모바일 환경에서 Core Web Vitals를 최적화해 INP를 어떻게 낮출 수 있나요?

모바일 INP를 개선할 때 핵심은 페이지 다운로드 속도를 높이는 것이 아니라, 클릭, 터치, 키보드 입력 후 브라우저가 다음 프레임을 최대한 빨리 표시하도록 하는 것입니다. 이미지 압축과 CDN 도입은 로딩 경험을 개선할 수 있지만, 버튼을 클릭한 뒤 반응이 늦어지는 문제를 직접 해결하지는 못합니다. 메인 스레드가 스크립트 실행이나 페이지 렌더링에 점유되어 있으면 상호작용은 여전히 지연될 수 있습니다.

Core Web Vitals를 기준으로 모바일 경험을 개선하려면 INP를 입력 지연, 이벤트 처리 시간, 표시 지연으로 나눈 뒤 각 시간의 원인을 해결해야 합니다. 클릭 콜백 시간만 줄이거나 실험실 점수 한 번을 높이는 것만으로는 실제 사용자의 상호작용 응답성이 개선되었다고 볼 수 없습니다.

INP는 상호작용부터 다음 프레임까지 측정하며, 업무 완료 시간은 측정하지 않습니다

INP, 즉 다음 페인트까지의 상호작용은 페이지 수명 주기 동안 조건을 충족하는 클릭, 터치, 키보드 상호작용을 관찰하고, 가장 느린 상호작용에 가까운 응답 성능을 보여 줍니다. 상호작용이 많을 경우 규칙에 따라 일부 극단값을 제외하고 계산하므로 모든 클릭 시간의 평균이나 절대 최댓값으로 단순하게 이해해서는 안 됩니다.

Google의 Core Web Vitals 평가에서 INP가 200밀리초 이하면 ‘양호’, 200밀리초 초과 500밀리초 이하면 ‘개선 필요’, 500밀리초를 초과하면 ‘나쁨’입니다. 사이트의 기준 충족 여부는 실제 방문 데이터의 75번째 백분위수를 기준으로 판단하며 모바일과 데스크톱을 각각 평가합니다. 이는 한 번의 페이지 방문에서 대표 상호작용을 선정하는 것과는 서로 다른 통계 수준입니다.

INP는 API 응답 시간도 아닙니다. 문의를 제출한 직후 ‘제출 중’ 상태를 표시하고 네트워크 요청이 나중에 완료된다면, 해당 상호작용의 INP는 낮을 수 있습니다. 그러나 낮은 INP가 업무의 성공을 뜻하지는 않으므로 요청 시간, 실패율, 중복 제출을 별도로 모니터링해야 합니다.

먼저 어느 구간이 느린지 파악한 뒤 개선 방법을 결정합니다

상호작용의 입력 지연은 사용자의 동작부터 이벤트 콜백 실행이 시작될 때까지의 대기 시간입니다. 처리 시간은 관련 콜백 실행에 걸리는 시간이고, 표시 지연은 콜백 종료부터 다음 프레임이 표시될 때까지의 시간입니다. 세 구간 모두 모바일에서 병목이 될 수 있습니다.

사용자가 클릭했을 때 메인 스레드가 스크립트 파싱, 서드파티 코드 실행 또는 다른 작업 처리 중이면 입력 지연이 늘어납니다. 콜백에서 많은 제품을 동기적으로 필터링하거나 전체 양식을 검증하거나 많은 컴포넌트를 업데이트하면 처리 시간이 늘어납니다. 콜백이 끝난 후 광범위한 스타일 계산, 레이아웃, 페인팅이 이어지면 표시 지연이 커집니다.

Chrome DevTools의 성능 패널에서 메뉴 열기, 제품 필터링, 사양 변경, 문의 제출 등의 작업을 기록하고, 상호작용 트레이스에서 메인 스레드 작업과 렌더링 활동을 확인할 수 있습니다. 50밀리초를 초과하는 작업은 장기 작업이지만, 이는 문제를 찾기 위한 단서일 뿐입니다. 여러 개의 짧은 작업이 연속되더라도 페인팅이 지연될 수 있으므로, ‘장기 작업이 없다’는 사실만으로 INP 기준을 충족했다고 판단할 수는 없습니다.

스크립트를 단순히 늦추기보다 차단을 줄이는 것이 중요합니다

입력 지연이 높다면 사용자가 조작을 시작한 뒤 스크립트가 한꺼번에 실행되는지 확인해야 합니다. 마케팅 웹사이트의 온라인 고객 지원, 통계 태그, 광고 추적, 팝업 컴포넌트는 로딩 시간과 실행 비용을 항목별로 점검해야 합니다. async 또는 defer를 사용하면 스크립트의 로드 및 실행 시점을 바꿀 수 있지만, 실행 중 메인 스레드를 점유하는 문제까지 없애지는 못합니다.

필수적이지 않은 스크립트는 페이지 용도, 동의 상태 또는 실제 사용 요구에 따라 로드하고 중복 태그를 정리할 수 있습니다. 지연 로딩을 적용할 때도 모든 스크립트를 첫 클릭 시점에 한꺼번에 실행하지 않도록 해야 합니다. 그렇게 하면 로딩 비용을 상호작용 경로로 옮기는 데 그칩니다.

동기 계산은 여러 묶음으로 나누어 처리하고, 각 묶음 사이에 메인 스레드가 다른 작업을 수행할 수 있도록 해야 합니다. 지원되는 브라우저에서는 scheduler.yield()를 사용할 수 있으며, 그 외 환경에서는 대체 방법이 필요합니다. Promise나 queueMicrotask만으로 작업을 분할하는 것은 신뢰할 수 없습니다. 마이크로태스크 큐가 페인팅 전에 계속 실행될 수 있기 때문입니다. CPU를 많이 사용하면서 DOM에 의존하지 않는 계산은 Web Worker로 옮길 수 있지만, 통신 및 데이터 복사에 드는 비용을 고려해야 합니다.

이벤트 콜백과 렌더링을 함께 줄여야 합니다

클릭 콜백에서는 로딩 상태 표시, 현재 선택 항목 표시, 중복 제출 방지 등 필요한 상태 변경을 우선 처리한 다음, 긴급하지 않은 작업을 예약해야 합니다. 먼저 화면을 수정한 뒤 동기 계산을 계속 실행한다고 해서 사용자가 이미 피드백을 확인했다는 뜻은 아닙니다. 브라우저가 페인팅할 기회를 얻어야 합니다.

제품 필터링에서는 계산 결과를 캐시해 상호작용마다 전체 데이터를 반복해서 순회하지 않도록 할 수 있습니다. 양식 검증 시에는 문자를 입력할 때마다 양식 전체를 다시 계산하지 않도록 해야 합니다. 디바운스는 즉각적인 응답이 필요 없는 검색을 줄이는 데 적합하지만, 버튼의 시각적 피드백을 늦추거나 필수 작업의 지연을 감추는 데 사용해서는 안 됩니다.

표시 지연이 높다면 DOM 규모, 스타일 영향 범위, 컴포넌트 업데이트 경계를 확인해야 합니다. 긴 제품 목록에는 가상화를 적용할 수 있지만, 접근성과 검색 크롤링 요구 사항도 함께 고려해야 합니다. 스타일을 반복해서 ‘쓰기—크기 읽기’하면 강제 레이아웃이 발생할 수 있으므로, 읽기를 먼저 모아서 처리한 뒤 쓰는 것이 좋습니다. 프레임워크 기반 애플리케이션에서는 콜백 시간만 측정할 것이 아니라, 일부 상태 변경으로 관련 없는 컴포넌트까지 업데이트되는지도 확인해야 합니다.

requestAnimationFrame도 시간이 오래 걸리는 작업을 담아 두는 곳은 아닙니다. 그 안의 코드는 페인팅 전에 실행되므로, 계산을 많이 넣으면 다음 프레임을 여전히 차단합니다.

한 번의 테스트만 보지 말고 실제 방문 데이터로 확인합니다

실험실 테스트는 원인을 재현하는 데 적합하고, 실제 사용자 모니터링은 영향 범위를 확인하는 데 적합합니다. PageSpeed Insights의 CrUX 데이터는 실제 방문 경험을 반영합니다. 트래픽이 충분하지 않으면 페이지 수준 데이터가 없을 수 있으며, 데이터가 없다고 해서 성능이 양호하다고 해석해서는 안 됩니다. Lighthouse의 총 차단 시간은 로딩 단계의 메인 스레드 부담을 찾는 데 도움이 될 수 있지만 INP를 대체하는 지표는 아닙니다.

사이트에서는 web-vitals와 해당 원인 분석 기능을 사용해 상호작용 대상, 페이지 유형, 각 단계의 소요 시간을 기록할 수 있습니다. 양식 내용과 같은 개인정보는 수집하지 않도록 주의해야 합니다. 테스트는 실제 모바일 기기와 합리적인 CPU 속도 저하 조건에서 진행해야 합니다. 데스크톱 브라우저에서 화면 폭만 좁혀 사용하는 방식으로는 모바일 기기의 처리 성능 차이를 반영할 수 없습니다.

배포 승인 시에는 비슷한 페이지와 유사한 기기 조건에서 INP 분포를 비교하고, 주요 상호작용이 여전히 올바르게 완료되는지 다시 테스트해야 합니다. CrUX는 최근 28일의 데이터를 사용하므로 변경 사항이 적용된 후 모든 효과가 즉시 반영되지는 않습니다. Google의 INP 정의에 따르면 효과적인 최적화의 근거는 실제 상호작용 대기 시간이 줄어드는 것이지, 리소스 크기가 줄거나 한 번의 성능 점수가 높아지는 것이 아닙니다.