코어 웹 바이탈은 웹페이지의 로딩 속도, 상호작용 반응성, 화면 안정성을 평가하는 핵심 지표입니다. LCP, INP, CLS로 측정하며, 사용자가 주요 내용을 얼마나 빨리 보고 조작할 수 있는지와 읽는 도중 화면이 밀리는지를 살펴봅니다.
LCP, INP, CLS의 측정 대상과 기준
각 지표는 서로 다른 문제를 측정합니다. 결과는 공식 경계값에 따라 ‘좋음’, ‘개선 필요’, ‘나쁨’으로 나눕니다.
| 지표 | 측정 대상 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| 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는 입력 후 100ms 안에 화면이 바뀔 때 사용자가 즉각적인 반응으로 느낀다는 연구를 참고했습니다. 여기에 모바일 사이트의 달성 가능성을 고려해 200ms를 ‘좋음’ 기준으로 정했습니다.
과거 자료에서 FID를 볼 수 있습니다. Google은 2024년 3월 12일 반응성 지표를 FID에서 INP로 바꿨으므로, FID를 현재 지표로 설명하는 진단 자료는 작성 시점을 확인해야 합니다.
지표별로 점검할 원인
- LCP: 대표 이미지나 큰 제목 등 주요 콘텐츠가 늦게 나타난다면 서버 응답과 이미지 용량, 렌더링을 막는 CSS와 JavaScript를 확인합니다.
- INP: 클릭 후 화면 반응이 늦다면 브라우저가 오래 처리하는 JavaScript나 복잡한 이벤트 처리를 살펴봅니다.
- CLS: 읽던 본문이 밀린다면 이미지 크기를 미리 지정했는지, 광고와 배너가 나중에 끼어드는지 확인합니다.
실제 사용자 데이터와 Lighthouse 점수
PageSpeed Insights의 코어 웹 바이탈 평가는 실제 Chrome 사용자의 방문 자료를 사용합니다. Lighthouse 성능 점수는 정해진 기기와 네트워크 조건에서 한 번 실행한 검사 결과입니다. 따라서 Lighthouse 점수가 높아도 최근 방문자의 코어 웹 바이탈은 ‘나쁨’일 수 있습니다.
| 데이터 | 용도 | 해석할 때의 한계 |
|---|---|---|
| 실제 사용자 데이터 | 방문자가 실제로 겪은 경험을 확인합니다. | 이전 28일을 이동 집계하므로 개선이 완전히 반영되기까지 최대 4주가 걸립니다. |
| 실험실 데이터 | 조건을 정해 반복 검사하고 원인을 찾습니다. | 실제 방문자의 모든 기기와 네트워크 환경을 대표하지는 않습니다. |
수정 직후에는 같은 조건으로 실험실 검사를 반복해 변경 효과를 확인하고, 배포 후에는 실제 사용자 데이터의 추이를 봅니다. 일반적인 Lighthouse 페이지 로드 검사에는 사용자의 클릭이나 키 입력이 없어 INP를 직접 측정하지 않습니다. INP 문제는 Chrome DevTools에서 문제가 생긴 동작을 재현하거나 실제 사용자의 상호작용 데이터를 조사해야 합니다.
실제 사용자 데이터가 없는 경우
트래픽이 있어도 Chrome 사용자 경험 보고서(CrUX)의 수집 조건을 충족하지 못하면 필드 데이터가 표시되지 않을 수 있습니다. 개별 URL의 자료가 부족하면 PageSpeed Insights가 사이트 전체에 해당하는 출처(origin) 단위 자료를 대신 보여 줄 수 있으므로, 표시된 수치의 범위도 확인해야 합니다.
- Chrome 사용자가 사용 통계 보고를 허용하고 브라우저 기록을 동기화하는 등 수집 조건을 충족해야 합니다.
- iOS Chrome, Android WebView, Edge 같은 다른 Chromium 브라우저는 수집 대상에 포함되지 않습니다.
- 페이지와 사이트가 공개 검색이 가능해야 하며, 통계적으로 유의미한 방문량도 필요합니다.
실제 사용자 데이터가 없으면 ‘좋음’이나 ‘나쁨’을 판정할 근거도 부족합니다. 이때는 실험실 검사로 로딩 문제를 찾고, 버튼과 입력창을 직접 조작해 반응 지연이나 화면 밀림을 점검합니다.
도구별 점검 범위
- PageSpeed Insights에서는 개별 URL의 실제 사용자 데이터와 실험실 진단을 함께 확인합니다.
- 구글 서치 콘솔에서는 비슷한 성능 문제가 있는 URL 그룹을 찾습니다.
- Chrome DevTools와 Lighthouse에서는 개발 중 문제 원인을 분석하고 수정 결과를 검사합니다.
Search Console이 같은 그룹으로 묶은 URL은 공통 템플릿에서 문제가 생겼을 수 있습니다. 대표 페이지를 수정한 뒤 같은 템플릿의 다른 페이지에도 효과가 반영됐는지 확인합니다.
검색 순위와 개선 우선순위
Google의 순위 시스템은 코어 웹 바이탈을 사용하지만 좋은 점수가 상위 노출을 보장하지는 않습니다. 페이지 경험이 부족해도 관련성이 가장 높은 콘텐츠를 보여 줄 수 있으며, 비슷하게 유용한 콘텐츠가 여럿일 때 페이지 경험이 선택에 영향을 줄 수 있다고 설명합니다.
개선 순서는 방문이 많거나 문의와 구매에 중요한 페이지부터 정합니다. 그 페이지에서 가장 큰 이미지가 늦게 뜨는지, 버튼이 늦게 반응하는지, 본문이 밀리는지를 찾아 원인을 고칩니다. 필요한 콘텐츠를 삭제해 점수만 높이기보다 방문자가 겪는 지연과 불편을 줄이는 것이 목적입니다.
자주 묻는 질문
모바일과 데스크톱 결과가 다른 이유는 무엇인가요?
기기 성능과 네트워크, 화면 구성, 방문자 집단이 다르기 때문입니다. 평가도 환경별로 나눠 진행하므로 실제 사용자 데이터는 각각 확인합니다.
수정했는데 Search Console 결과가 바로 바뀌지 않아요.
필드 데이터는 이전 28일을 집계합니다. 수정 전 데이터가 모두 빠지기까지 4주 가까이 걸릴 수 있으므로, 실험실 테스트에서 개선을 먼저 확인하고 실제 사용자 데이터의 변화를 추적합니다.
모든 페이지를 하나씩 검사해야 하나요?
방문이 많은 페이지와 주요 템플릿부터 검사합니다. 같은 원인이라면 공통 코드나 이미지 처리 방식을 수정해 여러 페이지를 함께 개선할 수 있습니다.
트래픽이 적은 사이트는 코어 웹 바이탈을 신경 안 써도 되나요?
실제 사용자 데이터가 없어도 느린 이미지와 밀리는 배너는 방문에 불편을 줍니다. Lighthouse로 명확한 원인을 찾고 수정한 뒤 이용 경험과 전환이 달라졌는지 확인합니다.
함께 알아두면 좋은 용어
- LCP: 화면에서 가장 큰 이미지나 텍스트가 표시되기까지 걸린 시간
- INP: 사용자 입력 이후 화면 반응 시간을 측정하는 지표
- CLS: 예상하지 못한 화면 이동을 측정하는 지표
- 페이지 경험: 속도 외에도 보안, 모바일 사용성, 방해 요소 등을 포함한 사용 경험