- 01기준클릭 뒤 다음 화면까지 200밀리초 이하면 양호입니다.
- 02찾기현장 데이터로 느린 상호작용을 먼저 특정합니다.
- 03고치기입력 지연·처리 시간·표시 지연을 나눠서 줄입니다.
INP가 「느림」이면 Search Console의 느린 그룹부터 고릅니다. 이어서 현장 데이터로 느린 상호작용을 찾고, 세 구간 중 긴 곳부터 손봅니다. INP는 한 번의 로딩이 아니라 방문 내내의 반응을 재는 지표라 순서가 중요합니다. 근거는 web.dev의 INP 문서와 Search Console 도움말입니다. 문서에 없는 운영 판단은 넥스트티 판단임을 밝혀 둡니다.
INP는 무엇을 재고, 언제 「느림」인가요?
INP는 클릭·탭·키 입력 뒤 다음 화면이 그려지기까지 걸린 시간입니다. 방문 중 일어난 상호작용 가운데 가장 느린 것이 대체로 그 페이지의 값이 됩니다. 상호작용이 많은 페이지는 50개마다 최댓값 1개를 이상값으로 빼고 계산합니다.
스크롤, 마우스 올림, 확대·축소는 INP 측정 대상이 아닙니다. 판정은 실제 방문 기록의 75번째 백분위수로 하며, 모바일과 데스크톱은 따로 판정합니다.
출처: web.dev 「다음 페인트에 대한 상호작용(INP)」 · Search Console 도움말 「Core Web Vitals 보고서」
| INP 값 | Search Console 상태 |
|---|---|
| 200밀리초 이하 | 빠름(양호) |
| 200 초과 500밀리초 이하 | 개선이 필요함 |
| 500밀리초 초과 | 느림 |
INP는 네트워크 응답까지 기다리는 시간을 재지 않습니다. 다음 화면에 첫 시각적 반응이 나타나기까지 막힌 시간을 잽니다. 세 지표 전체 개요는 Core Web Vitals 실무 가이드에 정리해 두었습니다.
Search Console에서는 어디부터 보나요?
Core Web Vitals 보고서에서 기기별로 「느림」 그룹부터 엽니다. 보고서는 비슷한 페이지를 URL 그룹으로 묶어 상태를 매깁니다. 그룹 INP는 지난 28일 동안 방문의 75%가 겪은 값입니다.
그룹 안의 URL은 노출수가 많은 순서로 나옵니다. 위쪽 URL일수록 그룹 상태에 주는 영향이 큽니다. 문서는 「느림」을 먼저 고르라고 권합니다. 그다음은 URL이 많거나 중요한 URL에 걸린 문제입니다.
- 그룹 상태는 LCP·INP·CLS 가운데 가장 나쁜 지표를 따릅니다.
- LCP와 CLS 데이터가 모자란 그룹은 보고서에 나오지 않습니다.
- PageSpeed Insights는 개별 URL 값이라 그룹 값과 다를 수 있습니다.
어떤 상호작용이 느린지 어떻게 찾나요?
현장 데이터에서 INP 값을 만든 상호작용을 특정합니다. web.dev 문서는 INP 개선을 현장 데이터에서 시작하라고 권합니다. 실험실에서 아무 버튼이나 눌러 보면 엉뚱한 곳을 고치기 쉽습니다.
PageSpeed Insights는 CrUX(Chrome 사용자 경험 보고서)로 문제 여부를 보여 줍니다. 하지만 어떤 요소가 원인인지까지는 짚어 주지 못합니다. 원인까지 보려면 실제 사용자 모니터링(RUM)으로 자체 데이터를 모아야 합니다.
출처: web.dev 「필드에서 느린 상호작용 찾기」
| 도구 | 알 수 있는 것 |
|---|---|
| PageSpeed Insights | 페이지·출처의 INP 수준 |
| Search Console | 페이지 유형별 그룹 상태 |
| web-vitals 기여 분석 빌드 | 느린 요소와 세 구간 시간 |
| LoAF 항목 | 지연을 만든 스크립트 |
web-vitals 라이브러리의 기여 분석 빌드는 상호작용 대상 요소를 알려 줍니다. 페이지 로드 중이었는지도 함께 남습니다. 여기에 긴 애니메이션 프레임(LoAF) 정보를 더하면 원인 스크립트까지 좁혀집니다.
실험실에서는 어떻게 재현하나요?
현장 데이터로 찾은 상호작용을 Chrome DevTools에서 그대로 재현합니다. 성능 패널의 실시간 측정항목 화면에서 버튼을 눌러 보면 상호작용별 지연이 기록됩니다. 느린 상호작용이 보이면 성능 프로파일러로 녹화합니다.
1. 조건 맞추기
CPU 제한을 켜거나 중저가 휴대폰을 연결합니다.
2. 로드 중 누르기
페이지가 다 뜨기 전에 버튼을 누릅니다.
3. 트랙 읽기
상호작용 트랙과 기본 스레드 작업을 맞춰 읽습니다.
현장 데이터가 없다면 Lighthouse의 총 차단 시간(TBT)을 참고합니다. TBT는 로드 중 반응성을 재는 실험실 지표로 INP와 상관관계를 보입니다. 다만 INP를 대신하지는 못하므로, 주요 사용자 흐름을 직접 눌러 봐야 합니다.
세 구간은 각각 어떻게 줄이나요?
상호작용 최적화 문서는 상호작용 하나를 세 구간으로 나눕니다. 세 구간의 합이 그 상호작용의 지연 시간입니다. 프로파일러에서 가장 긴 구간을 먼저 다룹니다.
출처: web.dev 「다음 페인트에 대한 상호작용 최적화」 · 「장기 작업 최적화」
| 구간 | 주된 원인 | 대응 |
|---|---|---|
| 입력 지연 | 진행 중인 긴 작업 | 긴 작업 줄이기 |
| 처리 시간 | 무거운 이벤트 콜백 | 작업 분할·지연 실행 |
| 표시 지연 | 렌더링 작업량 | DOM 크기 줄이기 |
장기 작업 최적화 문서는 50밀리초 이상 걸리는 작업을 긴 작업으로 봅니다. 긴 작업이 기본 스레드를 붙잡고 있으면 입력이 처리되지 못하고 기다립니다. 처리 시간을 줄일 때는 다음 화면에 필요한 일만 먼저 하고 나머지는 미룹니다.
function onClick(e) {
show(e); // 화면 먼저
// 나머지는 다음 프레임 뒤로
requestAnimationFrame(
() => setTimeout(save, 0)
);
}web.dev 예제를 줄인 설명용 코드입니다.
긴 작업을 나눌 때는 scheduler.yield()로 기본 스레드에 양보할 수 있습니다. 이 API는 아직 모든 브라우저가 지원하지 않으므로 setTimeout 대체 코드를 함께 둡니다. 표시 지연은 페이지 요소 수(DOM 크기)를 줄여 낮춥니다. CSS content-visibility로 화면 밖 요소의 렌더링을 늦추는 방법도 씁니다.
고친 뒤에는 어떻게 확인하나요?
실험실에서 개선을 확인한 뒤 배포하고 Search Console에서 수정 확인을 시작합니다. 문제 세부정보 페이지의 「추적 시작」을 누르면 28일 모니터링이 시작됩니다. 그 기간에 문제가 다시 나오지 않으면 해결로 처리됩니다.
「추적 시작」은 색인을 다시 요청하는 기능이 아닙니다. 현장 데이터 모니터링 기간을 새로 여는 것뿐입니다. 배포 직후 보고서 숫자가 그대로여도 집계 기간이 지나기를 기다립니다.
INP 개선은 한 번에 끝나지 않는 경우가 많습니다. 느린 상호작용 하나를 고치면 그다음으로 느린 것이 드러납니다. 크롤링·색인과 함께 점검 우선순위를 정하는 방법은 기술 SEO 실무 점검 글에 담았습니다.
- 고칠 상호작용은 현장 데이터에서 노출이 많은 페이지부터 고릅니다.
- 외부 위젯·태그는 넣기 전에 상호작용 지연을 재 보고 결정합니다.
- 배포 날짜와 수정 내용을 적어 두고 모니터링이 끝난 뒤 그룹 값과 대조합니다.
참고 자료
- web.dev — 다음 페인트에 대한 상호작용(INP)
- web.dev — 다음 페인트에 대한 상호작용 최적화
- web.dev — 필드에서 느린 상호작용 찾기
- web.dev — 실습에서 느린 상호작용 수동으로 진단
- web.dev — 장기 작업 최적화
- Search Console 도움말 — Core Web Vitals 보고서
- Google 검색 센터 — Core Web Vitals 및 Google 검색결과 이해하기
