INP

한동안 웹 성능은 화면이 뜨는 속도만 재는 일이었습니다. 첫 화면이 2초 안에 나오면 좋은 페이지로 쳤습니다. 그런데 화면이 떠 있는 것과 쓸 수 있는 것은 다른 문제였습니다. 글자와 버튼이 다 보이는데 눌러도 아무 일이 일어나지 않는 구간이 그 뒤에 숨어 있었습니다.

이 구간은 사고로 드러났습니다. 결제 버튼을 눌렀는데 0.7초 동안 화면이 그대로면 사람은 자기가 잘못 눌렀다고 생각하고 한 번 더 누릅니다. 그렇게 같은 요청이 두 번 들어가 결제가 두 건 잡히거나 댓글이 두 개 달립니다. 고객센터에는 중복 결제 문의가 쌓이는데, 성능 보고서에는 모든 숫자가 초록색이었습니다. 재는 지표가 그 구간을 아예 보고 있지 않았기 때문입니다.

먼저 나온 대응은 반쪽이었습니다. 페이지를 열고 처음 누른 조작 하나가 얼마나 늦게 처리됐는지만 재는 지표가 그 자리에 있었습니다. 첫 조작만 보니 그 뒤 10분 동안 벌어지는 일은 기록되지 않았고, 정작 사람들이 굼뜨다고 느끼는 자리는 목록을 걸러내고 항목을 여는 그 10분 쪽이었습니다. INP 는 그 범위를 페이지에 머무는 시간 전체로 넓히고, 재는 끝점도 처리 시작이 아니라 화면이 실제로 바뀐 순간으로 옮긴 지표입니다.

조작 하나가 일어날 때마다 누른 순간부터 화면이 다시 그려진 순간까지를 재고, 페이지에 머무는 동안 쌓인 그 값들 가운데 가장 느린 것을 그 방문의 INP 로 씁니다.

한 번의 조작에서 재는 시간은 세 토막으로 나뉩니다.

1. 입력 지연 — 손가락이 닿은 순간부터 브라우저가 그 조작을 처리하기 시작할 때까지입니다. 브라우저가 다른 작업을 붙들고 있으면 여기서 밀립니다.
2. 처리 시간 — 그 조작에 걸린 코드가 실제로 도는 구간입니다. 목록을 다시 정렬하거나 화면에 그릴 내용을 계산하는 시간이 여기 들어갑니다.
3. 표시 지연 — 계산이 끝난 뒤 바뀐 화면이 실제로 그려질 때까지입니다.

셋을 더한 값이 그 조작의 지연입니다. 입력 지연 40밀리초에 처리 시간 320밀리초, 표시 지연 30밀리초면 390밀리초입니다.

대상이 되는 조작은 클릭과 탭, 키 입력입니다. 스크롤이나 마우스를 움직이는 동작은 세지 않습니다.

방문 하나의 대표값을 고르는 규칙은 두 단계입니다.

1. 조작이 50회 이하면 그중 가장 느린 값을 그대로 씁니다.
2. 50회를 넘으면 50회마다 가장 느린 값 하나씩을 빼고 남은 것 중 가장 느린 값을 씁니다. 한 번 튄 값이 전체를 대표하지 않게 하려는 장치입니다.

사이트 전체의 숫자는 방문마다 나온 이 값들을 모아 백분위수 75 지점에서 읽습니다. 평균이 아니라 위에서 네 명 중 한 명이 겪는 값을 보는 것이라, 대부분은 괜찮고 일부만 느린 상태가 그대로 드러납니다.

200밀리초 이하면 좋음, 200에서 500밀리초 사이면 개선 필요, 500밀리초를 넘으면 나쁨으로 봅니다. 앞서 말한 75백분위 값을 이 기준에 대 봅니다.

200이라는 선은 사람이 즉시 반응했다고 느끼는 한계에서 왔습니다. 이 안에서는 누른 것과 화면이 바뀐 것이 한 사건으로 묶이고, 넘어가면 두 사건으로 떨어져 기다렸다는 느낌이 생깁니다. 그리고 그 느낌이 500밀리초쯤에서 다시 누르는 행동으로 바뀝니다.

판정은 실제 사용자에게서 모은 값으로 합니다. 개발자 노트북에서 재면 대개 좋게 나옵니다. 기기가 빠르고 데이터도 적기 때문입니다. 같은 화면이 3년 된 보급형 휴대폰에서 목록 2000줄을 들고 있으면 같은 조작이 600밀리초로 벌어집니다. 그래서 한 대에서 잰 값이 아니라 실제 방문에서 모은 값으로 봅니다.

숫자가 나쁠 때 먼저 볼 곳은 처리 시간 쪽입니다. 세 토막 중 이쪽이 대개 가장 길고, 원인도 대개 한 번에 너무 많은 일을 하게 짜 둔 코드입니다. 화면에 필요 없는 코드까지 한꺼번에 받아 두는 게 문제라면 코드 스플리팅으로 필요한 순간에만 받게 나눕니다. 계산 자체를 줄일 수 없는 자리라면 옵티미스틱 UI처럼 결과를 기다리지 않고 성공을 가정해 화면부터 바꾸는 방법으로 체감을 끊습니다.

"INP 가 480이에요. 필터 누를 때마다 목록 전체를 다시 그리고 있어요."

지연의 원인이 특정 조작의 처리 시간에 몰려 있다는 진단입니다.

"로컬에선 안 잡혀요. 현장 데이터로 봐야 합니다."

개발 환경 측정값으로는 판정할 수 없다는 말입니다.

"이번 스프린트는 LCP 말고 INP 부터 봅시다. 중복 제출 문의가 늘었어요."

사용자 문의의 원인이 로딩이 아니라 반응 쪽이라는 판단입니다.

페이지덱에서 이 숫자가 회의에 올라온 건 문서 목록 화면 때문이었습니다. 문서가 500개 넘는 팀에서 태그 필터를 누르면 화면이 잠깐 멎었고, 고객센터로 필터가 안 먹는다는 문의가 들어왔습니다. 실제로는 먹고 있었고, 다만 반영까지 600밀리초쯤 걸려서 사람들이 두세 번 더 누르고 있었습니다.

태오가 세 토막을 나눠 재 보니 처리 시간이 520밀리초였습니다. 필터를 누를 때마다 목록 전체를 다시 계산하고 다시 그리고 있었습니다. 바뀐 부분만 다시 그리도록 고쳐 처리 시간을 90밀리초로 줄였고, 민서는 그 사이에도 눌렸다는 표시가 바로 나오도록 버튼 상태를 하나 더 만들었습니다. 다음 달 현장 데이터에서 75백분위 값이 610에서 170으로 내려왔고, 필터 문의도 함께 사라졌습니다.

서버가 느려서 나는 숫자로 읽는 경우가 많습니다. 반응이 느리면 요청이 늦게 돌아온다고 생각하기 쉬워서 생기는 오해입니다. 하지만 이 지표가 재는 구간은 브라우저 안에서 벌어지는 일이라, 서버를 아무리 빠르게 해도 화면을 그리는 코드가 무거우면 값이 그대로입니다. 원인을 서버로 잡으면 서버 증설에 예산을 쓰고도 숫자가 안 움직이는 분기를 보내게 됩니다.

평균으로 보면 괜찮다고 판단하는 것도 흔합니다. 조작 대부분이 50밀리초 안에 끝나니 평균을 내면 늘 좋은 값이 나옵니다. 그런데 이 지표는 애초에 가장 느린 조작을 골라 쓰는 값이고, 사람의 기억도 평균이 아니라 가장 답답했던 순간에 남습니다. 평균으로 보고하면 500밀리초짜리 조작 하나가 매 방문에 섞여 있어도 보고서에는 문제가 없는 것으로 나옵니다.