[배우는 중] 버벅임에 드디어 점수가 붙었다 — INP

배우는 중(Learning log) — 완성된 정리가 아니라, 혼자 공부하다 막힌 지점과 그걸 넘은 과정을 그대로 남기는 시리즈입니다. 지금 제 이해라서 틀릴 수 있고, 나중에 알게 되면 정정 노트를 답니다.

Core Web Vitals를 공부하던 글에서 세 지표를 정리했었어요.

그때 반응성 지표는 FID(First Input Delay)였는데, 다시 보니 이름이 바뀌어 있더라고요.

2024년부터 INP(Interaction to Next Paint)가 그 자리를 대신했어요.

왜 갈아치웠나 궁금해서 파봤어요.

FID는 “첫 입력이 처리되기까지 걸린 시간”만 쟀어요.

페이지 뜨자마자 딱 한 번, 그것도 “반응을 시작하기까지”만요.

문제는 사용자가 답답함을 느끼는 순간이 대개 첫 클릭이 아니라는 거예요.

스크롤하다 버튼을 누르고, 탭을 바꾸고, 폼을 채우는 그 중간중간에서 버벅였죠.

INP는 거길 봐요.

페이지에 머무는 동안의 모든 상호작용을 재서, 그중 가장 느렸던 축을 대표값으로 삼아요.

클릭·탭·키 입력을 한 뒤 화면이 다음 그림을 그릴 때까지의 지연을요.

”눌렀는데 왜 늦게 반응하지”라는 그 감각에, 드디어 점수가 붙은 거예요.

기준은 이래요.

200ms 이하면 좋음, 200~500ms면 개선 필요, 500ms를 넘으면 나쁨.

사람이 “즉각적”이라고 느끼는 경계가 대략 200ms 언저리라, 그 선이 기준이 됐어요.

처음엔 이게 퍼블리셔 시절 감각이랑 닿는 데가 있었어요.

그때도 손이 닿는 순간의 반응은 목숨처럼 여겼거든요.

애니메이션은 transform·opacity로만, 리플로우 일으키는 속성은 최대한 늦게.

브라우저가 다시 그리는 비용을 아끼려던 그 습관이, 결국 INP가 재는 것과 같은 이야기였어요.

INP가 나빠지는 원인은 대체로 하나로 모여요 — 메인 스레드가 막혀 있는 것.

버튼을 눌러도, 그 클릭을 처리할 자바스크립트가 이미 돌고 있는 긴 작업 뒤에 줄 서 있으면 화면은 그만큼 늦게 반응해요.

이벤트 루프 글에서 “싱글 스레드라 한 번에 하나씩”이라고 정리했던 그 구조가, 여기선 지연으로 드러나는 거예요.

그래서 손대는 방향도 정해져요.

한 번에 오래 도는 작업을 잘게 쪼개 중간에 브라우저가 숨 쉴 틈(반응할 틈)을 주고, 당장 급하지 않은 계산은 뒤로 미뤄요.

무거운 이벤트 핸들러 안에서 화면 전체를 다시 그리게 만들지 않고요.

예전에 useMemo를 남용했다 혼난 것처럼, “이 계산이 지금 이 클릭을 붙잡고 있나”를 묻는 습관이 여기서도 쓰여요.

아직 헷갈리는 것도 있어요.

INP는 실제 사용자에게서 수집되는 현장 데이터라, 내 개발 기기에서 빠르게 느껴져도 느린 기기 사용자에겐 나쁠 수 있다는 점이요.

그래서 크롬 개발자도구의 성능 패널로 상호작용을 직접 기록해보는 것부터 다시 익히는 중이에요.

다음에 팔 씨앗은 하나 정해뒀어요 — 긴 작업을 쪼갤 때 쓰는 scheduler.yield 같은 스케줄링 API.

”메인 스레드를 언제 놓아줄 것인가”를 개발자가 표시하는 도구라던데, 아직 안 써봤어요.

써보고 나면 그때 다시 적을게요.