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

Interaction to Next Paint (INP)는 웹페이지가 클릭, 탭, 키 입력과 같은 사용자 상호작용에 얼마나 빠르게 응답하는지를 측정하는 Core Web Vitals입니다. INP는 사용자 입력부터 JavaScript 처리, 화면의 최종 시각적 업데이트까지의 전체 지연 시간을 측정합니다. 75백분위수에서 200 밀리초 이하이면 좋은 INP 점수입니다. INP는 2024년 3월에 First Input Delay (FID)를 Core Web Vitals로서 대체했습니다.

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

Interaction to Next Paint (INP)는 사용자가 전체 방문 기간 동안 웹페이지의 응답성을 측정하는 Core Web Vitals 지표입니다. 첫 번째 상호작용의 이벤트 핸들러가 시작되기 전의 지연 시간만을 측정했던 이전 지표인 First Input Delay (FID)와 달리, INP는 사용자가 페이지와 수행하는 모든 상호작용을 평가하고 페이지의 전반적인 응답성을 나타내는 단일 값을 보고합니다.

사용자가 버튼을 클릭하거나, 링크를 탭하거나, 키보드의 키를 누르거나, 커스텀 컨트롤과 상호작용할 때마다, 브라우저는 입력 순간부터 다음 프레임이 화면에 그려질 때까지의 총 시간을 측정합니다. INP는 이러한 상호작용 중 가장 느린 것 중 하나를 페이지의 응답성 점수로 선택합니다. 총 상호작용 횟수가 50회 미만인 페이지의 경우, INP는 가장 느린 단일 상호작용을 보고합니다. 상호작용이 많은 페이지의 경우, INP는 간혹 발생하는 이상치를 필터링하기 위해 일반적으로 98백분위수를 사용합니다.

INP가 낮다는 것은 페이지가 사용자 입력에 적시에 안정적으로 응답함을 의미합니다. INP가 높다는 것은 브라우저가 상호작용을 처리하고 화면을 충분히 빠르게 업데이트할 수 없어 페이지가 느리고, 반응이 없거나, "버벅거린다(janky)"고 느껴짐을 의미합니다.

INP vs FID: 변경 사항 및 이유

INP는 2024년 3월에 공식적으로 First Input Delay (FID)를 Core Web Vitals로서 대체했습니다. Google은 FID가 페이지 응답성의 불완전한 척도가 되게 하는 두 가지 근본적인 한계를 가지고 있었기 때문에 FID를 폐기했습니다.

첫째, FID는 페이지에서의 첫 번째 상호작용만 측정했습니다. 사용자의 첫 번째 클릭이 빨랐지만 후속 상호작용이 느렸다면, 좋지 않은 경험에도 불구하고 FID는 통과 점수를 보고했습니다. INP는 세션 내내 모든 상호작용을 측정하여 실제 응답성에 대한 훨씬 더 정확한 그림을 제공합니다.

둘째, FID는 입력 지연(input delay) 단계만을 측정했는데, 이는 브라우저가 이벤트 처리를 시작하기 전에 대기하는 시간만을 측정했다는 뜻입니다. 이벤트 핸들러 코드를 실행하는 데 소요된 시간(처리 시간)과 시각적 결과를 화면에 그리는 데 필요한 시간(표시 지연)은 완전히 무시했습니다. INP는 세 가지 단계를 모두 포착하여 개발자에게 상호작용 지연 시간에 대한 완전한 뷰를 제공합니다.

HTTP Archive의 2025 Web Almanac에 따르면, FID에서 INP로의 전환은 모바일 Core Web Vitals 통과율에서 약 5% 포인트의 하락을 가져왔습니다. 이는 FID 하에서는 반응형으로 보였던 많은 사이트들이 INP가 포착하게 된 느린 후속 상호작용을 가지고 있었기 때문에 발생했습니다.

INP는 어떤 상호작용을 측정하나요?

INP는 이벤트 핸들러를 통해 브라우저가 관찰할 수 있는 개별 사용자 입력이 포함된 상호작용만을 측정합니다. 정확한 디버깅 및 최적화를 위해서는 어떤 상호작용이 계산되는지 이해하는 것이 필수적입니다.

INP에 포함되는 상호작용

• 마우스 클릭 (버튼, 링크, 체크박스, 커스텀 컨트롤 클릭 포함)
• 터치스크린 탭 (모바일 기기에서 클릭과 동일)
• 물리적 또는 화면 키보드의 키 누름 (입력 폼 타이핑, Enter 누르기, 키보드 단축키 사용 포함)

INP에 포함되지 않는 상호작용

• 스크롤은 브라우저의 컴포지터 스레드에 의해 처리되고 일반적으로 메인 스레드를 차단하지 않으므로 포함되지 않습니다
• 호버링 (mouseover)은 개별적인 사용자 상호작용이 아니라 연속적인 포인터 상태이므로 포함되지 않습니다
• 드래그 제스처는 포함되지 않지만, 드래그를 시작하는 초기 pointerdown은 INP 항목을 트리거할 수 있습니다
• 사용자 입력 없이 발생하는 CSS 전환 및 애니메이션은 상호작용이 아닙니다

흔한 오해 중 하나는 스크롤이 INP에 영향을 미친다는 것입니다. 그렇지 않습니다. 그러나 페이지에서 네이티브 브라우저 스크롤 대신 JavaScript 기반 스크롤을 사용하는 경우 해당 JavaScript 스크롤 핸들러가 브라우저가 상호작용으로 측정하는 이벤트 콜백을 트리거할 수 있습니다. 이것이 네이티브 CSS 스크롤이 응답성 측면에서 JavaScript 스크롤보다 지속적으로 뛰어난 성능을 발휘하는 이유 중 하나입니다.

INP 상호작용의 3단계

INP에 의해 측정되는 모든 상호작용은 세 개의 순차적인 단계로 구성됩니다. 총 INP 값은 이 세 단계의 합입니다. 각 단계마다 최적화 전략이 다르기 때문에 각 단계를 이해하는 것이 중요합니다.

1. 입력 지연 (Input Delay)

입력 지연은 사용자가 페이지와 상호작용할 때부터 브라우저가 관련된 이벤트 핸들러의 실행을 시작할 때까지의 시간입니다. 이 지연은 브라우저의 메인 스레드가 JavaScript 파싱, 이전에 예약된 작업 실행, 다른 이벤트 콜백 처리와 같은 다른 작업으로 인해 바쁠 수 있기 때문에 발생합니다.

입력 지연은 많은 스크립트가 동시에 파싱되고 실행되는 페이지 로딩 단계에서 특히 문제가 됩니다. CoreDash 데이터에 따르면 로딩 단계 중의 상호작용은 p75 INP가 132ms인 반면, 페이지 로드가 완료된 후의 상호작용은 50ms에 불과합니다. 이는 2.6배의 차이입니다. 페이지 시작 중에 메인 스레드 경합을 줄이는 것이 INP를 개선하는 가장 효과적인 방법 중 하나입니다.

중간값에서 입력 지연은 INP의 하위 요소 중 가장 작습니다. 그러나 메인 스레드의 긴 작업이 이벤트 처리를 수백 밀리초까지 지연시킬 수 있으므로 90백분위수에서 입력 지연은 지배적인 요인이 됩니다. HTTP Archive의 2025 Web Almanac에 따르면 웹사이트의 25% 미만만이 작업 소요 시간을 권장 50ms 기준 이하로 유지하는 것으로 나타났습니다.

2. 처리 시간 (Processing Time)

처리 시간은 브라우저가 상호작용과 관련된 모든 이벤트 핸들러 콜백을 실행하는 데 소요된 총 시간입니다. 여기에는 양식 유효성 검사, 상태 업데이트, 분석 추적 호출 등 이벤트에 응답하여 실행되는 모든 JavaScript가 포함됩니다.

처리 시간은 총 INP의 상당 부분을 차지합니다. 이벤트 핸들러가 값비싼 DOM 작업을 수행하거나, 동기식 API 호출을 하거나, 비효율적인 루프를 실행하면 처리 시간이 부풀려집니다. 처리 시간을 증가시키는 일반적인 패턴 중 하나는 핵심 시각적 업데이트와 동일한 이벤트 핸들러 내에서 비필수 코드(분석 이벤트 또는 서드파티 태그 콜백 등)를 실행하는 것입니다.

3. 표시 지연 (Presentation Delay)

표시 지연은 모든 이벤트 핸들러의 실행이 완료된 시점부터 브라우저가 시각적 업데이트가 포함된 다음 프레임을 표시할 때까지의 시간입니다. 이 단계에는 스타일 재계산, 레이아웃 계산, 페인팅 및 합성이 포함됩니다.

모든 상호작용에는 적어도 한 번의 렌더링 패스가 필요하기 때문에 중간값에서 표시 지연은 INP 하위 요소 중 가장 큽니다. DOM 크기가 크거나 깊게 중첩된 페이지는 스타일을 다시 계산하고 레이아웃을 수행하는 데 더 오랜 시간이 걸립니다. 상태 변경 후 대규모 컴포넌트 트리를 다시 렌더링하는 Single Page Application은 특히 높은 표시 지연에 취약합니다.

좋은 INP 점수와 나쁜 INP 점수는 무엇인가요?

Interaction to Next Paint 지표에 대한 Core Web Vitals 평가를 통과하려면, 필드에서 기록된 모든 상호작용의 75백분위수가 200 밀리초 미만을 유지해야 합니다:

• INP가 200 밀리초 이하인 경우 페이지의 응답성이 좋음을 의미합니다.
• INP가 200 밀리초에서 500 밀리초 사이인 경우 페이지의 응답성에 개선이 필요함을 의미합니다.
• INP가 500 밀리초 초과인 경우 페이지의 응답성이 나쁨을 의미합니다.

INP는 평균이 아닌 75백분위수를 사용한다는 점을 이해하는 것이 중요합니다. 이는 실제 사용자의 75%가 200ms보다 빠른 상호작용을 경험해야 함을 의미합니다. 75백분위수 방법론은 고급 하드웨어를 사용하는 사용자뿐만 아니라 느린 기기 및 연결 환경의 사용자 경험도 이 지표에 반영되도록 보장합니다.

Interaction to Next Paint (INP) 측정 방법

Interaction to Next Paint는 실제 사용자 상호작용을 포착하는 필드 도구로만 측정할 수 있습니다. 단일 페이지 로드를 시뮬레이션하는 랩 지표와 달리, INP는 실제 방문자가 페이지에서 클릭, 탭, 타이핑하는 작업이 필요합니다. INP는 실제 사람의 행동에 따라 달라지기 때문에 합성 테스트에서 의미 있는 INP 점수를 얻을 방법은 없습니다.

공식 INP 지표 얻기

PageSpeed Insights 또는 CrUX 대시보드 및 Google BigQuery에서 공식 INP 지표를 얻을 수 있습니다. PageSpeed Insights는 최근 28일간의 Chrome 사용자 데이터를 바탕으로 75백분위수 점수를 보고합니다. Google BigQuery는 더 많은 과거 컨텍스트를 제공하며 전체 CrUX 데이터 세트에 대한 맞춤형 쿼리를 허용합니다.

Google Search Console은 또한 Core Web Vitals 섹션에서 INP 문제를 보고하여, 영향을 받는 URL을 그룹화하고 개선이 필요하거나 응답성이 떨어지는 페이지에 플래그를 지정합니다.

Real User Monitoring으로 INP 추적하기

공식 CrUX 데이터 세트는 Core Web Vitals 점수에 대한 결정적인 소스이지만, 매우 익명화되어 있으며 실시간 모니터링이나 세부 필터링을 지원하지 않습니다. 이러한 이유로 웹 성능 전문가들은 CoreDash와 같은 Real User Monitoring (RUM) 도구에 의존하여 실용적이고 실시간인 INP 데이터를 얻습니다. RUM 도구는 모든 페이지 로드에서 INP 측정값을 수집하고, 이를 특정 요소, 로드 상태 및 기기 유형에 귀속시키며, 어떤 상호작용이 문제를 일으키는지 정확히 진단할 수 있게 해줍니다.

현재 세션의 INP 측정하기

개발 중에 INP를 디버깅하는 가장 간단한 방법은 Chrome DevTools를 이용하는 것입니다. 성능 패널을 열고 Lighthouse의 "timespan" 모드를 사용하여 상호작용을 기록하고 지연 시간을 확인하세요. 상호작용 시 페이지에 INP 점수를 오버레이하여 보여주는 Core Web Vitals Visualizer 확장 프로그램을 사용할 수도 있습니다.

실제 디버깅을 위해서는 Google Web Vitals JavaScript Library를 사용하여 개별 상호작용을 콘솔에 기록하세요:

Web Vitals JavaScript 라이브러리를 사용해 INP를 콘솔에 기록하기

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

Interaction to Next Paint 개선 방법

Interaction to Next Paint를 개선하려면 입력 지연, 처리 시간, 표시 지연의 세 가지 단계를 모두 최적화해야 합니다. 페이지가 대부분의 상호작용에 즉시 응답할 수 있지만 단 하나의 상호작용이라도 느리다면, 그것이 전체 INP 점수를 결정할 수 있습니다. 이것이 체계적인 접근 방식이 필요한 이유입니다.

PageSpeed 팁: 사용자가 페이지 로딩의 시작 단계 동안 페이지와 상호작용할 때 INP가 훨씬 더 나빠지는 경우가 많습니다. 그렇기 때문에 INP를 디버깅할 때 페이지 로드 상태와 함께 모든 상호작용을 기록하는 것이 좋습니다!

1. 입력 지연 최소화: 메인 스레드에서 긴 작업 방지

일반적으로 대부분의 메인 스레드 작업(파싱, 디코딩, 렌더링 및 스크립팅)이 일어나는 페이지 시작 단계에서는 어떤 페이지든 응답성이 떨어집니다. 메인 스레드를 최대한 여유롭게 유지하려면 다음을 수행하세요:

• 사용하지 않는 코드 제거. 트리 쉐이킹을 사용하여 데드 코드를 제거하고 코드 스플리팅을 사용하여 번들을 필요에 따라 로드되는 더 작은 청크로 나눕니다. Chrome DevTools를 사용하여 코드 커버리지를 감사하고 로드되지만 실행되지 않는 스크립트를 식별하세요.
• 브라우저 유휴 시간에 비필수 코드 로드. 페이지 로드의 첫 500ms 동안 정말로 채팅 위젯이 필요한가요? 브라우저가 유휴 상태일 때만 실행되도록 requestIdleCallback()으로 중요하지 않은 스크립트의 일정을 예약하세요.
• 과도한 CPU 리소스를 소비하는 느린 스크립트 식별 및 재작성. Chrome 성능 패널을 사용하여 실행 시간이 긴 스크립트를 찾아 최적화 대상으로 삼으세요.
• 페이지를 렌더링하기 쉽게 유지. 큰 DOM 크기, 과도한 이미지, 너무 많은 비디오 및 CPU 집약적인 CSS 애니메이션을 피하세요.
• 스크립트 태그에 async 및 defer 사용하여 JavaScript가 HTML 파서를 차단하지 않도록 방지하세요. 페이지가 상호작용 가능해질 때까지 비필수 JavaScript 지연을 완전히 고려하세요.

scheduler.yield()로 긴 작업 분할하기

JavaScript는 "run to completion" 모델을 사용하여 브라우저의 메인 스레드에서 실행됩니다. 즉, 작업이 시작되면 완료될 때까지 메인 스레드를 차단합니다. 긴 작업(50ms 이상)은 브라우저가 사용자 입력에 응답하지 못하게 합니다. scheduler.yield() API를 사용하면 오래 실행되는 코드 내에서 명시적으로 yield 포인트를 생성하여, 브라우저가 처리를 계속하기 전에 대기 중인 사용자 상호작용을 처리할 기회를 제공할 수 있습니다.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

requestIdleCallback으로 비필수 작업 지연하기

requestIdleCallback()을 사용하여 브라우저가 유휴 상태일 때 비필수 작업(분석, 원격 측정, 프리페치)의 일정을 예약하세요. 이는 사용자 상호작용을 위해 메인 스레드를 여유롭게 유지하고 입력 지연을 직접적으로 줄여줍니다.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Passive 이벤트 리스너 사용

preventDefault()를 호출할 필요가 없는 이벤트의 경우 이벤트 리스너를 passive로 표시하세요. 이는 기본 동작을 취소할지 여부를 결정하기 위해 브라우저가 핸들러를 기다릴 필요가 없음을 알려주어 스크롤을 더 부드럽게 하고 터치 반응을 더 빠르게 해줍니다.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. 처리 시간 최소화: 즉각적인 피드백 제공

방문자가 양식을 제출하거나 장바구니에 항목을 추가하는 등의 작업을 수행할 때 UI를 업데이트하기 전에 서버 측 확인을 기다리지 마세요. 즉각적인 시각적 피드백("양식 제출 중...", "장바구니에 항목 추가 중...")을 제공한 다음 백그라운드에서 작업을 완료하세요.

또한 핵심 시각적 업데이트 이후 가능한 한 빨리 메인 스레드로 yield하세요. JavaScript는 "run to completion" 모델을 따르기 때문에 콜백의 모든 코드가 실행될 때까지 메인 스레드를 차단합니다. 브라우저가 레이아웃을 업데이트한 다음 나머지 비필수 코드를 계속 실행할 수 있는 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. 표시 지연 최소화: 단순하게 유지하기

상호작용 후 페이지를 업데이트해야 할 때, 브라우저는 스타일을 다시 계산하고 레이아웃을 수행하고 변경된 픽셀을 그리고 결과를 합성해야 합니다. DOM의 복잡성과 크기가 이 렌더링 작업에 소요되는 시간을 직접적으로 결정합니다.

일부 최적화되지 않은 SPA 환경에서는 각 상호작용 후에 너무 많은 콘텐츠를 리렌더링합니다. 예를 들어, 카운터를 업데이트할 때 전체 컴포넌트 트리가 아닌 카운터 요소만 업데이트해야 합니다.

더 빠른 렌더링을 위해 다음 두 가지 황금률을 따르세요:

1. DOM을 작고 단순하게 유지하세요. 브라우저 입장에서는 DOM 구조가 복잡하게 중첩된 페이지보다 DOM 요소(HTML 노드) 수가 적은 페이지를 렌더링하는 것이 훨씬 쉽습니다. 총 DOM 요소 수는 1,400개 미만으로 유지하고 32 레벨 이상 중첩되는 것을 피하세요.
2. 화면 밖 콘텐츠를 지연 렌더링하려면 content-visibility를 사용하세요. content-visibility: auto CSS 속성은 사용자가 근처로 스크롤할 때까지 화면 밖 콘텐츠의 렌더링을 지연시킴으로써 초기 렌더링 속도를 높여줍니다.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Long Animation Frames (LoAF) API를 사용한 INP 디버깅

Long Animation Frames (LoAF) API는 INP 문제를 진단하기 위한 강력한 도구입니다. 이 API는 렌더링에 50ms 이상 걸리는 프레임에 대한 자세한 정보를 제공하며, 느린 상호작용에 영향을 주는 스크립트를 정확히 알려주는 스크립트 귀속 데이터를 포함합니다.

이전의 Long Tasks API와 달리, LoAF는 스크립트 실행 시간뿐만 아니라 렌더링 시간도 캡처하므로 표시 지연 문제를 진단하는 데 특히 유용합니다. LoAF 항목에는 프레임 지속 시간, 차단 기간, 그리고 프레임 중에 실행된 각 스크립트의 소스 URL, 함수 이름, 실행 시간을 보여주는 스크립트 항목 배열이 포함됩니다.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      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 점수를 초래하는지 정확히 식별할 수 있습니다.

INP와 LCP: 긴 작업의 연결성

메인 스레드의 긴 작업은 INP와 Largest Contentful Paint (LCP) 모두에 영향을 미칩니다. 메인 스레드를 200ms 동안 차단하는 JavaScript 작업은 이벤트 처리를 지연시키고(INP 악화) 브라우저가 LCP 요소를 렌더링하는 것을 지연시킵니다(LCP 악화). 긴 작업을 나누고, 비필수 JavaScript를 지연시키고, 스크립 실행 시간을 줄임으로써 메인 스레드를 최적화하면 두 지표를 동시에 향상시킬 수 있습니다.

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

redBus: 모바일 전환율 80~100% 개선

세계 최대 온라인 버스 티켓팅 플랫폼 중 하나인 redBus는 글로벌 시장 전반에 걸쳐 Core Web Vitals 최적화에 투자했습니다. JavaScript 실행 시간을 줄이고 이벤트 핸들러를 최적화하는 데 중점을 둔 결과 글로벌 시장에서 모바일 전환율이 80~100% 향상되었습니다. 이러한 개선은 메인 스레드 차단 시간을 줄이고, 서드파티 스크립트 로딩을 최적화하며, 페이지 시작 시 구문 분석되는 JavaScript의 양을 줄이기 위한 코드 스플리팅을 구현한 결과로 이루어졌습니다.

Preply: INP 250ms에서 185ms로 개선, 연간 약 20만 달러의 SEO 가치 절감 효과

온라인 언어 튜터링 플랫폼인 Preply는 홈페이지 INP를 약 250ms에서 185ms로, 검색 페이지 INP를 약 250ms에서 175ms로 개선했습니다. 팀은 React 애플리케이션을 프로파일링하고, 불필요한 리렌더링을 식별 및 제거하며, 중요하지 않은 이벤트 콜백을 지연시킴으로써 이러한 성과를 달성했습니다. 개선된 Core Web Vitals 점수는 더 높은 검색 순위와 연관되었으며, 이는 유기적 검색 가치로 환산할 때 연간 약 20만 달러에 달합니다.

실제 데이터가 보여주는 INP의 실태

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

CoreDash 데이터에 따르면 모바일 INP(p75에서 131ms)는 데스크톱 INP(p75에서 48ms)보다 2.8배 더 나쁩니다. 이는 모든 Core Web Vitals 지표 중에서 가장 큰 기기 격차입니다. 모바일 기기는 프로세서가 느리고 메모리가 적으며 네트워크 지연 시간이 더 길어 메인 스레드 차단 시간이 길어지고 이벤트 처리가 느려집니다. 데스크톱에서는 상호작용의 95.6%가 "좋음" INP 점수를 달성하지만, 모바일에서는 이 수치가 88.0%로 떨어집니다. 모바일 사용자는 "나쁨" INP 이벤트(9.6% 대 1.9%)도 5배 더 많이 경험합니다.

키보드 대 포인터 상호작용

CoreDash 데이터에 따르면 키보드 상호작용(p75 75ms)은 포인터 상호작용(p75 49ms)보다 56% 더 느립니다. 키보드 이벤트는 나쁜 경험을 훨씬 더 많이 초래합니다. 키보드 상호작용의 7.4%가 나쁜 INP를 초래하는 반면, 포인터 상호작용은 1.4%에 불과합니다. 이 격차는 특히 양식 입력 필드에서 키보드 이벤트가 입력 유효성 검사, 자동 완성 제안, 상태 업데이트와 같은 더 복잡한 처리를 트리거하기 때문일 가능성이 큽니다.

로드 중 상호작용 대 로드 후 상호작용

페이지 로드 중 발생하는 상호작용은 페이지가 완전히 로드된 후의 상호작용보다 INP가 극적으로 높습니다. CoreDash 데이터에 따르면 "loading" 단계 중의 상호작용은 p75 INP가 132ms인 반면 로드 후 상호작용은 50ms에 불과합니다. 이는 2.6배의 차이입니다. "dom-content-loaded" 단계 중의 상호작용(75ms)조차도 비동기 스크립트 및 하위 리소스가 계속 처리되고 있으므로 높은 INP를 보입니다. 이 데이터는 페이지 시작 중에 메인 스레드 경합을 줄이기 위해 비필수 JavaScript 지연을 권장하는 이유를 강력하게 뒷받침합니다.

글로벌 INP 통과율

HTTP Archive의 2025 Web Almanac에 따르면 전체 모바일 페이지의 77%가 "좋음" INP 점수를 달성했습니다(2022년의 55%에서 증가). 그러나 방문자가 가장 많은 상위 1,000개 웹사이트 중 53%만이 INP를 통과합니다. 트래픽이 많은 웹사이트는 더 복잡한 JavaScript, 더 많은 서드파티 스크립트, 그리고 더 복잡한 DOM 구조를 갖는 경향이 있으며, 이 모든 것이 응답성을 악화시킵니다. 데스크톱에서는 97%의 페이지가 좋은 INP 점수를 달성하여 엄청난 모바일-데스크톱 간의 성능 격차를 강조합니다. 랩 테스트의 중간 Total Blocking Time은 데스크톱에서 67ms이지만 모바일에서는 1,209ms입니다.

자주 묻는 질문 (FAQ)

관련 가이드

이 허브 페이지는 Interaction to Next Paint의 기초를 다룹니다. INP 최적화의 특정 측면에 대한 심층적인 가이드는 다음 전용 기사를 살펴보세요:

• <strong>INP 문제 찾기 및 해결하기</strong>: Search Console, RUM 데이터 및 Chrome DevTools를 사용하여 어떤 상호작용이 가장 나쁜 INP 점수를 유발하는지 정확히 식별하는 단계별 진단 방법론입니다.
• <strong>INP 입력 지연</strong>: INP의 첫 번째 단계를 다룹니다. 메인 스레드의 긴 작업이 이벤트 처리를 차단하는 방식과 작업 스케줄링, 코드 스플리팅 및 Web Worker를 통해 입력 지연을 최소화하는 방법을 알아보세요.
• <strong>INP 처리 시간</strong>: INP의 두 번째 단계를 다룹니다. 이벤트 핸들러 콜백을 최적화하고, 중요 코드의 우선순위를 지정하고, 비필수 작업을 지연시키고, React 동시성 기능을 사용하여 처리 시간을 줄이는 방법을 알아보세요.
• <strong>INP 표시 지연</strong>: INP의 세 번째 단계를 다룹니다. DOM 크기, 레이아웃 스래싱 및 클라이언트 사이드 렌더링이 시각적 업데이트 지연에 미치는 영향과 표시 지연을 줄이는 방법을 알아보세요.

INP 개선에 도움이 되는 다음 PageSpeed 최적화 가이드도 참고해 보세요:

• INP 개선: JavaScript 스크롤 폐기하기
• Async vs Defer: JavaScript 로딩 전략
• JavaScript를 지연시키는 14가지 방법
• 완벽한 Core Web Vitals를 갖춘 채팅 위젯
• 해결: 과도한 DOM 크기 방지