Interaction to Next Paint (INP): 개념, 측정 및 개선 방법

Interaction to Next Paint (INP)는 클릭, 탭, 키 입력 같은 사용자 인터랙션에 웹페이지가 얼마나 빠르게 반응하는지 측정하는 Core Web Vitals 지표입니다. INP는 사용자 입력부터 JavaScript 처리, 화면의 최종 시각적 업데이트에 이르는 전체 지연 시간을 측정합니다. 75번째 백분위수 기준 200밀리초 이하이면 좋은 INP 점수입니다. 2024년 3월, INP가 First Input Delay (FID)를 대체하여 Core Web Vitals에 도입되었습니다.

Interaction to Next Paint (INP)란 무엇인가?

INP는 반응성을 측정하는 Core Web Vital 지표입니다. 방문 동안 발생한 모든 인터랙션을 살펴보고 페이지당 하나의 수치를 보고합니다.

클릭, 탭, 키 입력이 발생할 때마다 브라우저는 입력 시점부터 화면에 다음 프레임이 표시될 때까지의 시간을 측정합니다. 그중 가장 느린 인터랙션이 해당 방문의 INP가 됩니다. 클릭이 많은 페이지에서는 Chrome이 50개 인터랙션마다 이상치 1개를 제외하며, 이는 대략 98번째 백분위수에 해당합니다.

INP vs FID: 무엇이 왜 바뀌었는가

2024년 3월, INP가 First Input Delay (FID)를 대체하여 공식 Core Web Vitals 지표가 되었습니다. Google이 FID를 폐기한 이유는 두 가지를 놓쳤기 때문입니다.

첫째, FID는 페이지의 첫 번째 인터랙션만 측정했습니다. 첫 클릭은 빠르고 이후의 인터랙션이 느렸다면, 사용자가 좋지 않은 경험을 했더라도 FID는 합격 점수를 보고했습니다. 반면 INP는 방문 중 일어난 모든 인터랙션을 측정합니다.

둘째, FID는 input delay 구간만 측정했습니다. 즉, 브라우저가 이벤트를 처리하기 시작할 때까지 대기한 시간만 포착했습니다. 이벤트 핸들러를 실행하는 데 걸린 시간(processing time)과 결과를 화면에 렌더링하는 데 필요한 시간(presentation delay)은 무시했습니다. INP는 이 세 구간을 모두 측정합니다.

거의 모든 사이트가 FID를 통과했습니다. 하지만 많은 사이트가 INP 기준에 미달합니다. 첫 클릭 이후의 작업이나 뒤이어 일어나는 인터랙션이 느리기 때문입니다.

INP는 어떤 인터랙션을 측정하는가?

INP는 개별 인터랙션만 측정합니다. 즉 클릭, 탭, 키 입력입니다.

INP 측정에 포함되는 인터랙션

• 마우스 클릭 (버튼, 링크, 체크박스, 커스텀 컨트롤 클릭 포함)
• 터치스크린 탭 (모바일 기기에서의 클릭에 해당)
• 실제 또는 온스크린 키보드의 키 입력 (폼 필드 입력, Enter 키 입력, 단축키 사용 포함)

INP 측정에 포함되지 않는 인터랙션

• 스크롤 (아래 설명 참조)
• 호버링 (mouseover)
• 드래그 (단, 드래그를 시작하는 pointerdown은 측정될 수 있음)
• 사용자 입력 없이 실행되는 CSS transition 및 animation

스크롤 자체는 측정 대상이 아닙니다. 하지만 스크롤 관련 코드는 두 가지 방식으로 INP를 저하시킬 수 있습니다. JavaScript 스크롤 애니메이션을 시작하는 앵커 링크 클릭은 인터랙션이며, 스크롤 코드가 그 내부에서 실행됩니다. 또한 매 스크롤 이벤트마다 실행되는 스크롤 핸들러가 main thread를 점유하면 다음 클릭이 대기해야 합니다. CSS의 scroll-behavior: smooth를 사용하면 두 문제를 모두 피할 수 있습니다.

INP 인터랙션의 3단계

INP가 측정하는 모든 인터랙션은 순서대로 세 단계를 거칩니다(Google은 이를 하위 부분(subparts)이라고 부릅니다). INP 값은 이 세 단계의 합이며, 단계마다 해결 방법이 다릅니다.

1. Input Delay

input delay는 클릭부터 이벤트 핸들러가 시작될 때까지의 시간입니다. 클릭은 그 순간 main thread에서 실행 중인 작업이 끝날 때까지 대기해야 합니다. 태그 관리자, 동의 배너 스크립트, 아직 하이드레이션 중인 프레임워크 등이 여기에 해당합니다.

input delay는 페이지가 로딩 중일 때 가장 심각합니다. CoreDash 데이터에 따르면 로딩 중의 클릭은 로드 완료 후 클릭보다 두 배 이상 느립니다(구체적인 수치는 아래 참조).

2. Processing Time

processing time은 해당 인터랙션의 이벤트 핸들러가 실행되는 데 걸리는 시간입니다. 폼 유효성 검사, 상태 업데이트, 애널리틱스 호출 등이 있습니다.

이벤트 핸들러에서 부하가 큰 DOM 작업, 동기식 API 호출, 느린 루프를 처리하면 processing time이 증가합니다. 전형적인 사례로 클릭 핸들러 내부의 dataLayer.push()가 있습니다. 화면이 업데이트되기도 전에 태그 관리자의 모든 태그가 먼저 실행됩니다. 해결책은 push 전에 yield하는 것입니다.

3. Presentation Delay

presentation delay는 이벤트 핸들러가 끝난 시점부터 화면에 다음 프레임이 나타날 때까지의 시간입니다. 스타일 계산, 레이아웃, 페인트가 포함됩니다.

DOM이 크거나 깊게 중첩된 페이지는 스타일을 다시 계산하고 레이아웃을 실행하는 데 더 오랜 시간이 걸립니다. 상태 변경 후 거대한 컴포넌트 트리를 다시 렌더링하는 싱글 페이지 애플리케이션은 종종 presentation delay가 높게 나타납니다.

INP 점수의 '좋음'과 '나쁨' 기준

합격 기준을 충족하려면 p75에서 페이지 방문의 INP가 200밀리초 이하여야 합니다:

• INP가 200밀리초 이하이면 페이지의 반응성이 좋음을 의미합니다.
• INP가 200~500밀리초 사이이면 페이지의 반응성 개선이 필요함을 의미합니다.
• INP가 500밀리초 초과이면 페이지의 반응성이 나쁨을 의미합니다.

INP는 75번째 백분위수를 사용하므로, 전체 페이지 방문의 75%에서 INP가 200ms 미만이어야 합니다. 여기에는 저사양 휴대폰을 사용하는 방문자도 포함됩니다.

Interaction to Next Paint (INP) 측정 방법

INP는 클릭하고 탭하고 입력하는 실제 방문자가 필요하므로, 실질적인 INP는 field data에서 나옵니다. 페이지만 단순히 로드하는 lab data 테스트에는 INP가 없습니다. Lighthouse는 대신 Total Blocking Time을 보여주는데, 이는 로드 중에 main thread가 얼마나 바빴는지만 알려줄 뿐 필터 메뉴 클릭에 대해서는 아무것도 알려주지 않습니다.

공식 INP 지표 확인

공식 INP는 CrUX에서 집계됩니다. PageSpeed Insights는 URL 또는 오리진의 최근 28일간 Chrome 데이터 중 75번째 백분위수를 보여줍니다. CrUX Vis는 지난 몇 달간의 변화 추이를 보여주며, BigQuery의 CrUX에서는 모든 오리진의 월별 데이터를 제공합니다.

Google Search Console은 Core Web Vitals 보고서에서 URL을 그룹으로 묶습니다. 기준을 통과하지 못한 그룹은 예시 URL과 함께 "INP 문제: 200ms 초과(모바일)" 또는 "INP 문제: 500ms 초과(모바일)"로 표시됩니다. 최근 28일간의 데이터를 다루므로, 수정 사항을 배포하고 2주가 지나도 표시되는 데이터의 절반은 여전히 이전 사이트의 기록입니다.

Real User Monitoring으로 INP 추적

CrUX는 페이지 그룹이 기준에 미달한다는 사실은 알려주지만, 어떤 버튼 때문인지는 알려주지 않습니다. 이를 확인하려면 Real User Monitoring이 필요합니다. CoreDash에서는 클릭된 요소와 로드 상태별로 나누어 모바일의 INP p75를 먼저 살펴봅니다.

현재 세션의 INP 측정

Chrome DevTools의 Performance 패널을 엽니다. 페이지 곳곳을 클릭할 때 현재 세션의 INP가 모든 인터랙션 로그 및 세 단계와 함께 표시됩니다. 클릭하는 동안 트레이스를 기록하면 main thread에서 무엇이 실행되었는지 확인할 수 있습니다. Core Web Vitals Visualizer 확장 프로그램은 페이지 자체에서 직접 INP를 표시해 줍니다.

직접 디버깅하려면 Google의 Web Vitals JavaScript 라이브러리를 사용하여 개별 인터랙션을 콘솔에 기록하십시오:

Web Vitals JavaScript 라이브러리로 콘솔에 INP 기록

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@6/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Interaction to Next Paint 개선 방법

다른 모든 클릭이 빠르더라도 느린 인터랙션 단 하나가 방문 전체의 INP를 결정할 수 있습니다. 세 단계를 하나씩 점검하십시오.

PageSpeed TIP: 모든 인터랙션마다 페이지 로드 상태를 기록하십시오. 로딩 중에 일어난 느린 클릭은 로드가 완료된 페이지에서의 느린 클릭과 해결 방법이 다릅니다.

1. Input Delay 최소화: Main Thread의 Long Task 방지

main thread 작업의 대부분은 초기 시작 단계에서 발생합니다. main thread를 여유 있게 유지하십시오:

• 사용하지 않는 코드를 제거하십시오. DevTools의 Coverage 패널을 보면 각 스크립트에서 실행되지 않는 코드의 양을 확인할 수 있습니다. 나머지는 트리 셰이킹과 코드 분할로 정리합니다.
• 중요하지 않은 코드는 브라우저 유휴 시간에 로드하십시오. 페이지 로드 후 첫 500밀리초 동안 채팅 위젯이 정말 필요합니까? 중요하지 않은 스크립트는 requestIdleCallback()을 사용하여 브라우저가 유휴 상태일 때만 실행되도록 예약하십시오.
• 클릭 순간의 long task를 찾으십시오. 로드 중에 클릭하면서 Performance 패널에서 트레이스를 기록합니다. 클릭이 발생한 순간 실행 중이던 task를 가장 먼저 해결해야 합니다.
• JavaScript가 HTML 파서를 차단하지 않도록 script 태그에 async와 defer를 사용하십시오. 초기 몇 초 동안 아무도 필요로 하지 않는 스크립트는 더 뒤로 미룰 수 있습니다: JavaScript 지연을 위한 14가지 방법.
• 패시브 리스너 조언은 건너뛰십시오. { passive: true }는 INP 권장 사항으로 자주 언급됩니다. 이는 스크롤을 부드럽게 만들 뿐, INP와는 무관합니다.

scheduler.yield()로 Long Task 분할

JavaScript는 브라우저의 main thread에서 "run to completion" 모델로 실행됩니다. 즉 작업이 한 번 시작되면 완료될 때까지 main thread를 차단합니다. 50밀리초를 초과하는 long task는 브라우저가 사용자 입력에 반응하지 못하게 만듭니다. scheduler.yield()를 사용하면 코드를 계속 실행하기 전에 대기 중인 클릭을 처리할 수 있는 여유를 브라우저에 넘겨줄 수 있습니다. 자세한 내용은 main thread에 yield하기를 참조하십시오.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // scheduler.yield()를 지원하지 않는 브라우저를 위한 fallback
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// 사용법: 하나의 long task를 더 작은 단위로 분할
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // 브라우저가 사용자 입력을 처리할 수 있도록 5개 항목마다 yield
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

requestIdleCallback으로 중요하지 않은 작업 지연

requestIdleCallback()을 사용하여 중요하지 않은 작업(애널리틱스, 텔레메트리, 프리페치)을 브라우저가 유휴 상태일 때 실행되도록 예약하십시오. 그러면 해당 작업이 클릭의 processing time에 포함되지 않습니다.

// 애널리틱스를 동기식으로 실행하는 대신:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // 중요: UI 즉시 업데이트
  showConfirmation();

  // 비중요: 유휴 시간에 애널리틱스 전송
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

2. Processing Time 최소화: 즉각적인 피드백 제공

방문자가 폼 제출이나 장바구니 담기 같은 동작을 수행할 때, 서버 확인을 기다린 뒤 UI를 업데이트하지 마십시오. 즉각적인 시각적 피드백("양식 제출 중...", "장바구니에 담는 중...")을 제공한 후 백그라운드에서 작업을 완료하십시오.

또한 중요한 시각적 업데이트 직후 가능한 한 빨리 main thread에 yield하십시오. JavaScript는 "run to completion" 모델을 따르므로 콜백 내의 모든 코드가 실행될 때까지 main thread를 차단합니다. 수동으로 yield 지점을 만들어 브라우저가 레이아웃을 업데이트하도록 한 후, 남아 있는 중요하지 않은 코드를 계속 실행할 수 있습니다.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run, 0);
});

3. Presentation Delay 최소화: 단순함 유지

인터랙션 후 페이지를 업데이트해야 할 때 브라우저는 스타일 재계산, 레이아웃 수행, 변경된 픽셀 페인트, 결과물 합성을 거쳐야 합니다. DOM의 복잡도와 크기가 이 렌더링 작업에 걸리는 시간을 직접적으로 결정합니다.

일부 싱글 페이지 애플리케이션은 카운터 하나만 바뀌었을 뿐인데 인터랙션마다 페이지 절반을 다시 렌더링합니다. React DevTools와 React Scan으로 이를 확인할 수 있습니다. 트리 상단에 있는 단 하나의 컨텍스트 프로바이더가 하위의 모든 요소를 다시 렌더링하는 경우가 흔합니다.

더 빠른 렌더링을 위한 두 가지 규칙:

1. DOM을 작고 단순하게 유지하십시오. 작고 평평한 DOM은 크고 깊게 중첩된 DOM보다 빠르게 렌더링됩니다. Lighthouse는 DOM 요소가 1,400개를 초과하거나 중첩 깊이가 32단계를 초과하는 페이지에 플래그를 지정합니다.
2. content-visibility를 사용하여 화면 밖 콘텐츠를 지연 렌더링하십시오. content-visibility: auto CSS 속성은 사용자가 스크롤하여 근처에 도달할 때까지 화면 밖 콘텐츠의 렌더링을 미루어 초기 렌더링 속도를 높입니다.

/* 화면 밖 섹션에 content-visibility 적용 */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Long Animation Frames (LoAF) API로 INP 디버깅

Long Animation Frames (LoAF) API는 렌더링하는 데 50밀리초 이상 걸린 프레임에 대한 세부 정보와 그동안 실행된 스크립트 정보를 제공합니다.

이전의 Long Tasks API와 달리, LoAF는 스크립트 실행 시간뿐 아니라 렌더링 시간까지 측정하므로 presentation delay 문제를 진단하는 데 특히 유용합니다. 각 항목에는 프레임 지속 시간과 차단 시간이 포함됩니다. scripts 목록에는 스크립트별로 소스 URL, 함수 이름, 실행 시간이 표시됩니다.

// INP 병목 지점을 찾기 위해 Long Animation Frames 관찰
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // 100ms를 초과하는 프레임만 확인
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // 원인이 된 각 스크립트 기록
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

CoreDash 같은 RUM 도구는 LoAF 데이터를 자동으로 통합하여, 긴 애니메이션 프레임과 특정 사용자 인터랙션을 연계해 줍니다. 따라서 어떤 페이지의 어떤 스크립트가 어떤 인터랙션을 느리게 만드는지 파악할 수 있습니다.

INP와 LCP: Long Task의 상관관계

main thread의 long task는 INP와 Largest Contentful Paint (LCP) 모두에 영향을 미칩니다. main thread를 200밀리초 동안 차단하는 JavaScript 작업은 이벤트 처리를 지연시켜 INP를 악화시키고, 브라우저의 LCP 요소 렌더링도 지연시켜 LCP를 악화시킵니다. long task를 분할하고, 중요하지 않은 JavaScript를 지연시키며, 스크립트 실행 시간을 줄여 main thread를 최적화하면 두 지표 모두 개선됩니다.

사례 연구: 프로덕션 환경에서의 INP 개선

redBus: INP 72% 감소, 매출 7% 증가

온라인 버스 예매 플랫폼 redBus는 RUM 데이터에서 예상치 못했던 느린 인터랙션을 발견했습니다. 검색 페이지에서는 매 스크롤 이벤트마다 스크롤 핸들러가 실행되어 main thread를 점유하고 있었기에, 디바운스 처리를 적용했습니다. 다른 페이지에서는 입력 필드가 변경될 때마다 상태 리듀서가 실행되고 있어 호출 빈도를 줄였습니다. 그 결과 해당 페이지의 INP가 72% 개선되었고, redBus의 매출은 약 7% 증가했습니다. (web.dev의 redBus 사례 연구)

Preply: Next.js 사이트에서 INP를 250ms에서 185ms로 단축

Next.js 기반의 온라인 언어 튜터링 플랫폼 Preply는 홈 페이지의 INP를 약 250ms에서 185ms로, 검색 페이지는 175ms로 단축했습니다. React Server Components 없이 이뤄낸 성과입니다. 긴 목록을 가상화하고, 키보드 이벤트를 디바운스했으며, 무거운 컴포넌트를 메모이제이션했습니다. 또한 툴팁이 페이지 전체를 다시 렌더링하지 않도록 방지하고, 개인정보 보호 배너의 상태 처리 방식을 수정했습니다. 작업 시작 전 Preply는 두 페이지를 200ms 미만으로 개선하면 검색 트래픽 기준 연간 약 20만 달러의 가치가 창출될 것으로 추산했습니다. (Preply 엔지니어링 블로그)

CoreDash 데이터로 보는 INP

모바일과 데스크톱의 INP 격차

CoreDash 데이터에서 모바일 INP(p75 기준 131ms)는 데스크톱 INP(48ms)의 2.8배입니다. 휴대폰은 CPU가 느립니다. 동일한 JavaScript라도 main thread를 더 오래 차단합니다. 데스크톱에서는 인터랙션의 95.6%가 '좋음'이지만 모바일은 88.0%이며, 모바일의 '나쁨' 비율(9.6%)은 데스크톱(1.9%)의 5배에 달합니다.

키보드 vs 포인터 인터랙션

CoreDash 데이터에 따르면 키보드 인터랙션(p75 기준 75ms)은 포인터 인터랙션(p75 기준 49ms)보다 56% 느립니다. 키보드 이벤트는 부정적인 경험의 비율도 약 5배 높습니다. 포인터 인터랙션은 1.4%만 불량한 INP를 기록한 반면, 키보드 인터랙션은 7.4%에 달했습니다. 키보드 이벤트, 특히 폼 필드 입력은 유효성 검사, 자동완성, 상태 업데이트를 자주 트리거하기 때문입니다.

로딩 중 vs 로드 완료 후 인터랙션

페이지 로딩 중에 발생하는 인터랙션은 로드가 완료된 후의 인터랙션보다 INP가 훨씬 높습니다. CoreDash 데이터에 따르면 "loading" 단계의 인터랙션은 p75 INP가 132ms인 반면, 로드 완료 후 인터랙션은 50ms에 불과합니다. 2.6배 차이입니다. "dom-content-loaded" 단계의 인터랙션(75ms)도 높은 INP를 보이는데, 비동기 스크립트와 서브 리소스가 여전히 처리 중이기 때문입니다. 해결책은 초기 시작 시 JavaScript를 줄이는 것입니다: 미룰 수 있는 것은 뒤로 미루십시오.

웹 전반의 INP 현황

2026년 8월 CrUX 릴리스에서 '좋음' 수준의 INP를 기록한 오리진은 85.3%로, 3월의 87.2%에서 하락했습니다. 그 사이 INP는 매달 하락했으며, 2025년 8월(85.7%)과 비교해 악화된 유일한 Core Web Vitals 지표입니다. Chrome 팀은 이를 우려스러운 문제로 보고 있으며 아직 명확한 원인을 찾지 못했습니다.

2025 Web Almanac은 기기 간 격차를 보여줍니다. 데스크톱 페이지의 97%가 좋은 INP를 기록한 반면 모바일은 77%에 그쳤습니다. 상위 1,000개 사이트는 모바일 '좋음' 비율이 53%에서 63%로 가장 크게 개선되었습니다. 한편 모바일 Total Blocking Time의 중앙값은 1,209밀리초에서 1,916밀리초로 58% 증가했습니다.

자주 묻는 질문

관련 가이드

INP의 각 단계별 가이드:

• <strong>INP 문제 진단 및 해결</strong>: Search Console 보고서부터 느린 인터랙션 추적까지, RUM 데이터와 DevTools 활용법.
• <strong>INP Input Delay</strong>: 클릭을 대기하게 만드는 long task.
• <strong>INP Processing Time</strong>: 이벤트 핸들러 및 화면 업데이트 후 실행 가능한 작업.
• <strong>INP Presentation Delay</strong>: DOM 크기, layout thrashing 및 리렌더링.

관련 PageSpeed 가이드:

• INP 개선: JavaScript 스크롤 제거
• Async vs Defer: JavaScript 로딩 전략
• JavaScript 지연을 위한 14가지 방법
• 완벽한 Core Web Vitals를 유지하는 채팅 위젯
• 해결 가이드: 과도한 DOM 크기 방지