Interaction to Next Paint(INP)

요약 — INP는 사용자가 클릭하거나 탭하거나 입력했을 때 페이지가 얼마나 빨리 반응하는지 측정합니다. 브라우저는 전체 방문 동안 상호작용부터 다음 시각적 업데이트까지의 간격을 재고, 거의 가장 느린 값을 보고합니다. 200 ms 미만이면 좋음, 500 ms 초과면 나쁨입니다. 세 가지 Core Web Vitals 중 하나이며, 2024년에 이전 지표인 First Input Delay를 대체했습니다.

INP가 실제로 측정하는 것

버튼을 클릭하거나 메뉴를 탭하거나 입력란에 글을 쓰면 메뉴가 열리고 체크박스가 선택되며 글자가 나타나는 등 페이지가 반응하기를 기대합니다. **Interaction to Next Paint(INP)**는 상호작용한 순간부터 브라우저가 변경 사항을 보여 주는 다음 프레임을 그릴 때까지 걸린 시간을 측정합니다.

중요한 점은 INP가 상호작용 하나만 보지 않는다는 것입니다. 방문 내내 발생한 모든 클릭·탭·키보드 입력을 관찰한 뒤, 거의 가장 느린 값을 보고합니다. 따라서 입력할 때마다 반초씩 멈추는 검색창처럼 한 번의 버벅이는 상호작용만으로도 전체 점수가 나빠질 수 있습니다.

스크롤, 마우스 오버, 확대·축소는 포함되지 않습니다. 클릭, 탭, 키보드 상호작용만 측정합니다.

기준값

INP는 밀리초 단위로 보고되며 Google은 세 등급으로 나눕니다.

• 좋음 — 200 ms 이하
• 개선 필요 — 200 ms 초과, 500 ms 이하
• 나쁨 — 500 ms 초과

200 ms는 빠르지만 여유가 크지는 않습니다. 클릭에 반응해 코드가 수행하는 모든 작업과 브라우저가 결과를 그리는 작업까지 이 시간 안에 끝나야 합니다.

FID를 대체한 이유

이전 반응성 지표는 **First Input Delay(FID)**였습니다. FID는 페이지의 첫 번째 상호작용 처리가 시작되기 전 지연만 측정했고, 작업이 시작되는 순간 측정을 끝냈습니다. 실제 작업 시간이나 화면 업데이트 시간은 포함하지 않았습니다.

INP는 이 한계를 모두 보완했습니다. 첫 상호작용만이 아니라 모든 상호작용에 대해 시작부터 시각적 업데이트까지의 전체 시간을 측정합니다. Google은 2024년 3월 12일 공식 전환했고, 2024년 9월에는 도구에서 FID를 완전히 제거했습니다.

쉽게 풀어본 INP 악화 원인

거의 언제나 JavaScript가 메인 스레드를 독점하는 것이 원인입니다. 브라우저는 메인 스레드에서 한 번에 한 작업만 할 수 있으므로, 스크립트 덩어리가 실행 중이면 클릭은 순서를 기다려야 합니다. 흔한 원인은 다음과 같습니다.

• 클릭·탭 핸들러 안에서 실행되는 무거운 작업
• 모든 것을 막는 큰 JavaScript ‘긴 작업’
• 서드파티 스크립트 — 분석, 쿠키 동의 배너, 채팅 위젯, 태그 관리자. 단순한 콘텐츠 사이트에서도 특히 큰 문제를 일으킵니다.

큰 방향에서의 해결책은 상호작용 시 수행하는 작업을 줄이고, 큰 작업을 작은 조각으로 나눠 브라우저가 그 사이에 상호작용을 처리할 수 있게 하는 것입니다.

세 부분으로 나뉘는 지연, 일흔다섯 번째 백분위수 계산, 원인별 해결법과 SEO 관점까지 자세히 알고 싶다면 고급 탭으로 전환하세요.

요약 — INP는 반응성을 나타내는 Core Web Vital입니다. 방문 중 발생한 모든 클릭·탭·키보드 상호작용의 지연을 관찰하고 일흔다섯 번째 백분위수 값(상호작용 50회마다 이상치 하나 제외)을 보고합니다. FID처럼 첫 입력만 보지 않습니다. 상호작용 지연 = 입력 지연 + 처리 시간 + 표시 지연입니다. 필드 데이터의 p75에서 좋음은 200 ms 이하, 나쁨은 500 ms 초과입니다. 2024년 3월 12일 FID를 대체했고, 2024년 9월 도구에서 FID가 완전히 제거됐습니다. 긴 작업을 나누고 scheduler.yield()로 메인 스레드에 양보하며, 이벤트 핸들러 작업과 DOM을 줄이고 서드파티 스크립트를 지연해 개선하세요. 필드 지표이므로 실험실 대용 지표는 Total Blocking Time이며, 두 값이 항상 일치하지는 않습니다.

INP가 측정하는 것과 FID와의 차이

Google의 정의는 명확합니다. INP는 “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (번역) 「사용자의 페이지 방문 전체 기간에 발생하는 모든 클릭·탭·키보드 상호작용의 지연을 관찰해 페이지의 전반적인 반응성을 평가합니다.」

‘방문 전체 기간의 모든 상호작용’이라는 표현이 핵심입니다. INP는 로드 시간 지표가 아니라 방문 단위 지표입니다. Google의 논리는 사용자가 페이지에서 보내는 시간 대부분이 로드 후이므로 첫인상뿐 아니라 실제 사용 중 반응성이 더 중요하다는 것입니다.

First Input Delay와 비교하면 가장 쉽게 이해할 수 있습니다. “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (번역) 「FID는 페이지 첫 상호작용의 입력 지연만 측정했지만, INP는 입력 지연부터 이벤트 핸들러 실행 시간까지 모든 상호작용을 관찰합니다.」 FID는 상호작용 하나에서 핸들러가 시작되기 전 대기 시간만 재고, 핸들러 실행 시간과 화면 업데이트 시간은 무시했습니다. INP는 모든 상호작용의 전체 지연을 측정합니다.

흔한 오해와 달리 INP는 문자 그대로 가장 느린 상호작용이 아닙니다. 무작위 급증 한 번 때문에 페이지가 불이익을 받지 않도록 브라우저는 상호작용 50회마다 이상치 하나를 제외한 뒤 페이지 조회수의 일흔다섯 번째 백분위수 값을 보고합니다. 상호작용이 적은 방문에서는 가장 느린 값이 되고, 많은 방문에서는 이상치 몇 개가 먼저 제외됩니다.

상호작용의 범위도 생각보다 좁습니다. 클릭·탭·키보드 입력만 측정하고 스크롤·마우스 오버·확대/축소는 명시적으로 제외합니다. 탭 한 번은 pointerdown, pointerup, click 같은 여러 이벤트를 발생시킬 수 있지만 INP는 세 개가 아니라 한 번의 상호작용으로 묶습니다. 이 그룹에서는 이벤트 시간을 합산하지 않고 가장 긴 개별 이벤트 시간을 사용합니다. 빠른 pointerdown과 느린 click이 함께 있으면 느린 이벤트 크기의 상호작용 하나로 보고됩니다. 방문 중 해당 상호작용이 없으면 INP도 보고되지 않습니다.

상호작용 지연의 세 부분

모든 상호작용 지연은 순서대로 세 부분으로 나뉩니다. 각 부분이 서로 다른 해결책을 가리키므로 이 모델을 기억하세요.

Interaction latency = Input delay + Processing duration + Presentation delay

1. 입력 지연 — 보통 메인 스레드가 긴 작업을 마치느라 바빠 이벤트 핸들러가 시작되기 전까지 기다리는 시간
2. 처리 시간 — 모든 이벤트 핸들러 콜백이 실행되는 시간
3. 표시 지연 — 핸들러 종료부터 브라우저가 화면에 다음 프레임을 그릴 때까지의 시간

web-vitals의 기여도 빌드는 세 값(inputDelay, processingDuration, presentationDelay)을 모두 제공하므로 실제 상호작용에서 어느 부분이 지배적인지 볼 수 있습니다. Web Almanac 2024 데이터에서는 중앙값 기준 표시 지연이 가장 큰 단일 부분인 경우가 많지만, 최적화 여지는 대개 처리 시간에 있습니다. 제대로 만들지 않은 페이지에서 특히 크게 늘어나는 부분이기 때문입니다.

기준값과 p75 필드 데이터 주의점

Google Search Central은 목표를 “an INP of less than 200 milliseconds” (번역) 「200밀리초 미만의 INP」라고 명시하고, 전체 프로그램을 “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (번역) 「검색에서 성공하려면 사이트 소유자가 우수한 Core Web Vitals를 달성할 것을 강력히 권장합니다.」라고 설명합니다. 브라우저가 60 fps에서 약 16,7 ms마다 프레임을 그리려 한다는 점을 생각하면 200 ms 예산은 실제로 빠듯합니다. 모든 핸들러 작업과 렌더링을 합쳐 이 안에 들어와야 합니다.

INP가 필드 지표인 이유(실험실 데이터만으로 부족한 이유)

많은 SEO 담당자가 빠지는 함정이 있습니다. Lighthouse 점수가 녹색이어도 INP가 좋다는 뜻은 아닙니다. 다만 ‘Lighthouse는 INP를 측정할 수 없다’는 말은 다음 세 경우로 구분해야 도구를 잘못 해석하지 않습니다.

1. 상호작용 없는 표준 Lighthouse 실행은 INP를 전혀 보고하지 않습니다. 페이지 로드만 관찰하고 클릭·탭·입력을 하지 않기 때문입니다. 대신 로드 시간 대용 지표인 **Total Blocking Time(TBT)**을 사용합니다. Google은 “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (번역) 「TBT는 INP와 상관관계가 높으므로 TBT가 높은 페이지는 로드 중 INP도 높을 수 있다는 합리적인 신호입니다.」라고 설명합니다. 핵심은 “during load.” (번역) 「로드 중」입니다. TBT는 십 초 뒤 지연 로드 위젯 때문에 나빠지는 상호작용을 설명하지 못하며, 어디까지나 대용 지표이지 대체값이나 환산식이 아닙니다.
2. DevTools에서 실제 버튼을 누르거나 실험실 도구로 클릭을 스크립팅한 상호작용은 그 한 번에 대한 실제 INP 방식의 지연 값을 만듭니다. 특정 버그를 재현하는 데 유용하지만, 한 기기에서 실행한 한 경로일 뿐입니다. 실제 기기·사용자·대상과 방문 전체를 포괄하는 필드 데이터를 대신할 수 없습니다. Google 표현대로 값은 “will be dependent on what interactions are performed during the measurement period,” (번역) 「측정 기간에 수행된 상호작용에 따라 달라집니다」이며, 실제 사용자 행동은 한 번의 실험실 실행으로 대표하기엔 너무 다양합니다.
3. 필드 분포가 INP 자체입니다. 따라서 권위 있는 출처는 필드 데이터, 즉 Chrome User Experience Report(CrUX)이며 PageSpeed Insights와 Search Console Core Web Vitals 보고서에 표시됩니다. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (번역) 「실제 사용자에게 어떤 상호작용이 문제인지 이해하는 데 필드 데이터가 가장 좋은 정보원입니다.」

실험실(1·2번)은 느린 상호작용을 찾아 재현하는 데 사용하고, 필드(3번)는 실제 방문자의 점수를 정말 낮추는지 확인하는 데 사용하세요.

INP 점수가 나쁜 이유

거의 모든 INP 문제는 사용자가 상호작용할 때 메인 스레드가 차단되는 데서 시작합니다. 흔한 원인은 다음과 같습니다.

• 긴 작업. 메인 스레드 작업이 50 ms를 넘으면 긴 작업이며, 50 ms를 넘긴 시간이 ‘차단 구간’입니다. 실행 중에는 상호작용을 처리할 수 없습니다. 가장 큰 단일 원인입니다.
• 무거운 이벤트 핸들러. 클릭·입력 핸들러 안에서 너무 많은 동기 작업을 하면 처리 시간이 직접 늘어납니다.
• 큰 DOM. DOM이 클수록 렌더링 비용이 커져 입력 지연과 표시 지연이 모두 늘어납니다.
• 서드파티 스크립트. Web Almanac에 따르면 동의 관리, 태그 관리자, 분석, 채팅 위젯이 주요 원인이며 단순 콘텐츠 사이트에도 영향을 줍니다. 직접 만들지 않은 페이지에서 가장 먼저 확인할 부분입니다.
• 로드 후 JavaScript. 페이지가 그려졌다고 로드가 끝난 것은 아닙니다. 첫 페인트 후 평가되는 스크립트가 초기 상호작용을 막을 수 있습니다.

해결 방법

효과가 큰 순서로 정리하면 다음과 같습니다.

1. 긴 작업을 나누세요. Google의 핵심 조언은 핸들러에서 “do as little work as possible in them.” (번역) 「가능한 한 적은 작업만 하세요」입니다. 큰 작업을 작은 태스크로 쪼개 브라우저가 사이사이에 사용자 상호작용을 처리하게 하세요. 작업을 나누면 “the browser can respond to higher-priority work much sooner — including user interactions.” (번역) 「브라우저가 사용자 상호작용을 포함한 우선순위 높은 작업에 훨씬 빨리 응답할 수 있습니다.」

2. 메인 스레드에 양보하세요. 현대적인 권장 방식은 scheduler.yield()(Chrome 129+, Firefox 142+)입니다. await scheduler.yield()는 코드를 잠시 멈춰 브라우저가 대기 작업을 처리하게 한 뒤 우선순위를 유지해 재개합니다. 고전적인 대안 setTimeout(..., 0)도 동작하지만 코드를 태스크 큐 끝으로 보내며, 브라우저는 중첩 호출이 여러 번 이어지면 최소 5 ms를 적용합니다. isInputPending()은 이제 피하세요. Google은 “we no longer recommend using this API.” (번역) 「더 이상 이 API 사용을 권장하지 않습니다.」라고 말합니다. 구현 방식은 스크립트 탭을 참고하세요.

3. 이벤트 핸들러 작업을 줄이고 중요하지 않은 작업은 미루세요. 다음 프레임의 시각적 업데이트에 필요한 일만 동기적으로 실행하고, 저장·맞춤법 검사·분석·단어 수 계산 등은 requestAnimationFrame + setTimeout 또는 yield 뒤로 보내세요. 사용자는 즉시 반응을 보고 부가 작업은 나중에 실행됩니다.

4. 레이아웃 스래싱을 피하세요. 같은 작업에서 스타일을 쓴 직후 레이아웃 속성을 읽으면 브라우저가 원래 묶어서 처리할 수 있었던 레이아웃을 동기적으로 강제합니다. 읽기를 먼저 묶고 쓰기를 묶으세요.

5. DOM 크기를 줄이세요. 트리가 작을수록 빠르게 렌더링됩니다. content-visibility를 사용하면 화면 밖 요소를 지연 렌더링해 로드나 상호작용 중 비용을 줄일 수 있습니다.

6. 서드파티 스크립트를 감사하고 지연하세요. 실제 사이트에서 효과가 큰 SEO 개선입니다. 동의·태그·분석 스크립트를 지연 로드하거나 상호작용 뒤에 실행하거나 핵심 경로에서 빼세요. 무거운 임베디드 위젯 하나만으로 ‘가벼운’ 콘텐츠 페이지가 INP에 실패할 수 있습니다.

INP가 순위에 영향을 주나요?

그렇습니다. INP는 세 가지 Core Web Vitals 중 하나이며 Core Web Vitals는 Google의 페이지 경험 신호에 포함됩니다. 하지만 가벼운 신호입니다. 관련성이 비슷한 결과 사이에서 동점 판정 역할을 할 뿐 주된 순위 요소는 아닙니다. 콘텐츠와 관련성을 희생해 완벽한 INP 점수를 좇지 마세요.

실무 SEO 관점에서 두 가지가 중요합니다. 첫째, 모바일 수치가 어렵습니다. 2024 Web Almanac에서 모바일 사이트 약 74%가 INP를 통과한 반면 데스크톱은 약 97%였습니다. Google은 모바일 우선 색인을 사용하므로 모바일 수치가 중요합니다. 둘째, 복잡한 사이트일수록 불리합니다. 상위 1000개 사이트 중 통과율은 약 53%에 불과했습니다. 기능이 많은 페이지일수록 메인 스레드를 막는 JavaScript를 더 많이 보내기 때문입니다. 무거운 기능 개발은 INP 위험이며 제품·결제·검색 결과·양식처럼 상호작용이 많은 페이지는 정적 콘텐츠보다 훨씬 더 취약합니다.

INP와 FID 전체 비교

FID는 사라졌습니다. INP 출시일에 Search Console에서 제거됐고 2024년 9월에는 CrUX BigQuery/API에서도 제거됐습니다. 도구나 감사가 아직 FID를 참조한다면 오래된 것입니다.

INP 데이터가 서로 달라지는 예외 상황

대부분의 ‘왜 RUM과 CrUX가 다르지?‘라는 질문은 다음 수명 주기 특성으로 설명할 수 있습니다.

• 상호작용이 없으면 INP도 없습니다. 방문 중 클릭·탭·키 입력이 없거나 스크롤·마우스 오버처럼 제외된 동작만 있었다면 해당 페이지 조회에는 INP 값이 없습니다. 읽기 전용 콘텐츠 페이지에서 정상이며 모니터링 버그가 아닙니다.
• iframe 상호작용은 지표에 포함되지만 자체 JavaScript로 내부를 볼 수는 없습니다. 광고·위젯·임베디드 양식 등 iframe 안의 상호작용도 페이지 INP에 기여합니다. 그러나 퍼스트파티 RUM 스크립트는 브라우저 자체 지표처럼 교차 출처 iframe 이벤트를 읽을 수 없습니다. 따라서 서드파티 임베드가 있는 페이지에서는 CrUX와 동일 출처 RUM이 정당하게 다를 수 있습니다. 이 차이를 버그로 취급하지 말고 문서화하세요.
• 뒤로/앞으로 가기 캐시 복원은 INP를 영으로 초기화합니다. 뒤로 가기 등으로 bfcache에서 복원된 페이지는 새 INP 집계를 시작하며, 이전 탐색 전 상호작용은 이어지지 않습니다.
• 오래 열려 있거나 백그라운드로 간 탭도 보고해야 합니다. 탭은 정식 unload 없이 몇 시간 열려 있을 수 있고, 모바일에서는 OS가 바로 종료할 수도 있습니다. 따라서 INP는 unload 시점뿐 아니라 페이지가 숨겨질 때 수집해야 합니다. unload에서만 전송하는 RUM은 이런 방문 데이터를 조용히 잃습니다.

관련 지표와 도구

INP는 Largest Contentful Paint(로딩), Cumulative Layout Shift(시각적 안정성)와 함께 Core Web Vitals를 구성합니다. 필드 데이터는 PageSpeed Insights와 Search Console 보고서에서 확인하고, 실험실에서는 Lighthouse와 Chrome DevTools에서 TBT 대용 지표로 디버깅하세요. 모든 데이터의 기반은 CrUX입니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• INP는 반응성을 나타내는 Core Web Vital입니다. 방문 전체의 모든 클릭·탭·키보드 상호작용 지연을 관찰하고 일흔다섯 번째 백분위수 값(상호작용 50회마다 이상치 하나 제외)을 보고합니다. FID처럼 첫 입력만 보지 않습니다.
• 지연 = 입력 지연 + 처리 시간 + 표시 지연입니다. 각 부분의 해결책이 다르며 보통 처리 시간에서 개선 여지가 큽니다.
• 기준(필드, p75): 좋음 ≤ 200 ms, 개선 필요 ≤ 500 ms, 나쁨 > 500 ms.
• 클릭·탭·키보드만 포함하고 스크롤·마우스 오버·확대/축소는 제외합니다. 한 동작에서 발생한 여러 이벤트는 상호작용 하나로 묶습니다.
• 2024년 3월 12일 FID를 대체했고, FID는 2024년 9월 도구에서 완전히 제거됐습니다. FID는 첫 상호작용의 입력 지연만 쟀습니다.
• 필드 지표이며 ‘Lighthouse가 측정할 수 없다’는 말은 세 경우로 구분해야 합니다. 상호작용 없는 표준 Lighthouse는 INP 대신 로드 시간 대용 지표인 Total Blocking Time을 보고합니다. 수동 실험실 상호작용은 실제 단일 상호작용 지연을 만들지만 필드 모집단을 대신할 수 없습니다. CrUX·PageSpeed Insights·Search Console의 필드 데이터만 권위가 있습니다.
• 원인: 긴 작업(>50 ms), 무거운 이벤트 핸들러, 큰 DOM, 특히 동의·태그 관리자·분석·채팅 같은 서드파티 스크립트입니다.
• 해결: 긴 작업을 나누고 **scheduler.yield()**로 양보하며(setTimeout 대안, isInputPending()은 더 이상 권장되지 않음), 핸들러 작업과 DOM을 줄이고 레이아웃 스래싱을 피하며 서드파티 스크립트를 지연하세요.
• 예외: 해당 상호작용이 없으면 INP도 없습니다. iframe 상호작용은 지표에 포함되지만 동일 출처 RUM은 내부를 볼 수 없습니다. bfcache 복원은 INP를 초기화하며, 오래 열리거나 백그라운드로 간 탭은 unload뿐 아니라 hidden에서도 보고해야 합니다.
• SEO: 가벼운 순위 신호입니다. 모바일 우선 색인에서는 모바일 통과율(약 74%, 데스크톱 약 97%)이 중요하며 상호작용이 많은 페이지가 가장 취약합니다.

공식 문서

Google과 Chrome 팀의 1차 출처 문서입니다.

web.dev — INP 참고 문서

• Interaction to Next Paint(INP) — 측정 대상, 세 부분의 지연, 상호작용 유형과 기준을 담은 공식 정의
• Interaction to Next Paint 최적화 — 핸들러 작업 축소, 중요하지 않은 작업 지연, 레이아웃 스래싱, DOM 크기, content-visibility 최적화 안내
• Interaction to Next Paint가 공식 Core Web Vital이 됨 — Jeremy Wagner와 Rick Viscomi가 쓴 2024년 3월 12일 출시 글과 FID 폐기 일정
• First Input Delay(FID) — 폐기된 지표의 측정 대상과 교체 이유
• 새로운 반응성 지표: 의견 요청 — FID의 설계 한계와 INP의 개선점
• 긴 작업 최적화 — 50 ms 긴 작업 정의, scheduler.yield(), setTimeout 대안, isInputPending()을 더 이상 권장하지 않는 이유
• 스크립트 평가와 긴 작업 — INP 대용 지표로서 TBT와 스크립트 크기 안내
• 필드에서 느린 상호작용 찾기 — web-vitals 기여도 빌드와 Long Animation Frames(LoAF) API

Chrome / Google 검색

• 성능 기능 참고 문서(Chrome DevTools) — Interactions 트랙, Live Metrics, 200 ms 경고
• CrUX 출시 노트 — 2024년 9월 BigQuery/API에서 FID가 제거됐음을 확인
• Core Web Vitals와 Google 검색 결과 — 페이지 경험 신호의 일부인 INP와 ≤ 200 ms 목표

출처 인용

Google과 Chrome 팀의 공식 발언입니다. 각 링크는 출처 페이지의 인용 구절로 바로 이동합니다.

INP의 측정 대상과 FID와의 차이

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (번역) 「INP는 방문 전체 기간의 모든 클릭·탭·키보드 상호작용 지연을 관찰해 페이지의 전반적인 반응성을 평가하는 Core Web Vitals 지표입니다.」 — web.dev, Interaction to Next Paint(INP). 인용으로 이동
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (번역) 「FID는 첫 상호작용의 입력 지연만 측정했지만 INP는 입력 지연부터 이벤트 핸들러 실행까지 모든 상호작용을 관찰합니다.」 인용으로 이동
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (번역) 「First Input Delay는 더 이상 Core Web Vital이 아니며 Interaction to Next Paint 지표로 대체됐습니다.」 — web.dev, First Input Delay(FID). 인용으로 이동

FID에서 INP로의 전환

• “FID will be deprecated.” (번역) 「FID는 폐기될 예정입니다.」 — Jeremy Wagner와 Rick Viscomi, web.dev 블로그, Interaction to Next Paint가 공식 Core Web Vital이 됨. 인용으로 이동
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (번역) 「3월 12일 INP가 Core Web Vital이 되는 즉시 Google Search Console에서 FID가 제거됩니다.」 인용으로 이동

주요 원인인 긴 작업

• “Any task that takes longer than 50 milliseconds is a long task.” (번역) 「50밀리초보다 오래 걸리는 모든 작업은 긴 작업입니다.」 — web.dev, 긴 작업 최적화. 인용으로 이동

필드 데이터가 우선

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (번역) 「실제 사용자에게 어떤 상호작용이 문제인지 이해하는 데 필드 데이터가 가장 좋은 정보원입니다.」 — web.dev, 필드에서 느린 상호작용 찾기. 인용으로 이동

Google 검색

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (번역) 「검색에서 성공하려면 사이트 소유자가 우수한 Core Web Vitals를 달성할 것을 강력히 권장합니다.」 — Google Search Central, Core Web Vitals와 Google 검색 결과. 출처

INP 개선 체크리스트

위에서 아래 순서로 진행하세요. 위쪽 항목일수록 수치를 크게 움직이는 경향이 있습니다.

• 실험실 점수만 보지 말고 PageSpeed Insights나 Search Console CWV 보고서에서 필드 INP를 가져오며 모바일을 별도로 확인합니다.
• web-vitals 기여도 빌드나 Chrome DevTools Interactions 트랙으로 느린 상호작용을 찾습니다(200 ms 초과 시 표시).
• 메인 스레드에서 50 ms를 넘는 긴 작업을 찾아 나눕니다.
• 오래 도는 루프 안에서 scheduler.yield()로 메인 스레드에 양보하고 setTimeout(..., 0)을 대안으로 둡니다. isInputPending() 사용은 중단합니다.
• 핸들러에서는 렌더링에 꼭 필요한 업데이트만 동기 실행하고 저장·검증·맞춤법 검사·분석은 rAF + setTimeout 뒤로 미룹니다.
• 같은 작업에서 스타일을 쓴 직후 레이아웃을 읽는 레이아웃 스래싱을 찾아 읽기와 쓰기를 각각 묶습니다.
• 동의·태그 관리자·분석·채팅 등 서드파티 스크립트를 감사하고 지연·지연 로드·상호작용 후 실행합니다. 대개 가장 큰 단일 개선입니다.
• DOM 크기를 줄이고 화면 밖 영역에 content-visibility를 적용합니다.
• 중요하지 않은 JS를 지연하거나 코드 분할해 로드 후 스크립트가 초기 상호작용을 막지 않게 합니다.
• 배포 뒤 필드에서 다시 측정합니다. CrUX는 28일 이동 창이므로 점수가 천천히 변합니다.

INP와 FID 요약표

빠른 사실

• 기준(필드, p75): 좋음 ≤ 200 ms · 개선 필요 ≤ 500 ms · 나쁨 > 500 ms
• 포함: 클릭·탭·키보드. 제외: 스크롤·마우스 오버·확대/축소
• 지연 = 입력 지연 + 처리 시간 + 표시 지연
• 긴 작업 = 메인 스레드에서 > 50 ms 걸리는 작업
• 실험실 대용 지표: Total Blocking Time. 상관관계는 있지만 로드 시간 차단만 반영하며 권위 있는 출처는 필드 데이터(CrUX)입니다.
• 모바일 통과율(약 74%)은 데스크톱(약 97%)보다 훨씬 낮고 모바일이 실제로 중요합니다.

메인 스레드에 양보하기

큰 목록 렌더링이나 클릭 후 데이터 처리처럼 오래 도는 루프에서는 브라우저에 주기적으로 제어권을 돌려줘 대기 중인 사용자 상호작용을 처리하게 하세요. 현대적인 API는 **scheduler.yield()**이며 지원되지 않는 곳에서는 setTimeout으로 대체합니다.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

참고 사항:

• scheduler.yield()는 향후 태스크에서 이행되는 promise를 반환하며, 이어지는 코드는 우선 처리되므로 대기 중인 다른 태스크가 재개 코드보다 앞서지 않습니다.
• setTimeout(..., 0)은 어디서나 동작하지만 이어지는 코드를 큐 끝으로 보냅니다. 브라우저는 중첩 호출이 여러 번 이어지면 약 5 ms의 최소값을 적용합니다.
• isInputPending()은 사용하지 마세요. Google은 이 API를 “no longer recommend[s] using this API.” (번역) 「더 이상 사용을 권장하지 않습니다.」

핸들러의 중요하지 않은 작업 미루기

다음 프레임에 필요한 작업만 실행하고 나머지는 페인트 뒤로 미루세요.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

INP 측정·개선 도구

필드(권위 있는 데이터로 Google이 평가하는 값)

• PageSpeed Insights — URL·출처의 모바일/데스크톱 CrUX 필드 INP와 실험실 진단
• Search Console Core Web Vitals 보고서 — 필드 데이터에서 문제별로 묶은 URL의 INP 상태
• CrUX — 기반 Chrome User Experience Report 데이터세트로 CrUX API와 BigQuery에서도 조회 가능

실험실 / 디버깅

• Chrome DevTools Performance 패널 — Interactions 트랙이 각 상호작용의 입력 지연·처리·표시 시간을 재고 200 ms 초과를 표시하며 Live Metrics는 클릭할 때마다 갱신됩니다.
• Lighthouse — INP를 직접 측정하지 못하며 실험실 대용 지표인 Total Blocking Time을 보고합니다.

실사용자 모니터링(RUM)

• web-vitals JS 라이브러리 — 값은 onINP()로 수집합니다. 기여도 빌드(web-vitals/attribution)는 inputDelay / processingDuration / presentationDelay, interactionTarget 선택자, LoAF 항목을 제공해 느린 상호작용을 일으킨 스크립트와 요소를 찾게 합니다. 어떤 RUM을 쓰든 샘플링 비율과 기여도 범위를 문서화하세요. 이 맥락 없는 RUM 수치는 CrUX 필드 p75와 비교할 수 없고, 집계 지표와 달리 교차 출처 iframe 내부를 볼 수도 없습니다(고급 탭의 예외 참조).

도구 자체의 점수

이 페이지의 지표를 실제로 보여 주는 예시입니다. 잘 알려진 페이지 속도·모니터링 서비스의 실제 사용자 모바일 INP(Chrome UX Report 필드 데이터)를 비교합니다.

핵심을 놓치기 쉬운 INP 개선

첫 상호작용만 최적화하기

INP는 첫 입력이 아니라 방문 전체의 상호작용을 평가합니다. 페이지가 반응성이 있다고 판단하기 전에 메뉴·검색·필터·양식과 반복 제어를 모두 실행해 보세요.

Total Blocking Time을 최종 결과로 보기

TBT는 메인 스레드의 긴 작업을 드러내는 유용한 실험실 대용 지표지만 필드 INP는 아닙니다. 후보를 찾는 데 사용한 뒤 필드 데이터나 상호작용 트레이스로 실제 상호작용을 확인하세요.

모든 작업을 지연 콜백 하나로 옮기기

큰 작업 블록을 미루기만 하면 멈춤 시점만 바뀔 수 있습니다. 작업을 더 작은 태스크로 나누고 브라우저가 사이에 페인트하도록 양보하세요.

핸들러를 줄이려고 시각적 피드백 없애기

작업 중임을 보여 주지 않는 제어는 여전히 고장 난 것처럼 느껴집니다. 즉각적인 상태 변화를 먼저 그리고 중요하지 않은 후속 작업을 미루세요.

세 부분 지연 모델로 INP 진단하기

느린 상호작용마다 살펴볼 곳은 세 군데입니다.

1. 입력 지연: 앞선 메인 스레드 작업이 계속 실행돼 이벤트가 기다렸습니다. 핸들러 시작 전의 긴 작업과 서드파티 JavaScript를 감사하세요.
2. 처리 시간: 이벤트 핸들러 자체가 너무 많은 일을 했습니다. 동기 작업을 줄이고 루프를 나누며 다음 프레임에 필요하지 않은 일은 미루세요.
3. 표시 지연: 핸들러 뒤 스타일·레이아웃·페인트가 오래 걸렸습니다. DOM 복잡도를 줄이고 반복적인 강제 레이아웃을 피하세요.

트레이스에서 가장 큰 단계부터 시작하세요. 각 변경 뒤 같은 상호작용을 다시 기록해 빨라진 핸들러가 새로운 표시 병목을 숨기지 않는지 확인합니다.

INP 변경으로 상호작용이 개선됐는지 입증하기

핸들러 양보 테스트

실행할 테스트: 긴 작업을 나누거나 양보하기 전후의 대상 상호작용을 Performance 패널에 기록합니다. 예상 결과: 처리 구간이 짧아지거나 페인트를 사이에 두고 나뉩니다. 실패 해석: 비싼 작업이 다른 곳에 있거나 여전히 동기 실행됩니다. 모니터링 기간: 반복 트레이스에서 즉시 확인합니다. 롤백 조건: 제어 업데이트 순서가 틀어지거나 상태를 잃거나 새 입력 오류가 발생합니다.

표시 테스트

실행할 테스트: 같은 트레이스에서 이벤트 핸들러 뒤 스타일·레이아웃·페인트 작업을 확인합니다. 예상 결과: 더 큰 레이아웃 작업 없이 다음 페인트가 빨라집니다. 실패 해석: DOM 크기나 강제 레이아웃이 여전히 병목입니다. 모니터링 기간: 실험실 트레이스에서 즉시 확인합니다. 롤백 조건: 시각적 반응이 불완전하거나 불안정해집니다.

필드 확인

실행할 테스트: 출시 후 변경한 상호작용·템플릿의 onINP() 기여도를 기준선과 비교합니다. 예상 결과: p75 INP가 개선되고 대상 요소가 느린 이벤트를 더 이상 지배하지 않습니다. 실패 해석: 실험실 사례가 실제 기기나 여정을 대표하지 못했습니다. 모니터링 기간: 방문이 들어오는 대로 RUM에서, CrUX는 28일 이동 창에서 확인합니다. 롤백 조건: 배포 뒤 반응성이나 상호작용 완료율이 지속적으로 악화됩니다.

추적할 가치가 있는 INP 지표

p75 실사용자 INP

지표: 템플릿·기기 유형별 일흔다섯 번째 백분위수 INP. 알 수 있는 것: 일반적인 실제 방문이 여정 전체에서 반응성이 있는지 보여 줍니다. 수집 방법: CrUX, PageSpeed Insights 또는 web-vitals RUM. 벤치마크 / 현실적 범위: 200 ms 이하는 좋음, 500 ms 초과는 나쁨입니다. 주기: JavaScript 출시 후 모니터링하고 매월 필드 이동 추세를 검토합니다.

느린 상호작용 비율

지표: 대상별 200 ms 초과 상호작용 비율. 알 수 있는 것: 페이지 p75가 통과해도 사용자에게 가장 큰 지연을 만드는 제어를 찾습니다. 수집 방법: web-vitals 기여도 빌드 또는 RUM의 Event Timing 데이터. 벤치마크 / 현실적 범위: 여정별 기준선을 정하고 빈도가 높은 문제부터 줄입니다. 주기: 애플리케이션형 템플릿은 매주 확인합니다.

지연 단계 비중

지표: 느린 상호작용의 입력 지연·처리 시간·표시 지연. 알 수 있는 것: 스케줄링, 핸들러 코드, 렌더링 중 주된 제약을 밝힙니다. 수집 방법: DevTools 트레이스와 INP 기여도. 벤치마크 / 현실적 범위: 보편적으로 건강한 비율은 없습니다. 각 단계를 자체 기준선 및 전체 200 ms 좋음 기준과 비교하세요. 주기: 집중 성능 조사 때마다 확인합니다.

볼 만한 자료

Google / Chrome 공식 자료

• Interaction to Next Paint(INP) — 출발점
• Interaction to Next Paint 최적화 — 개선법
• 긴 작업 최적화 — 양보와 scheduler.yield()
• 필드에서 느린 상호작용 찾기 — LoAF와 기여도 디버깅
• INP가 Core Web Vital이 됨 — 2024년 3월 12일 출시

데이터

• Web Almanac 2024 — 성능 — 실제 INP 통과율과 하위 단계 중앙값

업계 자료

• INP — MDN Web Docs — Google 밖에서 브라우저 지원과 지표 정의를 교차 확인하기 좋은 참고 항목
• Scheduler API: scheduler.yield() — MDN — 핵심 양보 기능의 브라우저 지원표와 사양 세부 정보
• PerformanceEventTiming — MDN — INP가 읽는 기반 브라우저 API와 원시 이벤트 타이밍 조사 자료
• Long Animation Frames API — Chrome Platform Status — web-vitals 라이브러리의 INP 기여도에 쓰이는 LoAF 브라우저 지원 추적
• INP 주제 — Search Engine Land — INP 업데이트, 테스트 결과, FID 전환에 대한 실무자 업계 기사

인용할 만한 통계

• 모바일 약 74%, 데스크톱 약 97%가 INP 통과(2024). 모바일이 훨씬 어렵고 Google이 모바일 우선 색인을 사용하므로 SEO에 중요한 수치입니다. Web Almanac 2024
• 상위 1000개 사이트 중 약 53%만 INP 통과. 기능이 많은 사이트는 메인 스레드를 막는 JavaScript를 더 많이 보내므로 큰 사이트가 오히려 더 나쁠 수 있습니다. Web Almanac 2024
• 긴 작업 = > 50 ms. 메인 스레드에서 50 ms를 넘긴 작업은 브라우저의 상호작용 응답을 막으며 INP 악화의 직접 원인입니다. web.dev — 긴 작업 최적화
• 하위 단계 중앙값(2024): 표시 지연 약 36 ms가 중앙값에서 가장 큰 단일 기여인 경우가 많고, 입력 지연과 처리 시간은 p75에서 그 뒤를 잇습니다. 어느 부분을 먼저 개선할지 판단하는 데 유용합니다. Web Almanac 2024

동영상

• Google Chrome Developers(YouTube) — DevTools로 느린 상호작용을 진단하는 실습을 포함한 Chrome 팀의 Core Web Vitals·INP 설명 영상. 채널

퀴즈: Interaction to Next Paint

반응성과 INP 진단에 관한 짧은 문제 다섯 개입니다. 답을 고른 뒤 확인하세요.

변경 내역