INP — FID를 대체한 반응성 지표, 무엇이 달라졌나

2024년 3월 12일, 구글은 Core Web Vitals의 반응성(responsiveness) 지표를 FID(First Input Delay)에서 INP(Interaction to Next Paint)로 교체했습니다. FID로 통과하던 사이트가 INP에선 떨어질 수 있어, 6년차라면 차이를 정확히 알아야 합니다.

FID는 왜 부족했나

FID는 첫 상호작용의 입력 지연만 측정했습니다. 즉 “첫 클릭이 얼마나 빨리 반응을 시작했나”만 봤죠. 그래서:

• 첫 클릭만 빠르면 이후 모든 인터랙션이 굼떠도 통과했습니다.
• “입력 지연”만 재고, 실제 처리·렌더링 시간은 안 봤습니다.

INP가 재는 것

INP는 페이지 생애 동안의 모든 인터랙션(클릭·탭·키 입력)을 관찰해, 그중 가장 오래 걸린 것(이상치 제외)을 대표값으로 보고합니다. 그리고 한 인터랙션의 전체 구간을 잽니다.

INP = 입력 지연 + 처리 시간(이벤트 핸들러) + 프레젠테이션 지연(다음 페인트까지)

즉 “탭했더니 화면이 실제로 바뀌기까지” 전 구간입니다. 훨씬 사용자 체감에 가깝습니다.

기준값

필드 데이터(실사용자)의 75 퍼센타일 기준:

등급	INP
좋음(Good)	< 200ms
개선 필요	200ms ~ 500ms
나쁨(Poor)	> 500ms

어떻게 개선하나

INP를 잡는 핵심은 메인 스레드에서 긴 작업을 끊어주는 것입니다.

• 긴 태스크 쪼개기: 이벤트 핸들러에서 무거운 동기 작업을 하지 말고, 급하지 않은 부분은 메인 스레드에 양보(yield)하세요. scheduler.yield()(지원 확인 필요)나 await/setTimeout으로 다음 틱에 넘깁니다.
• 먼저 그리고 나중에 계산: 클릭 시 UI를 즉시 업데이트해 시각적 반응부터 주고(프레젠테이션), 무거운 계산은 그 다음으로 미룹니다.
• 입력 디바운스/스로틀: 특히 input·scroll 계열.
• 렌더 비용 축소: 큰 리스트 가상화, content-visibility: auto로 오프스크린 렌더 지연, 불필요한 리렌더 제거.
• 자바스크립트 총량 줄이기: 하이드레이션·서드파티 스크립트가 메인 스레드를 오래 잡으면 INP가 나빠집니다.

측정 도구

• 필드(실사용자): Chrome UX Report(CrUX), PageSpeed Insights, web-vitals 자바스크립트 라이브러리로 실제 사용자 INP 수집
• 랩(진단): Lighthouse, DevTools Performance 패널에서 어떤 인터랙션이 길었는지 추적

INP는 “첫인상”이 아니라 **“페이지를 쓰는 내내 얼마나 반응이 좋은가”**를 봅니다. 자바스크립트가 메인 스레드를 얼마나 오래 붙잡는지가 그대로 점수가 됩니다.