코어 웹 바이탈은 페이지의 주요 내용이 빨리 보이는지, 버튼이 바로 반응하는지, 읽는 중에 화면이 밀리지 않는지를 측정하는 지표입니다. 현재 지표는 LCP, INP, CLS입니다.
이 글은 web.dev와 Google 검색 센터의 공식 문서를 기준으로 작성했습니다.
LCP, INP, CLS 세 지표의 측정 대상
각 지표는 서로 다른 사용 경험을 봅니다. 판정은 좋음, 개선 필요, 나쁨 3단계이고 경계 수치가 공식으로 정해져 있습니다.
| 지표 | 측정 대상 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 주요 콘텐츠가 표시되는 시간 | 2.5초 이하 | 2.5초 초과 4초 이하 | 4초 초과 |
| INP | 클릭이나 입력 후 화면이 반응하는 시간 | 200ms 이하 | 200ms 초과 500ms 이하 | 500ms 초과 |
| CLS | 예상하지 못한 화면 이동의 누적 정도 | 0.1 이하 | 0.1 초과 0.25 이하 | 0.25 초과 |
판정 기준은 페이지 방문의 75번째 백분위수입니다. 방문 100번 중 75번이 기준 안에 들어야 좋음이 되는데, 이 값을 쓰는 이유도 공식 문서에 있습니다. 대다수 방문자의 경험을 대표하면서 소수의 느린 이상치에 결과가 흔들리지 않게 하기 위한 통계적 선택입니다. 모바일과 데스크톱은 나눠서 각각 판정합니다.
임계값 자체도 임의 숫자가 아닙니다. LCP 2.5초는 사용자 주의 지속에 관한 연구, INP 200ms는 100ms 이하 지연을 즉각 반응으로 인지한다는 인지 연구를 바탕으로, 상위 사이트들이 실제 달성 가능한 수준을 함께 고려해 정해졌습니다.
FID라는 지표를 본 적이 있다면 과거 자료일 수 있습니다. Google은 2024년 3월 12일 반응성 지표를 FID에서 INP로 교체했습니다. FID 기준으로 진단하는 자료는 그 이전에 쓰인 것입니다.
지표를 떨어뜨리는 흔한 원인
- LCP: 큰 대표 이미지나 제목 영역이 늦게 나타날 때 나빠질 수 있습니다. 서버 응답, 큰 이미지 파일, 렌더링을 막는 CSS와 JavaScript 등을 확인합니다.
- INP: 버튼을 누른 뒤 브라우저가 다른 작업을 오래 처리하느라 화면을 늦게 바꿀 때 나빠질 수 있습니다. 실행 시간이 긴 JavaScript와 복잡한 클릭 처리를 살펴봅니다.
- CLS: 이미지 크기를 미리 지정하지 않았거나 광고와 배너가 나중에 끼어들면서 본문을 밀어낼 때 커질 수 있습니다.
PageSpeed Insights 성능 점수와 다른 값
같은 뜻은 아닙니다.
PageSpeed Insights 상단의 Core Web Vitals 평가는 실제 Chrome 사용자의 최근 방문 데이터를 사용합니다.
Lighthouse 성능 점수는 정해진 기기와 네트워크 조건에서 시험한 결과입니다.
| 데이터 | 장점 | 확인할 점 |
|---|---|---|
| 실제 사용자 데이터 | 방문자가 실제로 겪은 경험 반영 | 이전 28일 롤링 데이터라 개선이 완전히 반영되기까지 최대 4주 걸림 |
| 실험실 데이터 | 같은 조건에서 반복 검사 가능 | 실제 사용자와 기기 환경을 모두 대표하지 않음 |
개선할 때는 실험실 데이터로 원인을 찾고, 배포 후 실제 사용자 데이터가 좋아지는지 확인합니다.
필드 데이터가 안 보이는 사이트의 조건
트래픽이 있는데도 실제 사용자 데이터가 비어 있다면 CrUX 수집 조건 때문일 가능성이 큽니다. 실무에서 자주 나오는 질문이라 조건을 정리해 둡니다.
- 데이터는 모든 크롬 사용자가 아니라 사용통계 보고를 켜고 브라우저 기록을 동기화하는 사용자에게서만 수집됩니다
- iOS의 크롬, 안드로이드 WebView, 엣지 같은 다른 Chromium 브라우저는 수집 대상이 아닙니다
- 페이지와 사이트도 공개 검색이 가능하고 통계적으로 유의미한 방문량이 있어야 데이터셋에 포함됩니다. 방문이 적은 페이지는 필드 데이터 없이 실험실 데이터만 표시됩니다
방문이 적은 사이트라면 필드 데이터 부재 자체는 문제가 아닙니다. 실험실 데이터 기준으로 관리하다가 트래픽이 쌓이면 필드 데이터가 생깁니다.
현장 데이터와 실험실 데이터의 구분
- PageSpeed Insights: 개별 URL의 실제 사용자 데이터와 실험실 진단을 함께 봅니다.
- 구글 서치 콘솔: 비슷한 문제가 있는 URL 그룹을 확인합니다.
- Chrome DevTools와 Lighthouse: 개발 과정에서 원인과 개선 항목을 찾습니다.
Search Console은 비슷한 경험을 보이는 URL을 묶어 보고할 수 있습니다. 대표 URL 하나를 고친 뒤 같은 템플릿의 다른 페이지에도 문제가 해결됐는지 확인하세요.
점수와 검색 순위의 관계
Google의 순위 시스템은 코어 웹 바이탈을 사용하지만 좋은 점수가 상위 노출을 보장하지는 않습니다. 공식 문서의 표현은 더 직접적입니다. 페이지 경험이 부족하더라도 가장 관련성 높은 콘텐츠를 우선 보여주며, 비슷하게 유용한 콘텐츠가 많은 검색어에서만 페이지 경험이 차별화 요소로 작용한다고 밝힙니다. 지표만 올리면 순위가 오른다는 기대는 이 공식 문구와 어긋납니다.
Google 검색의 AI 기능에도 좋은 페이지 경험이라는 기존 원칙이 이어지지만, LCP와 INP, CLS가 AI 인용을 결정하는 전용 점수는 아닙니다. 범용 챗봇이 세 지표를 공통으로 사용한다는 근거도 없습니다. AI 출처 링크로 들어온 방문자의 이용 경험은 GA4와 실제 사용자 데이터로 확인하고, 인용 여부와 분리해 해석합니다.
콘텐츠의 답을 줄이면서 점수만 높이거나, 이미 좋은 수치를 100점으로 만들기 위해 큰 비용을 쓰는 방식이라면 먼저 우선순위를 따져 보세요. 사용자가 실제로 불편을 겪는 페이지와 나쁨으로 분류된 지표부터 개선하는 것이 순서에 맞습니다.
자주 묻는 질문
모바일과 데스크톱 결과가 다른 이유는 무엇인가요?
기기 성능과 네트워크, 화면 구성과 사용자 집단이 다르기 때문입니다. 판정 자체가 두 환경을 나눠서 각각 이뤄지므로, 실제 사용자 데이터도 따로 확인하세요.
수정했는데 Search Console 결과가 바로 바뀌지 않아요.
필드 데이터가 이전 28일 롤링 기간으로 집계되기 때문입니다. 오늘 개선해도 이전 데이터가 완전히 빠지려면 4주 가까이 걸립니다. 실험실 테스트로 변경을 먼저 확인한 뒤 현장 데이터의 갱신을 기다리세요.
모든 페이지를 하나씩 검사해야 하나요?
주요 템플릿과 방문이 많은 페이지부터 검사합니다. 같은 템플릿에서 생긴 문제라면 공통 코드나 이미지 처리 방식을 고쳐 여러 페이지를 함께 개선할 수 있습니다.
트래픽이 적은 사이트는 코어 웹 바이탈을 신경 안 써도 되나요?
순위 신호로서의 비중은 낮지만 방문자 경험 문제는 그대로 남습니다. 필드 데이터가 없어도 Lighthouse로 나쁨 구간의 명백한 문제(거대 이미지, 밀리는 배너)는 잡을 수 있고, 이런 개선은 트래픽 규모와 무관하게 전환에 도움이 됩니다.
함께 알아두면 좋은 용어
- LCP: 주요 콘텐츠가 화면에 표시되는 속도 지표
- INP: 사용자 입력 이후 화면 반응 시간을 측정하는 지표
- CLS: 예상하지 못한 화면 이동을 측정하는 지표
- 페이지 경험: 속도 외에도 보안, 모바일 사용성, 방해 요소 등을 포함한 사용 경험