INP (Interaction to Next Paint)

INP(Interaction to Next Paint)는 2024년 3월 12일 FID를 대체한 Core Web Vitals 반응성 지표다. 200ms 이하가 Good 등급이며, 세션 전체 인터랙션의 75번째 백분위수를 측정한다. 메인 스레드 차단과 긴 JavaScript 작업이 주요 원인이다.

정의

INP는 사용자 입력부터 다음 화면 갱신까지 걸리는 시간을 측정하는 CWV 지표다.

TL;DR

INP란 무엇인가?

INP(Interaction to Next Paint)는 사용자가 버튼을 클릭하거나 키를 누른 순간부터 브라우저가 다음 화면을 그릴 때까지 걸리는 시간이다. 2024년 3월 12일 Google은 INP를 Core Web Vitals의 공식 반응성 지표로 채택했다. 기존 FID(First Input Delay)는 공식 CWV 지표에서 제외됐다.

측정 기준

등급	INP 범위
Good	200ms 이하
Needs Improvement	200ms ~ 500ms
Poor	500ms 초과

Google은 75번째 백분위수를 기준으로 삼는다. 세션 내 발생한 모든 인터랙션 중 75% 지점의 INP 값이 Good 임계값 이내여야 Good 등급이다. Chrome UX Report(CrUX)와 Google Search Console에서 실제 사용자 Field Data로 확인한다.

FID와의 차이

측정 범위

FID는 페이지 로드 후 첫 번째 인터랙션만 측정했다. INP는 세션 전체(클릭, 탭, 키보드 입력)를 추적한다.

측정 대상

FID는 이벤트 처리 시작까지의 딜레이(입력 지연)만 측정했다. INP는 이벤트 처리 시작 → 렌더링 완료까지 전 과정을 포함한다.

실용적 의미

FID는 처음 클릭이 빠르면 높은 점수가 나왔지만, INP는 페이지 사용 중 어느 시점에서든 응답이 느리면 점수가 낮아진다. 실사용자 경험을 더 정확하게 반영한다.

INP가 높아지는 원인

긴 JavaScript 작업(Long Tasks)

50ms를 초과하는 JavaScript 작업이 메인 스레드를 차지하면 인터랙션 처리가 지연된다. Performance 패널의 "Long Tasks" 항목으로 식별한다.

이벤트 핸들러 내 무거운 연산

클릭 핸들러 안에서 DOM 탐색, 동기 네트워크 요청, 복잡한 계산을 실행하면 렌더링이 지연된다.

렌더링 트리 재계산

많은 DOM 요소를 한 번에 변경하면 브라우저가 레이아웃을 재계산하는 비용이 커진다.

INP 개선 방법

1. 긴 작업 분할

scheduler.yield()나 setTimeout(fn, 0)으로 긴 작업을 여러 작은 작업으로 쪼갠다. 브라우저가 중간에 인터랙션을 처리할 기회를 준다.

2. 이벤트 핸들러 최적화

클릭·탭 핸들러에서 즉시 필요하지 않은 연산을 제거하거나 지연 실행한다. 무거운 연산은 Web Worker로 분리한다.

3. 불필요한 리렌더링 억제

React 기반이라면 React.memo, useMemo, useCallback으로 불필요한 리렌더링을 줄인다. 상태 변경 범위를 최소화한다.

4. CSS 애니메이션 선호

JavaScript 기반 애니메이션 대신 CSS transform, opacity를 사용한다. GPU 가속 속성은 메인 스레드 부하 없이 실행된다.

SEO와의 관계

Google은 INP를 Page Experience 신호로 검색 순위에 반영한다. Poor INP 페이지는 동일한 콘텐츠 품질 조건에서 Good 등급 페이지보다 불리하다. 특히 JavaScript가 많은 SPA(Single Page Application)에서 INP 문제가 자주 발생하며, 한국 모바일 사용자처럼 다양한 기기 환경에서 INP 편차가 크다.

한국 시장 맥락

한국의 뉴스·커머스·커뮤니티 사이트는 광고와 스크립트가 많아 메인 스레드 부하가 높다. 이런 사이트는 INP Poor 등급이 나올 가능성이 높다. Google Search Console에서 "모바일" 기준 INP를 별도로 확인하고, 모바일에서 Long Tasks를 우선적으로 줄이는 것이 효과적이다.

자주 묻는 질문

Q. INP와 TBT(Total Blocking Time)의 차이는 무엇인가요? A. TBT는 Lab Data(Lighthouse 시뮬레이션) 지표로 Long Tasks로 인한 메인 스레드 차단 시간을 측정한다. INP는 Field Data(실제 사용자)를 기반으로 하며, 실제 인터랙션 응답 시간을 직접 측정한다. TBT 개선이 INP 개선으로 이어지는 경향이 있어 Lighthouse TBT를 INP의 대리 지표로 활용할 수 있다.

Q. INP는 어떻게 측정하나요? A. Chrome DevTools Performance 패널의 "Interactions" 트랙에서 각 인터랙션별 INP를 확인할 수 있다. 또는 PerformanceObserver API로 직접 수집하거나, Google Search Console의 Core Web Vitals 보고서에서 Field Data를 확인한다.

Q. 200ms 이하 달성이 어려운 이유는 무엇인가요? A. 이벤트 처리 + 렌더링 완료까지 200ms 안에 끝내야 하는데, 복잡한 UI나 무거운 라이브러리를 사용하는 경우 쉽지 않다. 특히 React, Vue 같은 프레임워크에서 상태 변경이 전체 트리 리렌더링을 유발하면 200ms를 초과하기 쉽다.

Q. 모바일과 데스크톱 INP 기준이 다른가요? A. 임계값(200ms Good)은 같지만, Google Search Console에서 모바일과 데스크톱을 분리해 볼 수 있다. 일반적으로 모바일은 CPU 성능이 낮아 데스크톱보다 INP가 높게 측정되는 경향이 있다.