코어 웹 바이탈(Core Web Vitals)은 구글이 실제 사용자 데이터로 페이지의 로딩 속도(LCP), 반응성(INP), 시각적 안정성(CLS)을 재는 세 가지 사용자 경험 지표입니다. 구글 검색의 순위 시스템이 쓰는 신호 중 하나이며, 세 지표 모두 기준을 넘어야 “좋음”으로 판정됩니다.
코어 웹 바이탈은 구글 크롬 팀이 2020년에 발표한 웹 바이탈(Web Vitals) 가운데 모든 페이지에 적용되는 핵심 지표만 추린 것입니다. web.dev 문서에 따르면 각 지표는 실제 현장에서 측정할 수 있어야 하고 사용자가 체감하는 결과를 반영해야 합니다.
지표는 바뀔 수 있습니다. 반응성 지표는 원래 첫 입력의 지연만 재던 FID(First Input Delay)였는데, 2024년 3월 12일 INP로 교체됐습니다. 그래서 “코어 웹 바이탈은 LCP, FID, CLS”라고 적힌 글은 그 이전에 쓰인 것입니다. web.dev는 안정 단계의 지표를 1년에 한 번 넘게 바꾸지 않는다고 밝힙니다.

실무에서는 코어 웹 바이탈을 확인하는 도구 이름을 따서 PSI로 묶어 부르기도 합니다. PSI는 구글의 측정 도구 PageSpeed Insights의 줄임말로, 이 세 지표를 실제 사용자 데이터(CrUX)와 실험실 점수(Lighthouse)로 나눠 한 화면에 보여 주기 때문입니다. 다만 두 값은 뜻이 다르고, 합격 여부를 가르는 것은 실제 사용자 데이터 쪽입니다.
코어 웹 바이탈의 합격 여부는 PageSpeed Insights 위쪽의 0~100점 성능 점수가 아니라, 실제 방문자 기록의 75번째 백분위 값이 세 지표의 “좋음” 기준 안에 드는지로 정합니다. 기준값은 web.dev의 기준값 문서(2025년 5월 갱신)에 이렇게 정리돼 있습니다.
| 지표 | 재는 것 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 로딩 | 2.5초 이하 | 2.5초 초과 ~ 4초 이하 | 4초 초과 |
| INP | 반응성 | 200ms 이하 | 200ms 초과 ~ 500ms 이하 | 500ms 초과 |
| CLS | 시각적 안정성 | 0.1 이하 | 0.1 초과 ~ 0.25 이하 | 0.25 초과 |
75번째 백분위란 방문 기록을 빠른 순으로 줄 세웠을 때 75% 지점의 값입니다. 방문의 75% 이상이 “좋음” 기준을 넘으면 그 지표는 좋음, 25% 이상이 “나쁨”에 걸리면 나쁨으로 분류됩니다. 평균이 아니라 이 지점을 쓰는 이유는 느린 기기와 느린 회선으로 들어온 사용자 대부분까지 기준을 만족시키기 위해서입니다. 모바일과 PC는 따로 판정합니다.
PageSpeed 점수는 이와 다른 계산입니다. 점수는 Lighthouse가 정해진 기기와 네트워크 조건에서 페이지를 한 번 불러와 낸 실험실 값이고, Lighthouse 10 기준 가중치는 총 차단 시간(TBT) 30%, LCP 25%, CLS 25%, 첫 콘텐츠 페인트 10%, 속도 지수 10%입니다. INP는 점수에 들어가지 않습니다. 사용자가 없는 실험실에서는 상호작용이 일어나지 않아 INP를 잴 수 없기 때문입니다.
| 코어 웹 바이탈 평가 | PageSpeed 성능 점수 | |
|---|---|---|
| 데이터 | 필드 데이터: 실제 크롬 사용자 기록(CrUX) | 실험실 데이터: Lighthouse 1회 측정 |
| 기간 | 최근 28일 | 측정한 그 순간 |
| 결과 | 통과 / 미통과, 지표별 좋음·개선 필요·나쁨 | 0~100점 |
| 반응성 지표 | INP | TBT(INP의 대용치) |
| 구글 검색과의 관계 | 순위 시스템이 쓰는 신호 | 개발 중 문제를 찾는 진단 도구 |
두 값이 어긋나는 일은 흔합니다. web.dev의 실험실·필드 데이터 비교 문서는 한 페이지의 필드 LCP가 75번째 백분위 1.8초인데 실험실 LCP는 3.0초로 나온 예를 들며, 실험실 값은 기기 하나, 네트워크 하나, 지역 하나에서 잰 값이라 전체 분포를 대표하지 않는다고 설명합니다. 점수가 낮아도 코어 웹 바이탈은 통과할 수 있고, 점수가 높아도 실제 사용자는 느릴 수 있습니다.

코어 웹 바이탈은 순위에 쓰이지만, 관련성을 뒤집을 만큼 큰 신호는 아닙니다. 구글의 페이지 경험 문서는 “코어 웹 바이탈은 순위 시스템에서 사용된다”고 밝히면서도, 서치 콘솔 보고서나 외부 도구에서 좋은 결과가 나와도 상위 순위를 보장하지 않으며 SEO만을 위해 만점을 노리는 것은 시간을 가장 잘 쓰는 방법이 아닐 수 있다고 적습니다.
같은 문서는 구글이 페이지 경험이 좋지 않더라도 가장 관련성 높은 콘텐츠를 보여 주려 하고, 도움이 되는 콘텐츠가 많은 검색어에서 좋은 페이지 경험이 성공에 기여할 수 있다고 설명합니다. 구글의 설명대로라면 관련성이 비슷한 글끼리 경쟁할 때 작용하는 신호라는 뜻입니다. 평가는 대체로 페이지 단위로 하지만 사이트 전체 단위의 평가도 일부 있다고 합니다.
현재 웹의 통과율은 절반 안팎입니다. HTTP Archive의 Web Almanac 2025가 CrUX 데이터로 집계한 2025년 6월 기준 수치는 다음과 같습니다(전 세계 크롬 사용자 기록 기준).
| “좋음” 비율 | LCP | INP | CLS | 세 지표 모두 |
|---|---|---|---|---|
| 모바일 | 62% | 77% | 81% | 48% |
| PC | 74% | 97% | 72% | 56% |
모바일에서 가장 많이 떨어지는 지표는 LCP이고, INP는 PC에서는 거의 문제가 되지 않지만 모바일에서는 네 곳 중 한 곳 가까이가 기준을 넘지 못합니다. 구글이 모바일 버전을 기준으로 색인한다는 점을 생각하면, 먼저 볼 것은 모바일 쪽 수치입니다.
공식 문서는 순위 신호라고 적지만, 제가 국내 사이트를 다루며 본 바로는 그 영향이 순위까지 이어지지 않았습니다. 한국 기준으로 PageSpeed 점수와 코어 웹 바이탈은 구글봇이 사이트를 얼마나 자주, 얼마나 많이 크롤링하느냐에 영향을 줄 뿐, 이것만 고쳐서 순위가 움직이는 것은 보지 못했습니다.
컨설턴트의 실전 팁
코어 웹 바이탈 판정이 나쁘다고 곧바로 속도 개선부터 잡지는 않습니다. 판정이 나쁘고 실제 CrUX 필드 데이터까지 나쁠 때만 우선순위로 올립니다. 그렇지 않다면 콘텐츠, 색인 상태, 페이지 구조를 먼저 봅니다.
사이트 전체는 구글 서치 콘솔의 코어 웹 바이탈 보고서로, 페이지 하나는 PageSpeed Insights의 위쪽 필드 데이터 영역으로 봅니다. 둘 다 크롬 사용자 경험 보고서(CrUX)의 실제 사용자 데이터를 씁니다.
구글 고객센터 문서에 따르면 이 보고서는 비슷한 페이지를 URL 그룹으로 묶어 모바일과 PC 각각 나쁨, 개선 필요, 좋음으로 나눕니다. 그룹의 상태는 세 지표 중 가장 나쁜 지표를 따릅니다. CLS가 나쁨이면 INP가 좋아도 그 그룹은 나쁨입니다.
PageSpeed Insights 결과 화면은 위쪽이 필드 데이터(코어 웹 바이탈 평가), 아래쪽이 실험실 데이터(Lighthouse 성능 점수)입니다. 합격 여부는 위쪽을 보고, 아래쪽은 무엇이 느린지 찾는 진단에 씁니다. 필드 데이터는 최근 28일치라 고친 뒤 결과에 반영되기까지 시간이 걸립니다.
CrUX에 들어가려면 페이지가 공개적으로 발견 가능하고 방문자가 일정 수 이상이어야 합니다. CrUX 방법론 문서는 그 최소 인원을 공개하지 않습니다. 데이터가 없는 작은 사이트는 실험실 데이터로 방향을 잡되, 가능하면 web-vitals 자바스크립트 라이브러리 같은 실사용자 측정을 직접 붙이는 것이 좋습니다.

세 지표는 원인이 서로 다르므로, 나쁜 지표 하나를 골라 그 원인부터 봅니다.
| 지표 | 흔한 원인 | 먼저 해 볼 것 |
|---|---|---|
| LCP | 느린 서버 응답, 늦게 발견되는 대표 이미지, 렌더링을 막는 CSS·자바스크립트 | 대표 이미지를 지연 로드에서 빼고 먼저 불러오기, 이미지 용량 줄이기 |
| INP | 메인 스레드를 오래 붙잡는 자바스크립트, 한 번에 큰 화면 갱신 | 긴 작업을 쪼개기, 불필요한 스크립트 걷어 내기 |
| CLS | 크기가 지정되지 않은 이미지·동영상, 늦게 끼어드는 광고·위젯, 웹폰트 교체 | 이미지에 width·height 지정, 광고 자리를 미리 확보 |
원인 목록은 web.dev의 LCP, INP, CLS 문서를 따랐습니다. INP는 실험실에서 잴 수 없으므로 Lighthouse의 TBT를 대용치로 보고 줄이면, 실제 INP도 좋아질 가능성이 높다고 web.dev는 설명합니다.