Core Web Vitals란 무엇인가? LCP, INP, CLS 해설 (2026)
Core Web Vitals의 모든 것: 지표, 기준치, 측정 도구, 통과 방법.
Core Web Vitals는 실제 방문자를 대상으로 측정하는 세 가지 Google 지표입니다. 로딩 성능을 나타내며 2.5초 미만이어야 양호한 Largest Contentful Paint (LCP), 응답성을 나타내며 200밀리초 미만이어야 양호한 Interaction to Next Paint (INP), 시각적 안정성을 나타내며 0.1 미만이어야 양호한 Cumulative Layout Shift (CLS)로 구성됩니다. Google은 전체 방문의 75번째 백분위수 기준으로 이 지표들을 평가합니다.
Core Web Vitals 요약
Google은 페이지가 어떻게 로드되고, 반응하고, 시각적 안정성을 유지하는지 판단하기 위해 Core Web Vitals를 사용합니다. 지표는 세 가지입니다. Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS)입니다.
Core Web Vitals란 무엇인가?
각 Core Web Vital 지표는 방문 중 특정 순간을 측정합니다. 데이터는 실제 Chrome 사용자에게서 나옵니다:
- 로딩 (LCP): 주요 콘텐츠가 화면에 나타날 때까지 걸리는 시간
- 상호작용 (INP): 클릭, 탭, 키 입력에 페이지가 반응하기까지 걸리는 시간
- 안정성 (CLS): 로딩되는 동안 콘텐츠가 얼마나 움직이는지
지표 구성은 변경되기도 합니다. 2024년 3월, INP가 First Input Delay (FID)를 대체했습니다. FID는 첫 번째 상호작용이 처리되기 전까지의 대기 시간만 측정했습니다. 반면 INP는 모든 상호작용을 시작부터 끝까지 측정하며, 훨씬 더 많은 사이트가 여기서 탈락합니다.
Table of Contents!
Core Web Vitals는 언제 통과하는가?
Google은 각 지표를 양호(Good), 개선 필요(Needs Improvement), 느림(Poor)으로 평가합니다. CrUX에 기록된 페이지 방문 중 최소 75%에서 LCP, INP, CLS가 모두 '양호'여야 통과합니다. Google은 먼저 개별 URL을 살펴봅니다. 해당 URL의 트래픽이 너무 적으면 유사한 URL 그룹으로 fallback하고, 이마저도 부족하면 전체 origin으로 fallback합니다. PageSpeed Insights는 페이지 최상단에 "Core Web Vitals Assessment: Passed" 또는 "Failed"로 결과를 표시합니다.
| 양호 | 개선 필요 | 느림 | |
|---|---|---|---|
| Largest Contentful Paint | < 2500ms | 2500ms - 4000ms | > 4000ms |
| Interaction to Next Paint | < 200ms | 200ms - 500ms | > 500ms |
| Cumulative Layout Shift | < 0.1 | 0.1 - 0.25 | > 0.25 |
왜 75번째 백분위수인가?
중앙값(median)은 속도가 빠른 절반의 방문자 상태만 보여줄 뿐입니다. 그렇다고 더 엄격한 백분위수를 적용하면, 안테나가 한 칸만 뜨는 기차 안에서의 방문 몇 건 때문에 페이지 전체가 탈락할 수 있습니다. p75는 그 중간입니다. 방문 네 건 중 세 건이 '양호' 기준을 충족해야 합니다.
사무실 Wi-Fi에 연결된 노트북으로 테스트해서는 알 수 있는 것이 거의 없습니다. p75를 결정짓는 것은 모바일 네트워크 환경에 있는 느린 스마트폰의 방문입니다.
Core Web Vitals 3대 지표
Largest Contentful Paint (LCP): 로딩
Largest Contentful Paint는 로딩을 측정합니다. 페이지 탐색을 시작한 시점부터 viewport 내에서 가장 큰 요소가 화면에 그려질 때까지의 시간입니다.
해당 요소에는 반드시 콘텐츠가 있어야 합니다. 이미지(배경 이미지와 동영상 포스터도 포함)나 텍스트 블록이어야 합니다. 대부분의 페이지에서 LCP 요소는 히어로 이미지나 메인 제목입니다.
'양호' 기준은 2.5초 미만입니다. 2026년 8월 CrUX 릴리스에서는 68.1%의 origin만이 이를 달성하여 세 지표 중 가장 낮았습니다.
LCP는 방문자가 보는 화면을 기준으로 삼습니다. 가장 큰 요소가 화면에 나타나면 스크립트가 여전히 로딩 중이더라도 대부분의 사람들은 페이지 로딩이 끝났다고 생각합니다. 이 지표는 '페이지의 콘텐츠가 언제 보이는가?'라는 단 하나의 질문에 답하기 위해 만들어졌습니다.
LCP 요소가 늦게 뜨는 이유는 대개 뻔합니다. 히어로 이미지에 걸린 loading="lazy", 브라우저가 스타일시트를 가져온 뒤에야 발견하는 CSS 배경 히어로 이미지, 첫 번째 슬라이드가 표시되기 전에 먼저 실행되어야 하는 슬라이더 스크립트 등입니다. 먼저 브라우저의 발견 시점부터 고치세요. 그러고 나서도 HTML이 여전히 이미지를 숨기고 있다면 이미지를 preload하고, fetchpriority="high"를 부여하며, 파일 크기를 줄이세요. Largest Contentful Paint 가이드에서 LCP의 4단계를 모두 다룹니다.
Interaction to Next Paint (INP): 상호작용
Interaction to Next Paint는 상호작용을 측정합니다. 방문자가 클릭, 탭 또는 키를 누른 뒤 화면이 업데이트될 때까지 걸리는 시간입니다. 스크롤과 호버는 포함되지 않습니다.
각 상호작용은 입력부터 그로 인해 실행되는 JavaScript를 거쳐 화면에 다음 프레임이 그려질 때까지 측정됩니다. 페이지에는 가장 느린 상호작용의 시간이 기록됩니다. 상호작용이 많은 페이지의 경우, Google은 상호작용 50개마다 이상치 하나를 제외하며, 이는 대략 98번째 백분위수(p98)에 해당합니다.
일반적인 Lighthouse 실행으로는 INP를 측정할 수 없습니다. 페이지를 로드하기만 할 뿐 아무것도 클릭하지 않기 때문입니다. 이에 가장 가까운 lab data 수치는 Total Blocking Time입니다. INP는 보통 TBT보다 훨씬 낮지만, TBT가 내려가면 INP도 따라 개선되는 경향이 있습니다.
클릭 핸들러 자체는 빠른 경우가 많습니다. 클릭이 발생하는 순간 main thread가 다른 작업으로 바쁜 것이 원인입니다. 태그 관리자, 채팅 위젯, 여전히 hydration 중인 프레임워크 등이 자원을 차지하고 있기 때문입니다. 이러한 JavaScript의 대부분은 지연(defer)하거나 스케줄링할 수 있습니다. 2026년 8월 기준 85.3%의 origin이 양호한 INP를 기록했으며, 이는 3월의 87.2%에서 하락한 수치입니다(CrUX 릴리스 노트). 지난 1년 동안 수치가 악화된 유일한 Core Web Vital 지표입니다. Interaction to Next Paint 가이드에서 느린 상호작용을 찾는 방법을 확인할 수 있습니다.
Cumulative Layout Shift (CLS): 시각적 안정성
Cumulative Layout Shift는 시각적 안정성을 측정합니다. 방문자의 의도와 상관없이 눈에 보이는 콘텐츠가 얼마나 움직이는지를 나타냅니다. 링크를 누르려는데 페이지가 덜컥 튀는 경우가 대표적입니다.
레이아웃 이동이 일어날 때마다 점수가 계산됩니다. 영향 분율(impact fraction, viewport에서 영향을 받은 영역의 비율)에 거리 분율(distance fraction, viewport 대비 콘텐츠가 이동한 거리)을 곱합니다. 짧은 간격으로 발생하는 이동은 세션 윈도우 단위로 합산됩니다. 페이지의 CLS는 가장 점수가 나쁜 세션 윈도우의 수치입니다.
주요 원인은 뻔합니다. width와 height가 지정되지 않은 이미지, 로드되면서 콘텐츠를 아래로 밀어내는 광고나 쿠키 배너 및 임베드 요소, fallback 폰트보다 너비나 높이가 큰 웹 폰트 등입니다. 폰트의 경우 직접 호스팅하고 적절한 font-display 설정을 지정하세요. CLS는 대부분의 사이트가 무난하게 통과하는 지표입니다. 2026년 8월 기준 81.5%의 origin이 양호한 CLS를 기록했습니다. 자세한 내용은 Cumulative Layout Shift 가이드에 나와 있습니다.
Core Web Vitals는 왜 중요한가?
- 방문자의 이탈. 0.5초 동안 아무 반응이 없는 버튼은 두 번 클릭된 뒤 이탈로 이어집니다. Google은 Core Web Vitals를 개선해 이탈률을 낮추고 전환율을 높인 사이트들의 사례 연구를 모아두었습니다.
- 검색 순위. Core Web Vitals는 Google의 순위 결정 요소입니다. 영향력이 아주 크지는 않습니다. 두 페이지의 수준이 엇비슷하다면 더 빠른 쪽이 유리합니다.
- 모바일. 트래픽의 대부분은 스마트폰에서 발생하며, 페이지가 탈락하는 곳도 바로 모바일입니다. 최신 판인 2025 Web Almanac에 따르면 데스크톱 페이지의 통과율은 56%였지만 모바일은 48%에 불과했습니다.
- Google Ads. 랜딩 페이지 환경은 품질평가점수에 포함됩니다. 느린 랜딩 페이지는 점수를 떨어뜨리고 클릭당 비용을 높입니다.
Google은 또한 각 지표의 측정 방식을 브라우저 코드 수준까지 정확하게 문서화해 두었습니다. 순위 결정 요소에 대해 이렇게까지 공개하는 일은 거의 없습니다.
Vodafone 사례 연구
Vodafone Italy는 Largest Contentful Paint를 31% 개선하여 매출 8% 증가, 리드 15% 증가, 방문 대비 장바구니 전환율 11% 향상을 달성했습니다(출처: web.dev 사례 연구).
Field Data vs. Lab Data
Field data(Real User Monitoring 또는 RUM 데이터라고도 부름)는 실제 방문자가 사용하는 기기와 네트워크 환경에서 직접 수집됩니다. Google의 CrUX 데이터셋은 동의한 Chrome 사용자로부터 수집된 field data입니다. Core Web Vitals는 오직 field data만으로 평가됩니다.
Lab data는 통제된 환경에서 시뮬레이션 기기를 테스트하여 얻습니다. Lighthouse와 WebPageTest가 lab data를 생성합니다. lab 테스트는 실행할 때마다 거의 동일한 결과를 제공하므로 디버깅에 유용합니다. 하지만 실제 방문자가 경험하는 바를 보여주지는 못합니다.
Lighthouse 점수는 100점인데 왜 탈락하는가?
Google은 CrUX를 기준으로 순위를 매기지만, Lighthouse는 시뮬레이션된 단 한 번의 방문만 테스트하기 때문입니다. 실제 방문자는 저가형 Android 스마트폰과 열악한 호텔 Wi-Fi를 사용하며, Lighthouse가 건드리지도 않는 요소들을 클릭합니다. 게다가 Lighthouse 실행 환경에는 INP가 아예 존재하지도 않습니다.
CrUX는 URL 그룹별 통과 또는 탈락 여부만 제공합니다. 탈락 원인이 된 페이지, 기기, 요소를 구체적으로 찾아내기 위해 저는 Real User Monitoring을 사용합니다. 바로 이 목적으로 만든 도구가 CoreDash입니다. 기기, 국가, 페이지 템플릿별로 데이터를 분류하고, 병목이 되는 LCP 요소나 느린 상호작용을 정확히 짚어냅니다.
Core Web Vitals 측정 방법
측정 도구 비교
| 도구 | 데이터 유형 | CWV 측정 여부 | 주요 용도 |
|---|---|---|---|
| CrUX (Chrome User Experience Report) | Field | 예 (공식) | origin 또는 URL별 Google 공식 사용 수치 확인 |
| PageSpeed Insights | Field + Lab | 예 (CrUX 기반) | 빠른 확인: CrUX 데이터 및 Lighthouse 실행 결과 제공 |
| Lighthouse | Lab 전용 | 아니요 | 단일 페이지의 문제점 진단 |
| Chrome DevTools | Lab 전용 | 아니요 | trace, waterfall, LCP 요소 분석 |
| CoreDash (RUM) | Field | 예 | 페이지·기기·요소별 당일 세부 데이터 확인 |
| Google Search Console | Field (CrUX) | 예 | 통과 및 탈락 URL 그룹 확인 |
CrUX 데이터
CrUX 데이터셋은 일정 수준 이상의 Chrome 트래픽을 보유한 모든 사이트의 Core Web Vitals를 담고 있습니다. Web Vitals 프로그램의 공식 데이터셋입니다. 이 데이터는 몇 가지 방법으로 접근할 수 있습니다:
- CrUX Vis는 특정 origin이나 URL이 지난 몇 달간 기록한 점수 추이를 보여줍니다. Google이 2025년 말 서비스를 종료한 Looker Studio의 기존 CrUX Dashboard를 대체했습니다.
- CrUX on BigQuery는 CrUX의 모든 사이트에 대한 origin 단위 데이터를 제공하며, 매달 업데이트되는 지표별 전체 히스토그램을 포함합니다. 경쟁사와 사이트 성능을 비교할 때 좋습니다.
- CrUX API는 자체 사내 도구에 수치를 연동하고 싶을 때 유용하며, 기기 유형 및 지표별로 필터링된 페이지 또는 origin 단위 데이터를 제공합니다.
- PageSpeed Insights는 특정 URL의 CrUX 데이터를 Lighthouse 보고서 상단에 보여줍니다. 기본적으로 모바일 탭이 열립니다. 모바일 탭을 그대로 보세요. 데스크톱 탭은 초록색인 경우가 많아 통과한 것으로 착각하기 쉽습니다.
RUM을 활용한 모니터링
RUM 데이터는 사이트에 설치된 가벼운 스크립트가 모든 방문을 측정하여 수집합니다. CrUX와 동일한 Core Web Vitals를 측정하면서도, CrUX에서는 빠져 있는 세부 정보까지 기록합니다. CrUX는 익명화되어 있고 URL 단위에서 멈추며 항상 지난 28일치만 반영합니다. 반면 RUM은 어제의 데이터를 페이지, 기기, 국가, 브라우저별로 보여주며, 어떤 요소가 느린 LCP나 레이아웃 이동을 유발했는지까지 정확히 알려줍니다. Core Web Vitals 개선을 업으로 삼는 대부분의 엔지니어가 CrUX와 RUM을 함께 운용하는 이유입니다.
Lighthouse
Lighthouse는 Core Web Vitals를 측정하지 않습니다. 네트워크 속도가 제한된 시뮬레이션 스마트폰에서 단일 페이지를 딱 한 번 로드할 뿐입니다. 비어 있는 캐시로 시작하며, 두 번째 페이지로 이동하지도 않고 아무것도 클릭하지 않습니다.
그럼에도 렌더링을 차단(render blocking)하는 요소, LCP 요소인 이미지, main thread를 점유하는 스크립트를 확인하는 가장 빠른 방법입니다. 다만 권장 목록의 절반은 무시해도 좋습니다. CSS를 압축(minify)해 봤자 고작 몇 킬로바이트 절약될 뿐이며, 방문자 중 누구도 이를 알아채지 못합니다.
PageSpeed Insights, Chrome DevTools, 또는 Lighthouse CLI 도구를 통해 실행해 보세요.
얼마나 많은 사이트가 통과하는가?
Chrome 팀은 매월 두 번째 화요일에 CrUX 릴리스 노트를 통해 CrUX 수치를 발표합니다. 모든 기기를 합산했을 때 '양호' 점수를 기록한 origin의 비율은 다음과 같습니다:
| 지표 | 2025년 8월 | 2026년 8월 | 비고 |
|---|---|---|---|
| LCP | 66.7% | 68.1% | 세 지표 중 가장 낮음. 대부분의 사이트에서 통과 여부를 결정짓는 지표 |
| INP | 85.7% | 85.3% | 3월 이후 매달 하락 중이며, Google도 아직 원인을 내놓지 못함 |
| CLS | 80.1% | 81.5% | 세 지표 중 가장 우수함 |
| 세 지표 모두 | 53.5% | 55.6% | 총 1,830만 개 origin 기준 |
비교는 반드시 전년 동월과 대조하십시오. 12월 수치는 매년 변동 폭이 크므로(CrUX 출시 이래 Chrome 팀이 매년 확인해 온 현상입니다), 특정 달의 결과가 나쁘다고 해서 큰 의미를 둘 필요는 없습니다. 릴리스 노트에 나오지 않는 TTFB와 FCP에 대해서는 Time to First Byte 가이드 및 First Contentful Paint 가이드를 참고하세요.
Core Web Vitals 개선 방법
제가 점검을 시작하는 순서는 이렇습니다. 먼저 모바일 환경에서 지표별 p75를 확인하고, Search Console이 지적한 URL 그룹을 검토한 뒤, 전체적인 추세를 봅니다. 점수가 갑자기 급락했다면 대개 배포가 원인입니다. 완만하게 하락하고 있다면 태그가 하나둘 쌓이면서 서드파티 스크립트가 누적된 탓입니다.
새로운 배포가 있을 때마다 언제든 다시 문제가 생길 수 있으므로, 수정 사항이 반영된 후에도 field data를 계속 관찰하세요. 또한 지표들은 서로 영향을 줍니다. font-display: swap을 쓰면 텍스트가 화면에 더 빨리 표시되어 LCP 개선에 도움이 될 수 있지만, 웹 폰트 크기가 fallback과 다르면 교체되는 순간 레이아웃 이동이 발생합니다. 각 지표별 가이드는 다음과 같습니다:
LCP 개선을 가로막는 두 가지 진단 지표가 있습니다:
- Time to First Byte (TTFB): HTML이 도착하기 전에는 브라우저가 페이지 처리를 시작조차 할 수 없습니다. TTFB가 느리면 양호한 LCP를 달성하기란 거의 불가능합니다. CDN에서 HTML을 캐싱하는 것이 대개 가장 빠른 해결책입니다.
- First Contentful Paint (FCP): 어떤 콘텐츠든 화면에 처음으로 그려지는 시점입니다. 이 시점 전까지 방문자는 빈 흰 화면만 보게 됩니다.
단계별 작업 목록이 필요하다면 Core Web Vitals 체크리스트를 활용하세요.
Search Console의 Core Web Vitals
Google은 과거에 Core Web Vitals를 HTTPS, 모바일 친화성, 전면 광고와 함께 "페이지 경험"으로 묶어 다뤘습니다. 하지만 2024년 11월 Search Console에서 페이지 경험 보고서를 삭제했습니다. Core Web Vitals 보고서는 여전히 '경험' 메뉴 아래에 남아 있습니다.
이 보고서는 URL을 템플릿별로 묶어 어느 그룹이 통과했는지 보여줍니다. 지난 28일치 데이터를 다루기 때문에, 수정 사항을 배포하고 2주가 지나도 표시되는 데이터의 절반은 여전히 이전 사이트의 수치입니다.
Core Web Vitals FAQ
Core Web Vitals 학습하기
Core Web Vitals 전문가가 되려면 무엇을 공부해야 하는가?
어떤 Core Web Vitals 문제는 5분이면 해결되지만, 어떤 문제는 수년간의 경험이 필요합니다. 네 가지를 알아야 합니다.
첫째, 브라우저 동작 원리입니다. 라벨 표시 없이도 파싱, 스타일, 레이아웃, 페인트를 구분할 수 있을 때까지 Performance 패널의 trace를 읽어보세요.
둘째, JavaScript입니다. 저는 개발자들에게 코드가 왜 느린지 설명하는 데 많은 시간을 씁니다. 느린 코드는 INP를 해치고, 보통 LCP와 FCP까지 악화시킵니다.
셋째, HTML과 CSS입니다. 동일한 컴포넌트를 만들더라도 빠른 방식과 느린 방식이 나뉩니다.
넷째, 네트워크와 서버입니다. 캐싱 헤더, 압축, HTTP/2 및 HTTP/3 등이 여기에 해당합니다. 대기업에는 유능한 개발자가 많으며, 이들은 이 네 가지 모두에 대해 질문할 것입니다.
Core Web Vitals 개선
Core Web Vitals 플러그인이 효과가 있는가?
때에 따라 다릅니다. WP Rocket처럼 Core Web Vitals 개선을 내세우는 플러그인은 아주 많습니다. 이에 대해서는 몇 시간이고 이야기할 수 있지만, 요점만 짧게 말씀드리겠습니다.
어떤 문제가 발생했는지에 따라 다릅니다. lazy loading이 적용되지 않은 이미지나 defer 처리되지 않은 스크립트는 플러그인으로 해결할 수 있습니다. 하지만 JavaScript로 레이아웃을 다시 짜는 슬라이더나 요소가 5,000개에 달하는 DOM은 그대로 남습니다. 또한 "첫 상호작용까지 모든 JavaScript를 지연시키는" 꼼수는 그 모든 부하를 첫 클릭 시점으로 몰아넣으며, 이는 정확히 INP가 측정하는 대상입니다.
플러그인이 해주는 일은 유능한 개발자가 몇 시간 만에 끝낼 수 있는 작업에 불과합니다. 까다로운 문제는 플러그인을 도입한 뒤에도 여전히 남아 있습니다.
모바일과 데스크톱 중 어디에 집중해야 하는가?
모바일입니다. 스마트폰은 일반적인 데스크톱보다 대역폭이 좁고 메모리가 적으며 CPU도 느립니다. 모바일에서 통과하면 데스크톱도 대개 함께 통과합니다.
예외도 있습니다. 데스크톱은 viewport가 더 크기 때문에 LCP 요소가 달라질 수 있습니다. 모바일에서는 제목인 경우가 많지만, 데스크톱에서는 화면 아래쪽의 이미지일 수 있습니다. 또한 데스크톱은 화면에 표시되는 요소가 더 많아 레이아웃 이동이 일어날 가능성이 크므로 CLS가 더 나빠질 수 있습니다.
측정: CrUX, RUM, 합성 데이터
URL 단위 데이터를 사용할 수 없는 경우 Google은 Core Web Vitals를 어떻게 평가하는가?
Google은 먼저 개별 URL의 CrUX 데이터를 확인합니다. 해당 URL의 트래픽이 너무 적으면 유사한 URL 그룹의 데이터를 사용할 수 있습니다(Search Console에서 이러한 그룹을 보여줍니다). 그룹 데이터도 없다면 전체 origin 데이터를 사용합니다.
Core Web Vitals 데이터는 실시간인가?
아닙니다. 그렇다고 28일 전 데이터인 것도 아닙니다. CrUX 데이터는 약 이틀 전의 데이터입니다. 현재 표시되는 수치는 지난 28일간의 p75이므로, 오늘 배포된 수정 사항은 내일 시점에서 28일 중 하루치에 불과합니다. 기준치 경계에 있던 사이트라면 1~2주 만에도 p75가 움직일 수 있습니다. 전반적으로 느렸던 사이트라면 4주를 꽉 채워 기다려야 합니다. 28일 수집 기간에 대한 자세한 내용.
Search Console이나 기타 CrUX 도구에 데이터가 없는 이유는 무엇인가?
해당 사이트에 대한 Chrome 사용자의 방문 데이터가 Google에 충분히 쌓이지 않았기 때문입니다. CrUX는 최소 기준치 이상의 트래픽이 있는 페이지와 origin만 보고합니다. 신규 사이트, 소규모 사이트, 로그인 뒤에 있는 페이지는 데이터가 아예 없는 경우가 많습니다.
Lighthouse 점수가 Core Web Vitals에 영향을 미치는가?
아닙니다. Google은 CrUX field data를 사용하며, Lighthouse 점수는 여기에 포함되지 않습니다. Lighthouse는 페이지를 느리게 만드는 원인을 진단하는 데 사용하세요. Core Web Vitals는 실제 방문자가 더 빠른 페이지를 경험할 때만 바뀝니다.
Core Web Vitals 자주 묻는 질문
Core Web Vitals 3대 지표는 무엇인가?
로딩을 측정하며 2.5초 미만이어야 양호한 Largest Contentful Paint (LCP), 응답성을 측정하며 200밀리초 미만이어야 양호한 Interaction to Next Paint (INP), 시각적 안정성을 측정하며 0.1 미만이어야 양호한 Cumulative Layout Shift (CLS)입니다. 75번째 백분위수에서 세 지표가 모두 양호해야 페이지가 통과합니다.
Core Web Vitals 점수가 따로 있는가?
아닙니다. 단일 점수는 존재하지 않습니다. 각 지표는 p75 기준으로 양호, 개선 필요, 느림으로 나뉘며, 세 지표가 모두 양호해야 URL이 통과합니다. PageSpeed Insights에 표시되는 0~100점 점수는 Lighthouse 성능 점수입니다. 이는 lab 점수일 뿐이며, Google은 이를 기준으로 순위를 매기지 않습니다.
Core Web Vitals는 순위 결정 요소인가?
그렇습니다. 2021년 6월부터 적용되었습니다. 비중은 작습니다. 가장 알맞은 답변을 담은 느린 페이지가 부실한 답변의 빠른 페이지보다 여전히 높은 순위를 차지합니다. 하지만 두 페이지의 품질이 엇비슷하다면, 통과한 쪽이 유리합니다.
field data와 lab data의 차이는 무엇인가?
Field data는 실제 방문자의 기기와 네트워크 환경에서 브라우저가 직접 측정한 데이터입니다. Lab data는 Lighthouse나 WebPageTest처럼 시뮬레이션된 기기에서 테스트하여 얻은 데이터입니다. Lab data는 재현 가능하므로 디버깅에 적합합니다. Google은 Core Web Vitals 평가에 오직 field data만 사용하므로, 완벽한 Lighthouse 점수가 통과를 보장하지 않으며, 점수가 나쁘다고 해서 무조건 탈락하는 것도 아닙니다.
