코어 웹 바이탈(Core Web Vitals)은 웹페이지의 로딩 성능, 반응성, 시각적 안정성을 실제 사용자 데이터로 측정하는 구글의 세 가지 지표다. 각각 LCP, INP, CLS로 부른다.
구글은 이 셋을 “실제 사용자 경험을 측정하는 측정항목”으로 정의하고, 검색 순위 시스템이 실제로 사용하는 페이지 경험 요소라고 밝히고 있다 (구글 검색 센터, Core Web Vitals 및 Google 검색결과 이해하기).
로딩을 재는 LCP, 반응성을 재는 INP, 시각적 안정성을 재는 CLS다. 사용자가 페이지에서 겪는 불편을 셋으로 나눠 각각 숫자로 바꾼 것이다.
LCP(Largest Contentful Paint, 최대 콘텐츠 페인트)는 화면에 보이는 영역에서 가장 큰 이미지나 텍스트 블록, 동영상이 렌더링되는 시점을 잰다. “페이지가 다 뜬 것처럼 보이는 순간”에 가장 가까운 값이다.
LCP에는 이전 페이지를 떠나는 시간과 연결을 맺는 시간, 리디렉션 시간이 모두 포함된다 (web.dev, 최대 콘텐츠 렌더링 시간(LCP)). 서버가 느리면 프런트엔드를 아무리 다듬어도 LCP가 좋아지지 않는 이유가 여기에 있다.
INP(Interaction to Next Paint, 다음 페인트에 대한 상호작용)는 사용자가 클릭이나 탭, 키 입력을 한 뒤 화면이 다음 프레임을 그릴 때까지 걸린 시간을 잰다. 페이지 안에서 일어난 상호작용 중 가장 느린 축에 속하는 값 하나를 대표로 보고한다.
CLS(Cumulative Layout Shift, 누적 레이아웃 이동)는 이미 보이던 요소가 예고 없이 밀려나는 정도를 잰다. 시간이 아니라 점수라 단위가 없다.
CLS 점수는 곱셈으로 계산된다. 브라우저는 요소가 화면에서 차지한 면적의 비율(영향 분수)과 움직인 거리의 비율(거리 분수)을 곱해 레이아웃 이동 점수를 낸다 (web.dev, 누적 레이아웃 이동(CLS)).
기사를 읽다가 광고가 로드되면서 본문이 아래로 밀리는 그 순간이 CLS로 잡힌다.
세 지표 모두 좋음과 나쁨을 가르는 값이 정해져 있고, 판정은 항상 75번째 백분위수로 한다.
| 지표 | 좋음 | 나쁨 | 판정 백분위수 |
|---|---|---|---|
| LCP | 2,500밀리초 이하 | 4,000밀리초 초과 | 75 |
| INP | 200밀리초 이하 | 500밀리초 초과 | 75 |
| CLS | 0.1 이하 | 0.25 초과 | 75 |
75번째 백분위수라는 말은 평균이 아니라는 뜻이다. 구글은 “사이트의 페이지 조회 중 75% 이상이 ‘양호’ 기준을 충족하면 해당 측정항목에 대해 ‘양호’한 실적을 보인 것으로 분류”한다고 설명한다 (web.dev, Core Web Vitals 측정항목 기준 정의).
평균으로 재면 빠른 방문 몇 건이 느린 방문을 가려 버린다. 75번째 백분위수는 하위 25% 사용자의 경험을 판정에 그대로 반영한다.
기준값은 이상적인 목표가 아니라 달성 가능성을 따져 정한 숫자다. 구글은 LCP 후보값을 검토하면서 “1.5초 및 2초 기준점은 일관되게 달성할 수 없지만 2.5초 기준점은 일관되게 달성할 수 있는 것으로 나타났다”고 적었다.
INP 기준은 더 노골적으로 현실을 반영했다. 인기 상위 1만 개 사이트에서 200밀리초를 통과하는 비율이 모바일 기준 23%에 그쳤는데도, 구글은 10% 이상이면 유효한 후보라는 자체 기준에 따라 200밀리초를 유지했다.
측정 도구가 “통과”라고 표시하려면 세 지표 전부가 75번째 백분위수에서 기준을 만족해야 한다 (web.dev, Web Vitals). 하나만 어긋나도 평가는 실패로 뜬다.
순위 시스템이 쓰기는 하지만, 점수를 올린다고 순위가 오른다는 보장은 없다. 구글이 직접 그렇게 말했다.
구글은 “Google 검색 순위 시스템에서는 Core Web Vitals가 사용됩니다”라고 명시한다. 페이지 경험 요소 중 순위에 직접 쓰인다고 못 박은 것은 코어 웹 바이탈뿐이다 (구글 검색 센터, Google 검색결과의 페이지 경험 이해하기).
그런데 같은 문서가 곧바로 기대치를 낮춘다. “보고서에서 좋은 결과를 얻었다고 해서 페이지가 Google 검색 결과 상단에 표시된다고 보장할 수는 없습니다”가 원문이다.
가장 분명한 문장은 그다음에 나온다. 구글은 “검색엔진 최적화만을 위해 Core Web Vitals에서 완벽한 점수를 얻으려고 하는 것은 시간 낭비일 수 있습니다”라고 적어 뒀다.
단일한 페이지 경험 신호도 없다. “Google의 핵심 순위 시스템은 전반적인 페이지 경험에 부합하는 다양한 신호를 확인합니다”가 같은 문서 FAQ의 답이다.
콘텐츠가 먼저라는 순서도 문서에 있다. 구글은 페이지 경험이 평균 이하여도 가장 관련성 높은 콘텐츠를 보여주려 하며, 코어 웹 바이탈이 갈라놓는 것은 유용한 콘텐츠가 여럿일 때라고 설명한다.
코어 웹 바이탈은 동점을 깨는 요소에 가깝다. SEO에서 콘텐츠가 부족한 페이지를 끌어올리는 장치가 아니라, 비슷한 후보들 사이에서 갈리는 지점이다.
측정에는 두 종류가 있고, 판정에 쓰이는 것은 한쪽뿐이다. 실제 사용자에게서 모은 필드 데이터가 정본이고, 내 컴퓨터에서 돌린 랩 데이터는 진단용이다.
필드 데이터는 크롬 사용자 경험 보고서(CrUX)에서 나온다. CrUX는 실제 크롬 사용자의 익명 측정값을 모아 구글 서치 콘솔의 코어 웹 바이탈 보고서와 PageSpeed Insights에 공급한다.
랩 데이터는 시뮬레이션이다. 라이트하우스는 사용자 입력이 없는 환경에서 페이지를 열기 때문에 INP를 아예 측정하지 못하고, 대신 총 차단 시간(TBT)을 대리 지표로 쓴다.
| 도구 | 데이터 종류 | INP 측정 |
|---|---|---|
| 서치 콘솔 코어 웹 바이탈 보고서 | 필드(CrUX) | 가능 |
| PageSpeed Insights | 필드 + 랩 | 필드에서만 가능 |
| 크롬 개발자 도구 | 랩 | 가능 |
| 라이트하우스 | 랩 | 불가(TBT로 대체) |
서치 콘솔 보고서를 볼 때 알아 둘 점이 셋 있다. 데이터는 지난 28일 기준이고, 개별 URL이 아니라 비슷한 페이지를 묶은 URL 그룹 단위이며, 그룹의 상태는 가장 저조한 지표를 따른다 (구글 서치 콘솔 고객센터, Core Web Vitals 보고서).
CLS는 빠른데 INP가 느리면 그 그룹 전체가 “느림”으로 표시된다는 뜻이다.
트래픽이 적은 페이지는 보고서에 아예 나오지 않는다. CrUX에 충분한 데이터가 쌓이지 않은 URL 그룹은 생략되기 때문이다.
이럴 때는 랩 측정으로 메운다. 구글도 데이터가 없으면 PageSpeed Insights나 라이트하우스로 개별 URL을 직접 테스트하라고 안내한다.
서치폴라리스 도메인의 세 페이지를 브라우저 성능 API로 직접 재 봤다. 2026년 9월 1일, 데스크톱 크로미움에서 각 1회 측정한 랩 값이다.
| 측정한 주소 | TTFB | LCP | LCP 요소 | LCP 중 TTFB 비중 | CLS |
|---|---|---|---|---|---|
| searchpolaris.com 홈 | 47ms | 628ms | H1 텍스트 | 7% | 0.0001 |
| /wiki/geo/ | 436ms | 948ms | 본문 문단 텍스트 | 46% | 0.0001 |
| /blog/rag/ | 1,832ms | 2,084ms | 썸네일 이미지 | 88% | 0 |
세 페이지 모두 LCP 2.5초 기준은 통과했다. 그런데 통과 여부만 보면 놓치는 것이 있다.
구글은 잘 최적화된 페이지의 LCP 구성을 TTFB 약 40%, 리소스 로드 지연 10% 미만, 리소스 로드 시간 약 40%, 요소 렌더링 지연 10% 미만으로 제시한다 (web.dev, LCP 최적화).
이 기준으로 보면 블로그 페이지는 LCP의 88%를 서버 응답을 기다리는 데 썼다. 권장치의 두 배가 넘는다.
이미지를 아무리 압축해도 이 페이지의 LCP는 거의 줄지 않는다. 병목이 이미지가 아니라 서버 응답이기 때문이다.
LCP 요소가 무엇인지도 갈림길이다. 홈과 위키 페이지는 LCP 요소가 텍스트라 별도 리소스를 기다릴 필요가 없었고, 블로그 페이지는 썸네일 이미지가 LCP 요소라 다운로드 시간이 그대로 얹혔다.
구글도 같은 지점을 짚는다. 모바일 페이지의 73%가 이미지를 LCP 요소로 쓰고 있고, 그중 35%는 이미지 주소가 초기 HTML에서 발견되지 않아 브라우저가 늦게 내려받는다 (web.dev, Core Web Vitals를 개선하는 가장 효과적인 방법).
위 표는 필드 데이터가 아니다. 1회 랩 측정이라 순위 판정에는 쓰이지 않고, 어디가 병목인지 찾는 용도로만 의미가 있다.
지표마다 효과가 큰 조치가 다르다. 구글 크롬팀이 실제 데이터를 근거로 우선순위를 매겨 둔 것이 있다.
LCP부터 보면 손을 대야 할 곳은 이미지다. 크롬 사용자 경험 보고서에 포함된 사이트의 40%가 권장 LCP 기준을 넘기지 못하고 있다.
data-src 같은 비표준 속성 뒤에 숨기면 브라우저의 미리 로드 스캐너가 못 찾는다.fetchpriority="high"를 붙이고 loading="lazy"를 뗀다. 조건을 갖춘 페이지 중 15%만 이 속성을 쓰고 있다.INP는 자바스크립트 문제인 경우가 많다. 50밀리초를 넘는 작업은 긴 작업으로 분류되고, 이 작업이 메인 스레드를 잡고 있으면 클릭에 반응할 수 없다.
긴 작업을 쪼개 메인 스레드에 자주 양보하고, 쓰지 않는 스크립트를 걷어내고, 한 번에 큰 렌더링을 일으키지 않는 것이 순서다. 태그 관리자에 쌓인 오래된 태그를 정리하는 것도 여기 들어간다.
CLS는 셋 중 고치기 가장 쉽다. 페이지의 66%에 크기가 지정되지 않은 이미지가 하나 이상 있는데, width와 height를 명시하는 것만으로 상당 부분이 해결된다.
크기를 모르는 영역은 aspect-ratio나 min-height로 자리를 미리 잡아 둔다. 빈 요소의 기본 높이는 0이라 콘텐츠가 도착하는 순간 아래 내용이 통째로 밀린다.
애니메이션도 확인한다. 레이아웃에 영향을 주는 CSS 속성에 애니메이션을 거는 페이지는 CLS가 양호할 가능성이 15% 낮고, margin이나 border 너비에 애니메이션을 걸면 나쁨 비율이 거의 두 배가 된다.
top이나 left 대신 transform을 쓰면 브라우저가 레이아웃을 다시 계산하지 않는다. 쿠키 배너가 아래에서 슬라이드로 올라오는 흔한 패턴이 대표적인 수정 대상이다.
이 작업들은 대부분 테크니컬 SEO의 영역이라 콘텐츠 담당자 혼자 처리하기 어렵다. 측정은 마케터가 하고 수정은 개발자가 하는 구조를 먼저 만들어야 한다.
INP로 교체됐기 때문이다. 2024년 3월 12일 INP가 정식 코어 웹 바이탈이 되면서 FID(First Input Delay, 첫 입력 지연)는 지원 중단됐다.
FID는 첫 상호작용이 처리되기 시작할 때까지의 지연만 쟀다. 버튼을 누른 뒤 화면이 실제로 바뀔 때까지는 재지 않아서, 사용자가 답답함을 느끼는 구간을 놓쳤다.
INP는 첫 입력에 한정하지 않고 페이지 수명 동안의 상호작용을 모두 본다. 그리고 입력 지연에서 끝나지 않고 다음 프레임이 그려지는 순간까지를 잰다.
전환은 이미 끝났다. 구글은 개발자가 2024년 9월 9일까지 INP로 전환해야 하며 그 이후 크롬 도구에서 FID 가용성을 보장하지 않는다고 공지했다 (web.dev, Interaction to Next Paint가 정식 Core Web Vital이 되었습니다).
그런데 한국어 검색 결과는 아직 따라오지 않았다. 2026년 9월 1일 기준으로 구글에서 “코어 웹 바이탈”을 검색하면 2위에 나오는 클라우드플레어 한국어 문서가 세 지표를 “LCP, FID, CLS”로 설명하고 있고, 본문에 INP는 한 번도 등장하지 않는다.
한국어 자료를 읽을 때 FID가 세 지표 중 하나로 나오면 2024년 3월 이전 기준이라고 보면 된다. 그 문서의 나머지 설명도 오래됐을 가능성이 높다.
안정 지표라고 영구적인 것은 아니다. 구글은 안정 측정항목도 문제를 더 잘 다루는 다른 지표로 대체될 수 있으며, 다만 변경은 1년에 한 번을 넘지 않는다고 밝히고 있다.
코어 웹 바이탈은 어떻게 측정하나요? 순위 판정에 쓰이는 값을 보려면 구글 서치 콘솔의 코어 웹 바이탈 보고서를 엽니다. 이 보고서는 실제 사용자 데이터(CrUX)를 지난 28일 기준으로 보여 줍니다. 트래픽이 적어 데이터가 없다면 PageSpeed Insights나 크롬 개발자 도구로 개별 페이지를 직접 측정합니다.
코어 웹 바이탈 평가 실패는 무슨 뜻인가요? LCP, INP, CLS 중 하나 이상이 75번째 백분위수에서 기준값을 넘겼다는 뜻입니다. 세 지표 전부가 기준을 만족해야 통과로 표시되기 때문에, 두 개가 좋아도 하나가 나쁘면 실패로 나옵니다. 어느 지표가 걸렸는지는 PageSpeed Insights의 실제 사용자 데이터 항목에서 확인할 수 있습니다.
웹 바이탈과 코어 웹 바이탈은 무엇이 다른가요? 웹 바이탈이 더 넓은 개념이고, 코어 웹 바이탈은 그중 모든 웹페이지에 적용되는 핵심 세 가지입니다. TTFB나 FCP, TBT도 웹 바이탈이지만 코어에는 들어가지 않습니다. TBT는 실제 사용자 환경에서 측정할 수 없다는 이유로 제외됐습니다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.