코어 웹 바이탈 점검기 쉽게 이해하기 — 개념과 원리
코어 웹 바이탈(Core Web Vitals)은 구글이 정한 웹 페이지 사용자 경험 지표 세 가지로, 로딩 속도를 보는 LCP(Largest Contentful Paint), 반응성을 보는 INP(Interaction to Next Paint), 화면 안정성을 보는 CLS(Cumulative Layout Shift)입니다. 이 점검기는 입력한 값을 구글이 공개한 기준에 따라 평가하고, 보조 진단 지표인 TTFB(첫 바이트까지의 시간)와 FCP(첫 콘텐츠 표시 시간)도 함께 평가합니다.
계산 방법
각 지표는 두 기준값과 비교합니다. 첫째 기준 이하면 good(좋음), 둘째 기준 이하면 needs improvement(개선 필요), 그보다 크면 poor(나쁨)입니다.
- LCP: 좋음 2.5초 이하, 나쁨 4.0초 초과
- INP: 좋음 200ms 이하, 나쁨 500ms 초과
- CLS: 좋음 0.1 이하, 나쁨 0.25 초과(단위 없는 점수)
- TTFB: 좋음 800ms 이하, 나쁨 1800ms 초과
- FCP: 좋음 1.8초 이하, 나쁨 3.0초 초과
종합 판정은 LCP, INP, CLS 세 가지가 모두 좋음일 때만 통과이며, TTFB와 FCP는 판정에 들어가지 않습니다.
원리
평가는 실제 방문 데이터의 75번째 백분위수로 하며 모바일과 데스크톱을 따로 봅니다. 방문 네 번 중 세 번 이상이 좋음이어야 통과한다는 뜻입니다. LCP는 화면에서 가장 큰 이미지나 텍스트 블록이 그려진 시점입니다. INP는 방문하는 동안의 클릭, 탭, 키 입력 반응 지연을 모두 관찰해 가장 느린 축에 속하는 값을 보고합니다. CLS는 예상치 못한 레이아웃 이동을 영향 비율 × 이동 거리 비율로 점수화해, 가장 심한 이동 묶음을 합산합니다. INP는 2024년 3월 FID를 대신해 코어 웹 바이탈이 되었습니다.
예제 풀이
- 입력값은 LCP 2.1초, INP 180ms, CLS 0.08, TTFB 600ms, FCP 1.5초입니다.
- LCP 2.1 ≤ 2.5, INP 180 ≤ 200, CLS 0.08 ≤ 0.1이므로 셋 다 good입니다.
- TTFB 600 ≤ 800, FCP 1.5 ≤ 1.8이므로 둘 다 good입니다.
- 핵심 지표 세 개가 모두 좋음이므로 종합 결과는 passes (all good)입니다.
결과 해석
한 번의 실험실 측정값이 아니라 현장 데이터의 75번째 백분위수를 넣어야 합니다. TTFB가 느리면 FCP와 LCP도 함께 늦어지므로 서버와 캐시부터 점검하는 것이 순서입니다. INP가 나쁘면 메인 스레드를 오래 붙잡는 자바스크립트 작업을, CLS가 나쁘면 크기를 지정하지 않은 이미지나 광고, 웹폰트를 의심해 보십시오.
흔한 실수
- 라이트하우스 한 번의 결과만 보는 경우입니다. 실험실 측정으로는 실제 INP를 잴 수 없습니다.
- 75번째 백분위수 대신 평균값을 넣는 경우입니다.
- 모바일과 데스크톱 데이터를 섞어 판단하는 경우입니다.
자주 묻는 질문
FID는 이제 쓰지 않나요?
그렇습니다. 첫 입력만 보는 FID 대신 모든 상호작용을 보는 INP가 2024년 3월부터 핵심 지표입니다.
CLS에는 왜 단위가 없나요?
화면의 얼마만큼이 얼마나 멀리 움직였는지를 곱한 점수이기 때문입니다.
내 사이트의 현장 데이터는 어디서 보나요?
방문자가 충분한 페이지라면 PageSpeed Insights와 서치 콘솔에서 크롬 사용자 경험 보고서(CrUX) 데이터를 볼 수 있습니다.
출처: web.dev, "Web Vitals" 및 LCP·INP·CLS·TTFB·FCP 지표 문서 (Google) · Chrome UX Report 문서, developer.chrome.com