Core Web Vitals의 INP가 '개선 필요'로 나올 때, 무엇부터 볼까요?

서치콘솔의 Core Web Vitals 보고서에서 "INP 문제: 200ms 초과" 같은 알림을 받으면 무엇을 고쳐야 할지 막막합니다. INP는 이미지 용량을 줄이는 것만으로는 잘 해결되지 않는 지표라 원인을 찾는 순서가 중요합니다. 이 글은 web.dev와 구글 검색 센터 문서를 바탕으로 점검 순서를 정리합니다.

INP는 무엇을 재나요?

INP(Interaction to Next Paint)는 사용자가 클릭·탭·키 입력을 한 뒤 화면에 그 결과가 보이기까지 걸린 시간을 잽니다. 페이지를 쓰는 동안 일어난 상호작용을 지켜보고, 그중 가장 느린 축에 속하는 값을 그 페이지의 INP로 봅니다.

INP는 2024년 3월 12일부터 FID(First Input Delay)를 대신해 Core Web Vitals 지표가 되었습니다. FID가 첫 입력의 대기 시간만 봤다면, INP는 페이지를 쓰는 내내 화면이 실제로 반응하기까지를 봅니다.

평가는 실제 방문자 데이터의 75번째 백분위수 기준입니다. 방문자 4명 중 3명이 이 값 이하로 경험한다는 뜻이라, 일부 느린 기기의 경험도 결과에 반영됩니다.

반응이 늦어지는 원인은 어디서 생기나요?

한 번의 상호작용 시간은 세 부분으로 나뉩니다. 어느 부분이 긴지에 따라 고칠 곳이 다릅니다.

세 구간 모두 공통 원인은 브라우저의 메인 스레드가 한 번에 한 작업만 처리한다는 점입니다. web.dev는 50ms를 넘는 작업을 긴 작업(long task)으로 부르고, 이런 작업이 도는 동안에는 사용자 입력이 처리되지 못한다고 설명합니다.

어떤 순서로 원인을 찾나요?

느린 페이지 묶음을 먼저 찾고, 그 페이지에서 느린 동작을 직접 재현하는 순서로 갑니다.

1. 서치콘솔 Core Web Vitals 보고서에서 INP 문제가 있는 URL 묶음과 대표 URL을 확인합니다. 모바일과 데스크톱을 따로 봅니다.
2. 대표 URL에서 사용자가 실제로 하는 동작을 적어 봅니다. 메뉴 열기, 탭 전환, 필터 선택, 상담 신청서 입력 같은 것들입니다.
3. 크롬 개발자 도구의 성능(Performance) 패널로 그 동작을 녹화합니다. 사양이 낮은 휴대폰 환경을 흉내 내려면 CPU 속도를 낮춰 놓고 녹화합니다.
4. 녹화 결과에서 긴 작업을 찾고, 그 작업이 어떤 스크립트에서 나왔는지 확인합니다. 우리 코드인지, 외부 위젯·광고·분석 스크립트인지 나눕니다.
5. 세 구간 중 어디가 긴지 보고 아래 해결 방법을 고릅니다.

원인별로 무엇을 고치나요?

긴 작업을 쪼개거나, 급하지 않은 일을 뒤로 미루는 것이 기본입니다.

작업을 쪼갤 때 쓰는 대표적인 방법이 메인 스레드에 차례를 넘기는(yield) 것입니다. 예전에는 setTimeout으로 남은 일을 다음 차례로 넘겼고, 지금은 이 용도로 만든 scheduler.yield()를 지원하는 브라우저도 있습니다. 지원하지 않는 브라우저를 위해 대체 방법을 함께 두는 것이 안전합니다.

// 예시: 상담 신청 버튼을 누르면 '접수 중' 표시를 먼저 그리고, 무거운 일은 그 뒤로 미룬다
button.addEventListener('click', async () => {
  showSubmitting();               // 사용자에게 바로 보여야 하는 변화
  await yieldToMain();            // 브라우저가 화면을 먼저 그리도록 차례를 넘김
  sendAnalytics();                // 급하지 않은 일
  validateAndSend();
});

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

고친 뒤에는 어떻게 확인하나요?

실험실 측정으로 먼저 확인하고, 실제 사용자 데이터로 최종 확인합니다. 둘은 역할이 다릅니다.

• 같은 동작을 같은 조건(CPU 속도 낮춤)으로 다시 녹화해 긴 작업이 줄었는지 본다
• 페이지를 배포한 뒤 서치콘솔 보고서에서 해당 URL 묶음의 '수정 확인'을 시작한다
• 실제 사용자 데이터가 새로 쌓일 때까지 기다린다 (서치콘솔 데이터는 지난 기간의 실제 방문 기록을 모아 계산하므로 바로 바뀌지 않음)
• 상담 신청 같은 핵심 동작이 여전히 정상 작동하는지 함께 확인한다

INP를 고치는 것이 AI 검색과도 관계가 있나요?

간접적인 관계로 보는 것이 정확합니다. 구글은 AI 기능에 나오는 데에도 검색 전반의 기본 원칙을 적용하라고 안내하며, 그 목록에 좋은 페이지 경험을 포함합니다. 다만 INP를 고친다고 AI 답변에 바로 인용된다는 근거는 없습니다.

현실적인 효과는 이렇습니다. AI 답변의 출처 링크를 눌러 들어온 방문자는 이미 답을 일부 읽은 상태라, 페이지가 답답하면 상담 신청까지 가지 않고 떠나기 쉽습니다. INP 개선은 그 마지막 단계에서 이탈을 줄이는 일입니다. 퍼스트초이스 무료 진단 도구의 31개 점검 항목에도 속도 영역이 포함되어 있어, 큰 문제가 있는지 먼저 확인하는 데 쓸 수 있습니다.

참고 자료

• Interaction to Next Paint (INP) web.dev
• Interaction to Next Paint becomes a Core Web Vital on March 12 web.dev · 2024
• Optimize Interaction to Next Paint web.dev
• Optimize long tasks web.dev
• Understanding Core Web Vitals and Google search results Google Search Central

자주 묻는 질문