구글이 페이지 반응 속도를 재는 지표 INP(Interaction to Next Paint)를 Core Web Vitals에 넣은 지 1년 반이 넘었다. Core Web Vitals는 구글이 페이지 경험을 평가할 때 쓰는 핵심 지표 묶음으로, 로딩 속도를 재는 LCP, 화면이 밀리는 정도를 재는 CLS, 그리고 반응성을 재는 INP로 이뤄진다. INP는 2024년 3월 12일 기존 반응성 지표였던 FID(First Input Delay)를 대신해 정식 지표가 됐다. 구글 크롬팀이 운영하는 개발자 사이트 web.dev가 그해 1월 31일 이 일정을 공지했다.

LCP는 이미지 용량이나 서버 응답을 손보면 개선되는 경우가 많다. INP는 사정이 다르다. 클릭 뒤 화면이 늦게 바뀌는 원인은 대부분 브라우저 안에서 돌아가는 자바스크립트에 있어서, 개발팀이 코드를 직접 들여다봐야 한다.

INP가 재는 것과 합격 기준

web.dev 설명에 따르면 INP는 방문자가 페이지에 머무는 동안 일어난 클릭, 탭, 키보드 입력을 모두 관찰하고, 입력 뒤 화면에 다음 장면이 그려지기까지 걸린 시간을 잰다. 첫 입력 하나만 보던 FID와 가장 크게 다른 점이다. 대부분의 사이트에서는 가장 느렸던 상호작용의 값이 그 페이지의 INP가 된다. 상호작용이 많은 페이지라면 50번마다 가장 느린 값 하나를 빼서 우연한 지연이 결과를 흔들지 않게 한다.

합격선은 200ms다. 실제 방문 기록의 75번째 백분위수, 즉 방문 100건을 빠른 순서로 세웠을 때 75번째 값이 200ms 이하면 '양호'다. 200ms 초과 500ms 이하는 '개선 필요', 500ms를 넘으면 '불량'으로 분류된다.

검색 순위와의 관계는 구글 문서가 밝힌 범위에서만 보는 게 맞다. 구글 검색 센터의 Core Web Vitals 문서는 이 지표가 "핵심 순위 시스템이 보상하려는 방향과 맞는다"고 적었다. 같은 검색 센터의 페이지 경험 문서는 서치 콘솔이나 외부 도구에서 좋은 결과를 얻어도 상위 노출이 보장되지는 않는다고 밝혔다. 페이지 경험이 다소 떨어져도 가장 관련성 높은 콘텐츠를 보여 준다는 것이 구글의 설명이다.

서치 콘솔에서 느린 페이지 묶음부터 찾는다

진단은 구글 서치 콘솔의 Core Web Vitals 보고서에서 시작한다. 이 보고서는 크롬 사용자 경험 보고서(CrUX)에 쌓인 실제 크롬 이용자의 익명 성능 데이터를 쓴다. 비슷한 구조의 URL을 하나의 그룹으로 묶고, 그룹 안에서 가장 나쁜 지표의 상태를 그룹 전체의 상태로 표시한다. 방문 데이터가 적은 URL은 도메인 전체 값으로 대신 보여 준다.

web.dev의 INP 최적화 가이드도 실험실 테스트보다 실제 방문 데이터를 먼저 보라고 권한다. 어느 페이지의 어떤 동작이 느린지 확인한 뒤, 크롬 개발자 도구(DevTools)의 성능 패널에서 그 동작을 재현해 원인을 찾는 순서다. 상품 상세나 장바구니처럼 매출과 바로 닿는 템플릿이 '개선 필요' 그룹에 들어가 있다면 그 템플릿부터 손보는 편이 효과가 크다.

느려지는 구간은 세 군데다

web.dev는 상호작용 하나를 세 구간으로 나눈다. 사용자가 누른 순간부터 이벤트 처리 코드가 실행되기 시작할 때까지의 입력 지연, 처리 코드가 실제로 실행되는 처리 시간, 결과 화면이 그려지기까지의 표시 지연이다.

입력 지연은 메인 스레드가 다른 일로 바쁠 때 생긴다. 메인 스레드는 브라우저가 스크립트 실행, 화면 그리기, 입력 처리를 한 줄로 처리하는 작업 통로다. 페이지를 여는 동안 스크립트를 해석하고 실행하는 작업이 길어지면 사용자의 클릭은 그만큼 기다린다. 분석 태그, 상담 채팅 위젯, 광고 픽셀처럼 외부 업체가 제공하는 서드파티 스크립트도 같은 메인 스레드에서 실행되므로 점검 대상에 들어간다.

처리 시간에 대한 web.dev의 조언은 짧다. 이벤트 처리 코드에서 "가능한 한 적은 일을 하라"는 것이다. 메인 스레드를 50ms 넘게 붙잡는 작업은 긴 작업(long task)이라고 부른다. 긴 작업은 여러 조각으로 나누고, 조각 사이마다 브라우저가 입력을 처리할 틈을 줘야 한다. web.dev는 이를 '메인 스레드에 양보한다'고 표현하며, 지원하는 브라우저에서는 scheduler.yield()를, 그렇지 않은 환경에서는 setTimeout을 쓰라고 안내한다. 한때 쓰이던 isInputPending()은 이제 권하지 않는다고 적었다.

표시 지연은 화면 구조와 관련이 있다. 페이지를 이루는 요소의 구조인 DOM이 클수록 화면을 다시 그리는 데 드는 일이 많아진다. 요소 수를 줄이거나, 화면 밖 영역의 렌더링을 뒤로 미루는 CSS 속성 content-visibility를 쓰는 방법이 가이드에 소개돼 있다.

고칠 순서는 매출 기여로 정한다

코드 수정은 개발팀 몫이지만, 무엇부터 고칠지는 마케팅팀이 함께 정할 수 있다. 서치 콘솔에서 '개선 필요'나 '불량'으로 분류된 URL 그룹을 뽑고, 각 그룹이 매출이나 문의에 얼마나 기여하는지 붙여 보면 작업 순서가 나온다.

태그 관리 도구에 쌓인 마케팅 태그도 직접 정리할 수 있다. 끝난 캠페인의 픽셀이나 같은 데이터를 두 번 보내는 분석 태그가 남아 있다면, 개발팀에 요청하기 전에 마케팅팀이 먼저 걷어 낼 수 있는 부분이다. 다만 INP가 좋아졌다고 순위가 곧바로 오르리라고 기대할 일은 아니다. 구글이 문서에 직접 적어 둔 내용이다.