핵심 웹 바이탈

TL;DR — 핵심 웹 바이탈은 실제 사용자가 페이지를 어떻게 느끼는지 측정하는 Google의 세 가지 지표입니다. LCP는 로딩 속도, INP는 탭하거나 클릭했을 때의 반응 속도, CLS는 로딩 중 화면이 얼마나 움직이는지를 나타냅니다. “좋음” 기준은 LCP 2,5초 이하, INP 200밀리초 이하, CLS 0,1 이하입니다. 순위에 어느 정도 영향을 주지만 좋은 콘텐츠가 훨씬 더 중요합니다.

핵심 웹 바이탈이란?

Google은 사용하기 쾌적한 페이지를 보상하기 위해 “좋은 페이지 경험”을 측정 가능한 세 가지 요소로 정리했습니다. 이를 합쳐 **핵심 웹 바이탈(Core Web Vitals, CWV)**이라고 합니다.

• Largest Contentful Paint (LCP) — 로딩. 화면에서 가장 큰 요소(대개 히어로 이미지나 제목)가 나타날 때까지 걸리는 시간입니다. 좋음은 2,5초 이하입니다.
• Interaction to Next Paint (INP) — 반응성. 버튼을 누르거나 입력한 뒤 페이지가 반응하기까지 걸리는 시간입니다. 좋음은 200밀리초 이하입니다.
• Cumulative Layout Shift (CLS) — 시각적 안정성. 로딩 중 페이지가 얼마나 움직이는지 측정합니다. 예를 들어 누르려는 순간 광고가 텍스트를 아래로 밀어내는 경우입니다. 좋음은 0,1 이하입니다.

점수는 어디에서 오나요?

Google이 실제로 사용하는 점수는 직접 실행한 테스트가 아니라 Chrome에서 실제 사용자가 사이트를 방문하며 생성한 데이터에서 나옵니다. Google은 이 데이터를 수집해 **방문자의 75%**가 겪은 경험을 기준으로 페이지를 평가합니다. 따라서 내 컴퓨터에서 한 번 빠른 결과를 얻었다고 “통과”하는 것은 아닙니다. 실제 방문자 대부분이 좋은 경험을 해야 합니다. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

그래서 속도 테스트 도구에서 만점을 받아도 통과가 보장되지 않습니다. PageSpeed Insights와 Lighthouse 같은 도구는 모의 휴대전화에서 한 번의 실험실 테스트를 실행합니다. 문제를 찾는 데는 훌륭하지만 Google이 순위 평가에 사용하는 수치는 아닙니다.

순위에 영향을 주나요?

어느 정도는 그렇습니다. Google은 순위 시스템에서 핵심 웹 바이탈을 사용한다고 말하지만 공식 가중치나 비율을 공개하지 않았고, 페이지 경험이 좋지 않아도 관련성 높은 콘텐츠가 더 높은 순위를 차지할 수 있다고 명시합니다. 콘텐츠가 관련성이 없다면 빠르고 안정적이어도 소용없습니다. Google의 John Mueller는 “it’s not going to make your site’s rankings jump up.” (번역) “사이트 순위가 갑자기 뛰어오르게 하지는 않습니다”라고 말했습니다.

오랫동안 이 분야를 다룬 제 솔직한 판단은 이렇습니다. 대부분의 사이트는 이 수치를 좇는다고 큰 순위 이익을 얻지 못합니다. 그래도 사이트를 더 빠르고 안정적으로 만드는 일은 좋습니다. 순위가 움직이지 않아도 방문자가 체감하고 전환에 도움이 됩니다.

사람들이 자주 틀리는 한 가지

예전 이름 주의: 아직도 **FID (First Input Delay)**를 핵심 웹 바이탈로 소개하는 자료가 있을 수 있습니다. 이제는 아닙니다. 2024년 3월 12일에 INP가 FID를 대체했습니다. 아직 FID 최적화를 권하는 도구나 글은 오래된 정보입니다.

정확한 기준값, 필드 데이터와 실험실 데이터의 차이, 실제 순위 영향, 상황별 측정 도구까지 자세히 보려면 고급 탭으로 전환하세요.

TL;DR — 핵심 웹 바이탈은 필드에서 측정하는 세 가지 UX 지표입니다. LCP(로딩, “좋음” ≤ 2,5 s), INP(반응성, ≤ 200 ms), CLS(시각적 안정성, ≤ 0,1)를 실제 Chrome 사용자(CrUX)의 p75 백분위수, 이동 28일 기간으로 평가합니다. 기준값은 모바일과 데스크톱에서 같지만 Google은 기기별로 따로 평가하며, 하나가 아니라 세 지표 모두 좋아야 한다고 봅니다. INP는 2024년 3월 12일에 FID를 대체했습니다. Google은 순위 시스템이 핵심 웹 바이탈을 사용한다고 말하지만 공식 가중치나 “동률 결정” 비율은 없습니다. 좋은 점수가 더 높은 순위를 보장하지 않으며 관련성이 우선할 수 있습니다. Lighthouse/PSI의 실험실 점수는 진단용이며 필드 데이터와 자주 다릅니다. TTFB와 FCP는 진단용 “기타 Web Vitals”, TBT와 Speed Index는 실험실 대리 지표입니다.

핵심 웹 바이탈에 포함되는 지표

Google은 핵심 웹 바이탈을 “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (번역) “모든 웹페이지에 적용되고 모든 사이트 소유자가 측정해야 하며 모든 Google 도구에 표시되는 Web Vitals의 하위 집합”이라고 정의합니다. 정확히 세 가지이며, 각각 페이지 경험의 다른 차원을 측정합니다.

Google은 세 가지 “좋음” 기준을 p75 백분위수에서 평가합니다. LCP는 2,5초, INP는 200밀리초, CLS는 0,1입니다. p75에서 한두 개가 아니라 세 지표 모두 기준을 넘어야 페이지 전체가 “좋음”으로 평가됩니다. 기준값은 모바일과 데스크톱에서 같지만 Google은 기기 유형별로 따로 평가하고 보고합니다. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

TTFB, FCP, TBT, Speed Index 등 그 밖의 지표는 핵심 웹 바이탈이 아닙니다. 아래에서 더 설명합니다.

LCP — 로딩

LCP는 “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (번역) 사용자가 처음 페이지로 이동한 시점을 기준으로 뷰포트에 보이는 가장 큰 이미지·텍스트 블록·동영상의 렌더링 시간을 보고합니다. 실무에서 LCP 요소는 대개 히어로 이미지, 큰 배경 이미지 또는 제목 블록입니다. 가장 큰 가시 요소이므로 뷰포트 크기에 따라 LCP 요소가 달라질 수 있고, 이것이 필드와 실험실 수치가 갈리는 이유 중 하나입니다.

INP — 반응성

INP는 “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (번역) 사용자가 페이지를 방문하는 동안 발생하는 모든 클릭·탭·키보드 상호작용의 지연 시간을 관찰해 페이지의 전반적인 반응성을 평가합니다. 입력 지연 → 이벤트 처리 → 다음 프레임을 그리는 시간까지 전체 상호작용을 측정합니다.

이 점이 이전 지표보다 크게 개선된 부분입니다. FID는 첫 상호작용의 입력 지연만 측정했지만 INP는 모든 상호작용을 관찰합니다. INP는 2024년 3월 12일에 First Input Delay (FID)를 대체해 핵심 웹 바이탈이 되었습니다. Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch 같은 날 Search Console에서도 FID가 제거되었습니다. 완전히 폐기된 지표이므로 더 이상 최적화하지 마세요.

기억할 세부 사항이 하나 있습니다. INP는 한 번의 최악 상호작용이 아니라 전체 상호작용의 높은 백분위수입니다. 한 번 버벅인 클릭만으로 나머지가 좋은 페이지 전체가 망가지지는 않습니다.

CLS — 시각적 안정성

CLS는 “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (번역) 페이지 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동 중 가장 큰 이동 점수 묶음을 측정합니다. 이 “묶음”(세션 창)은 1초 이내에 연달아 발생한 이동을 최대 5초 창으로 그룹화합니다. Google이 꼽는 흔한 원인은 “images or videos with unknown dimensions,” (번역) 크기를 알 수 없는 이미지·동영상, “fonts that render larger or smaller than its initial fallback,” (번역) 초기 대체 글꼴보다 크거나 작게 렌더링되는 글꼴, 그리고 “third-party ads or widgets that dynamically resize themselves.” (번역) 동적으로 크기가 바뀌는 서드파티 광고·위젯입니다.

필드 데이터와 실험실 데이터 — 측정과 진단

가장 많은 혼란을 만드는 차이이므로 정확히 구분해야 합니다.

• **필드 데이터(CrUX)**는 “data collected from the real users visiting your site.” (번역) 사이트를 방문하는 실제 사용자에게서 수집한 데이터입니다. 이동 28일 기간의 p75 백분위수로 보고되며 모바일과 데스크톱으로 나뉩니다. 핵심 웹 바이탈은 이런 실제 환경 경험을 나타내며 Google 순위 시스템에서 사용됩니다. 실제 기기, 네트워크, 캐시 상태, 뒤로/앞으로 가기 캐시가 반영됩니다.
• 실험실 데이터는 “data collected in a controlled environment with predefined device and network settings” (번역) 미리 정한 기기·네트워크 설정의 통제된 환경에서 수집한 데이터입니다. 모의 휴대전화 한 대, 콜드 캐시, 실제 사용자 없음이라는 조건입니다. Lighthouse와 PageSpeed Insights의 실험실 섹션이 이를 생성합니다. 필드 측정값이 아니라 문제를 찾기 위한 진단 도구입니다. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Google의 지침은 “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (번역) 같은 페이지에 필드와 실험실 데이터가 모두 있다면 필드 데이터를 기준으로 작업 우선순위를 정하라고 말합니다. Lighthouse의 Performance Score는 “often does not correlate with field Core Web Vitals.” (번역) 필드 핵심 웹 바이탈과 자주 상관관계가 없습니다. 제 Core Web Vitals 가이드에서도 같은 이유로 실험실 데이터는 테스트와 반복 개선에 더 유용하다고 설명합니다. 필드 CWV는 28일 이동 평균이므로 수정 효과가 보이기까지 몇 주가 걸립니다.

p75 규칙과 그 중요성

**실제 사용자의 75%**가 “좋음” 기준을 충족해야 통과합니다. 의도적으로 관대하면서도 현실적인 기준입니다. 방문자 4명 중 3명은 좋은 경험을 해야 하지만, 매우 나쁜 연결을 쓰는 일부 이상치 때문에 평가가 좌우되지는 않습니다. 내 휴대전화에서 1,8s가 나왔다는 사실만으로는 의미가 없는 이유도 같습니다. 전체 사용자의 p75가 중요합니다.

페이지 수준과 오리진 수준 — 착각하지 마세요

많은 도구는 기본적으로 개별 페이지보다 훨씬 좋아 보일 수 있는 오리진 수준(사이트 전체 평균) 점수를 보여 줍니다. 제 CWV 데이터 연구에서는 CrUX와 Ahrefs Site Audit의 5,2M개 페이지를 분석했는데, 세 기준을 모두 통과한 비율은 개별 페이지 21,2%, **오리진 수준 33%**였습니다. Google의 페이지 경험 문서는 시스템이 일반적으로 페이지를 개별 평가하지만 더 넓은 사이트 전체 평가도 수행한다고 설명합니다. 따라서 “통과”한 오리진 안에도 실패한 개별 페이지가 많을 수 있습니다. 두 보기가 모두 있다면 오리진 평균으로 특정 페이지 상태를 단정하지 말고 페이지 수준 수치도 확인하세요.

트래픽이 부족한 페이지에는 CrUX 필드 데이터가 전혀 없을 수도 있습니다. CrUX에는 사용 통계 제공에 동의한 Chrome 사용자만 포함되며 iOS Chrome이나 다른 브라우저는 포함되지 않습니다. 이는 데이터 적격성의 공백이지 실패가 아닙니다. 필드 데이터 부재와 낮은 점수는 다릅니다. 도구가 유사 페이지를 묶거나 저트래픽 URL에 대체 데이터를 적용하는 구체적 방식(PSI, Search Console, CrUX API)은 각 제품 문서에 따르며 보편적인 단일 규칙은 없습니다.

핵심 웹 바이탈은 실제로 순위에 얼마나 중요한가요?

핵심 웹 바이탈은 확인된 순위 신호입니다. Google은 순위 시스템에서 이를 사용한다고 말합니다. 다만 현재 문서는 공식 가중치, 비율 또는 “동률 결정”이라는 이름을 붙이지 않습니다. 그런 표현을 Google의 공식 설명처럼 반복하지 않도록 주의하세요.

“실재하는 신호”라는 근거로 Google 문서는 핵심 웹 바이탈이 “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (번역) 다른 페이지 경험 요소와 함께 핵심 순위 시스템이 보상하려는 바와 일치한다고 설명합니다. John Mueller도 “more than a tie-breaker, but it also doesn’t replace relevance.” (번역) 동률 결정 요소 이상이지만 관련성을 대체하지는 않는다고 공개적으로 말했습니다.

반대로 과대평가하지 말아야 할 근거도 있습니다. Mueller는 “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (번역) CWV는 거대한 순위 요소가 아니며 이것만으로 큰 하락이 생기지는 않을 것이라고 했고, 2024년 3월 문서 업데이트 때 LinkedIn에서 “it’s not going to make your site’s rankings jump up.” (번역) 사이트 순위를 갑자기 올려 주지는 않는다고 덧붙였습니다. Google의 페이지 경험 문서도 “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (번역) 페이지 경험이 좋지 않아도 항상 가장 관련성 높은 콘텐츠를 보여 주려 한다고 명확히 말합니다. 2024년 문서는 “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (번역) SEO만을 위해 만점을 얻으려는 시도는 시간을 가장 잘 쓰는 방법이 아닐 수 있다고 경고하기도 합니다. Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

제 실용적인 해석은 이렇습니다. 관련성이 지배적이고 Google은 CWV의 비중을 수치로 공개하지 않았으며, 대부분의 사이트는 순위 때문에 이 지표를 개선해도 큰 이익을 보지 못할 것입니다. 그래도 기본 UX 개선은 사용자와 전환에 가치가 있고 WordPress, Cloudflare, 프레임워크 같은 플랫폼이 최적화 부담을 계속 자동으로 흡수하고 있습니다. 특히 소규모·지역 비즈니스라면 보통 최우선 과제가 아닙니다.

2024년 업데이트의 또 다른 명확한 설명은 더 넓은 페이지 경험 신호 중 순위에 직접 기여한다고 확인된 것은 핵심 웹 바이탈뿐이라는 점입니다. HTTPS, 모바일 친화성, 방해되는 전면 광고 제거, 콘텐츠 명료성은 모두 좋은 관행이지만, 과거 문서가 암시했던 방식으로 순위를 직접 높이지는 않습니다.

”기타 Web Vitals” — 핵심 지표가 아닌 진단 지표

다음 지표는 자주 언급되고 잘못 분류되지만 어느 것도 핵심 웹 바이탈이 아닙니다.

• Time to First Byte (TTFB) — 응답의 첫 바이트가 도착할 때까지의 시간입니다. 다른 모든 의미 있는 로딩 성능 지표보다 “precedes every other meaningful loading performance metric” (번역) 앞서며 LCP에도 영향을 줍니다. 하지만 Google은 “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (번역) TTFB는 핵심 웹 바이탈이 아니므로 사이트가 반드시 “좋음” 기준을 충족할 필요는 없다고 명시합니다. 좋음 ≤ 0,8 s인 진단 지표입니다.
• First Contentful Paint (FCP) — 어떤 콘텐츠든 처음 그려질 때까지의 시간입니다. 좋음 ≤ 1,8 s인 유용한 로딩 진단 지표지만 핵심 지표는 아닙니다.
• Total Blocking Time (TBT) — INP의 실험실 대리 지표입니다. Lighthouse 같은 도구는 실제 사용자가 없으면 *“cannot measure INP”*하므로 대신 TBT를 보고합니다. 실험실 전용입니다.
• Speed Index — 체감 로딩 속도의 실험실 대리 지표입니다. Lighthouse 전용입니다.

이 지표들은 디버깅에 사용하세요. 핵심 웹 바이탈로 보고하거나 기준값을 순위 관문으로 취급하지 마세요.

이제 버려야 할 오해

**“Engagement Reliability”**가 새로운 핵심 웹 바이탈이라는 주장을 볼 수 있습니다. 그런 지표에 대한 Google의 공식 발표는 없습니다. 서드파티 콘텐츠에서만 돌고 있는 이야기입니다. 핵심 웹 바이탈은 LCP, INP, CLS입니다. Google이 달리 발표하기 전까지 목록은 이 셋입니다.

측정 방법과 상황별 도구

작업에 맞는 도구를 선택하세요.

• 순위 관련 필드 데이터: PageSpeed Insights(페이지·오리진 수준 CrUX 필드 데이터), Google Search Console의 핵심 웹 바이탈 보고서(유사 페이지 그룹과 사이트 전체 패턴), CrUX API / BigQuery(맞춤형·국가별 분석), web-vitals JS 라이브러리(자체 RUM 수집).
• 디버깅용 실험실 데이터: Lighthouse, Chrome DevTools Performance 패널, PSI 실험실 섹션. 원인을 찾는 도구이며 순위를 결정하지 않습니다.

권장 흐름은 GSC에서 필드 데이터가 실패한 페이지 그룹을 찾고, PageSpeed Insights에서 페이지 수준으로 확인한 다음, Lighthouse / DevTools에서 원인을 진단하고 반복 개선하는 것입니다. 필드 수치는 최대 28일 동안 갱신되지 않을 수 있음을 감안하세요.

다음 단계: 웹 성능 클러스터

이 허브는 전체 주제의 지도입니다. 아래 각 주제에는 별도의 심층 글이 있습니다.

세 가지 핵심 웹 바이탈

• Largest Contentful Paint — 로딩 지표: 어떤 요소가 LCP인지, ≤2,5 s 목표, 더 빨리 표시하는 방법.
• Interaction to Next Paint — FID를 대체한 반응성 지표: 입력 지연, 이벤트 처리, 표시 지연과 각각을 줄이는 방법.
• Cumulative Layout Shift — 시각적 안정성 지표: 세션 창, 흔한 원인(크기가 지정된 미디어, 글꼴, 삽입 광고), ≤0,1 달성 방법.

지원·진단 지표

• Time to First Byte — LCP에 영향을 주는 서버/응답 지연으로, 핵심 웹 바이탈이 아닌 디버깅 지표입니다.
• First Contentful Paint — 첫 콘텐츠가 표시되는 시점인 로딩 진단 지표입니다.
• Total Blocking Time — Lighthouse가 INP를 근사하는 실험실 대리 지표입니다.
• Speed Index — 체감 로딩 속도의 실험실 대리 지표입니다.

측정 방식

• PageSpeed Insights — 필드(CrUX) 데이터와 Lighthouse 실험실 보고서를 한곳에서 제공합니다.
• Google Lighthouse — PSI와 DevTools의 기반이 되는 실험실·진단 엔진입니다.
• Chrome UX Report (CrUX) — Google 평가의 기반이 되는 실제 사용자 데이터셋입니다.

전체 클러스터는 웹 성능 허브에서 확인하세요. 각 형제 문서는 공개될 때 이 문서로 자동 연결됩니다.

AI 요약

고급 버전의 핵심을 압축하면 다음과 같습니다.

• 핵심 웹 바이탈 = 세 가지 필드 지표: LCP(로딩, 좋음 ≤ 2,5 s), INP(반응성, ≤ 200 ms), CLS(시각적 안정성, ≤ 0,1). TTFB, FCP, TBT, Speed Index 등은 핵심 지표가 아닙니다.
• 필드 데이터로 평가: 실제 Chrome 사용자의 CrUX 데이터를 이동 28일 기간의 p75 백분위수에서 봅니다. 모바일과 데스크톱의 기준은 같지만 별도 평가하며, 하나가 아니라 세 지표 모두 좋아야 합니다.
• INP는 2024년 3월 12일에 FID를 대체했습니다. FID는 완전히 폐기되었고 INP는 첫 상호작용뿐 아니라 모든 상호작용을 측정합니다.
• 실험실 도구(Lighthouse/PSI)는 진단용이며 필드 측정값이 아니고 필드 CWV와 자주 다릅니다. 원인을 찾는 데 쓰며 필드 수치는 최대 28일 뒤처집니다.
• 페이지 수준과 오리진 수준은 다릅니다: 제 CWV 연구에서 통과율은 페이지 약 21,2%, 오리진 약 33%였습니다. Google은 페이지 수준을 사용하므로 오리진 평균은 실패 페이지를 숨길 수 있습니다.
• 순위 가중치: 사용하지만 수치는 미공개. Google은 순위 시스템이 핵심 웹 바이탈을 사용한다고 말하지만 공식 비율이나 “동률 결정” 명칭은 없습니다. 관련성이 우선하며 좋은 점수는 순위를 보장하지 않습니다. Mueller는 “not giant factors in ranking.” (번역) 순위에서 거대한 요소는 아니라고 했습니다. 2024년 문서에 따르면 HTTPS, 모바일 친화성, 전면 광고가 아니라 CWV만 직접 기여합니다.
• 피해야 할 오해: “Engagement Reliability”는 확인된 핵심 웹 바이탈이 아닙니다.
• 도구: 필드 = PSI, GSC CWV 보고서, CrUX API, web-vitals.js. 디버깅 = Lighthouse, DevTools, PSI 실험실 섹션.

공식 문서

Google의 1차 출처 문서입니다.

web.dev (Chrome 팀)

• Web Vitals — 이니셔티브, 세 지표, p75 규칙, TTFB/FCP가 “기타” Web Vitals인 이유.
• Largest Contentful Paint (LCP) — 정의, 기준값, LCP 후보 요소.
• Interaction to Next Paint (INP) — 정의, 기준값, 입력 지연 → 처리 → 표시의 구성.
• Cumulative Layout Shift (CLS) — 정의, 세션 창, 흔한 원인.
• 핵심 웹 바이탈 지표 기준값 정의 — 각 “좋음” 기준과 p75 백분위수를 선택한 이유.
• 실험실 데이터와 필드 데이터의 차이 — 필드(CrUX)와 실험실(Lighthouse) 수치가 다른 이유.
• 핵심 웹 바이탈 워크플로/도구 — 필드·실험실 데이터를 보고하는 도구.
• INP의 Core Web Vitals 승격(2023년 5월) — INP가 FID를 대체한다는 발표.
• Interaction to Next Paint가 공식 Core Web Vital이 됨(2024년 3월 12일) — 출시 확인.
• TTFB와 FCP — 진단용 “기타 Web Vitals”.

Google Search Central

• 핵심 웹 바이탈과 Google 검색 결과 이해 — CWV와 순위의 관계.
• Google 검색 결과의 페이지 경험 이해 — 더 넓은 페이지 경험과 “관련성이 우선”이라는 설명.
• Core Web Vitals에 INP 도입(2023년 5월) — Search Central 발표.

Chrome 개발자 문서

• Chrome 사용자 경험 보고서(CrUX) — 실제 사용자 데이터셋, 적격성, 28일 기간.

출처 인용문

Google의 공개 발언입니다. 각 링크는 출처 페이지의 해당 구절로 바로 이동합니다.

Google — 핵심 웹 바이탈의 정의

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (번역) 핵심 웹 바이탈은 모든 웹페이지에 적용되고 모든 사이트 소유자가 측정해야 하며 모든 Google 도구에 표시되는 Web Vitals의 하위 집합입니다. — Philip Walton, web.dev. 인용문으로 이동
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (번역) LCP는 사용자가 처음 페이지로 이동한 시점을 기준으로 뷰포트에 보이는 가장 큰 이미지·텍스트 블록·동영상의 렌더링 시간을 보고합니다. — web.dev (LCP). 인용문으로 이동
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (번역) INP는 사용자가 페이지에 머무는 동안 발생하는 모든 클릭·탭·키보드 상호작용의 지연을 관찰해 전반적인 반응성을 평가합니다. — web.dev (INP). 인용문으로 이동
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (번역) CLS는 페이지 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동 중 가장 큰 이동 점수 묶음을 측정합니다. — web.dev (CLS). 인용문으로 이동

Google — INP의 FID 대체

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (번역) INP는 이제 FID를 대체하는 안정적인 핵심 웹 바이탈 지표입니다. — Rick Viscomi, web.dev (2024년 3월 12일). 인용문으로 이동

Google — 필드와 실험실, 그리고 순위

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (번역) 같은 페이지에 필드와 실험실 데이터가 모두 있다면 필드 데이터로 작업 우선순위를 정해야 합니다. — Philip Walton, web.dev. 인용문으로 이동
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (번역) CrUX는 실제 Chrome 사용자가 웹의 인기 사이트를 어떻게 경험하는지 반영하는 데이터셋입니다. — Chrome 개발자 문서(CrUX). 인용문으로 이동

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (번역) 순위 요소이며 동률 결정 요소 이상이지만 관련성을 대체하지는 않습니다. — Search Engine Journal 보도(Reddit, 2021년 8월). 보도 읽기
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (번역) 핵심 웹 바이탈은 거대한 순위 요소가 아니며 이것만으로 큰 하락이 생기지는 않을 것입니다. — Stan Ventures 보도(2024). 보도 읽기

핵심 웹 바이탈 체크리스트

올바른 지표를 측정하고 올바른 페이지를 수정하는지 빠르게 확인하세요.

• Google이 순위에 사용하는 지표는 실험실 점수만이 아니라 필드 데이터(CrUX)에서 확인한다.
• 오리진 평균만 보지 않고 페이지 수준 수치를 확인한다.
• p75에서 LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 세 가지를 모두 확인한다.
• Google이 별도 평가하는 모바일과 데스크톱을 각각 검토한다.
• 2024년 3월 12일에 폐기된 FID를 최적화하지 않고 INP를 사용한다.
• GSC 핵심 웹 바이탈 보고서에서 개별 사례가 아닌 실패 페이지 그룹을 검토한다.
• 트래픽이 적은 페이지에는 CrUX 필드 데이터가 전혀 없을 수 있음을 이해한다.
• Lighthouse/PSI 같은 실험실 도구는 통과/실패 관문이 아니라 진단에 사용하며, Performance Score 만점을 기다리지 않는다.
• 필드 데이터에 수정 결과가 나타날 때까지 최대 28일을 허용한다.
• 콘텐츠 관련성과 더 큰 SEO 기회보다 CWV를 앞세우지 않는다.

사고 모델

1. 세 차원, 세 지표. LCP = 로딩, INP = 반응성, CLS = 시각적 안정성입니다. 문제가 어느 차원에 속하는지 알면 어떤 지표와 심층 글을 봐야 하는지도 알 수 있습니다.

2. 필드는 순위 판단용, 실험실은 수정용. Google은 28일 동안의 p75 CrUX 필드 데이터를 순위 시스템에 사용합니다. Lighthouse/PSI 실험실 점수는 원인을 찾습니다. 둘은 상관관계조차 없는 경우가 많으므로 실험실 점수를 순위 수치로 취급하지 마세요.

3. 페이지 수준이 오리진 수준보다 우선. “통과”한 오리진도 실패 페이지를 숨길 수 있습니다. Google은 데이터가 있으면 페이지 수준 데이터를 사용합니다. 도구가 둘 다 보여 준다면 페이지 수준 보기를 우선하세요.

4. 사용되지만 가중치는 미공개. CWV는 확인된 순위 신호지만 Google은 공식 가중치를 공개하지 않았고 관련성이 우선할 수 있습니다. 사용자와 전환을 위해 CWV를 개선하되 순위 급등을 기대하지 마세요.

5. “정말 Core인가?” 테스트. 핵심 웹 바이탈은 LCP, INP, CLS뿐입니다. TTFB와 FCP는 진단 지표이고 TBT와 Speed Index는 실험실 대리 지표입니다. “Engagement Reliability”는 전혀 확인되지 않았습니다.

핵심 웹 바이탈 요약표

세 가지 핵심 웹 바이탈(필드 데이터, p75)

진단 지표 — 핵심 웹 바이탈이 아님

핵심 사실

• 평가 = CrUX 필드 데이터, p75 백분위수, 이동 28일 기간, 모바일과 데스크톱 별도.
• INP는 2024년 3월 12일 FID를 대체했습니다. FID는 완전히 폐기되었습니다.
• Lighthouse/PSI의 실험실 점수는 필드 측정이 아닌 진단용이며 필드 CWV와 자주 다릅니다.
• Google은 페이지 수준을 사용합니다. 오리진 평균은 오해를 부를 수 있습니다. 제 CWV 연구에서 통과율은 페이지 약 21,2%, 오리진 약 33%였습니다.
• 순위 가중치: Google 순위 시스템에서 사용하지만 공식 가중치는 미공개입니다. 관련성이 우선하고 좋은 점수가 보장은 아닙니다.
• **“Engagement Reliability”**는 확인된 핵심 웹 바이탈이 아닙니다.

어떤 핵심 웹 바이탈부터 조사해야 하나요?

출시 후 핵심 웹 바이탈이 악화된 경우

1. 신호를 확인합니다. 필드와 실험실, URL과 오리진, 모바일과 데스크톱을 구분하세요. 실험실 실행 한 번만 바뀌었다면 사고로 선언하기 전에 재현하세요.
2. 실패한 지표를 찾습니다. LCP, INP, CLS는 서로 다른 문제입니다. 여러 지표가 함께 움직였다면 공통 배포 변경과 서드파티 스크립트를 먼저 확인하세요.
3. 회귀를 배포와 연결합니다. 출시 전후 RUM 또는 반복 가능한 실험실 추적을 비교하세요. 시점이 맞지 않으면 트래픽·기기 구성을 조사하세요.
4. 점수가 아니라 지표를 진단합니다. LCP는 요소와 하위 구간, INP는 느린 상호작용과 메인 스레드 작업, CLS는 이동 원인을 조사하세요.
5. 원인이 명확한 최소 수정을 배포합니다. 실험실에서 즉시 검증하고 기능을 깨뜨리거나 다른 바이탈을 악화하면 롤백하세요.
6. 실제 사용자를 관찰합니다. 선행 신호는 RUM, 이동 필드 판정은 CrUX/Search Console을 사용하세요. 이해관계자가 당일 CrUX 초기화를 기대하지 않도록 범위와 기간을 기록하세요.

작업을 낭비하는 핵심 웹 바이탈 실수

Lighthouse 종합 점수 최적화

Google의 필드 평가는 단일 Lighthouse Performance 수치가 아니라 실제 사용자 데이터의 LCP, INP, CLS를 사용합니다. 실패한 필드 지표를 진단하고 Lighthouse는 통제된 디버깅 환경 하나로 사용하세요.

핵심 웹 바이탈을 순위 지름길로 취급

CWV는 Google이 공식 가중치를 공개한 적 없는 페이지 경험 신호이며 관련성이 여전히 우선합니다. 사용자를 위해 나쁜 경험을 고치되, 근거 없이 순위 상승을 약속하거나 더 중요한 콘텐츠·색인 작업을 밀어내지 마세요.

URL, 오리진, 모바일, 데스크톱 수치를 혼합

범위가 다르면 서로 다른 이야기를 할 수 있습니다. 모든 수치에 범위를 표시하고, 오리진 대체값이나 데스크톱 집계가 초록색이라는 이유로 페이지가 통과했다고 주장하지 마세요.

출시 확인 전에 CrUX를 기다림

이동 28일 기간은 배포 QA에 너무 느립니다. 실험실과 RUM에서 메커니즘을 즉시 검증한 뒤 CrUX로 장기적인 필드 결과를 확인하세요.

핵심 웹 바이탈 측정 도구

핵심 웹 바이탈 기록 및 경쟁사 비교로 확인하세요.

1. 사이트를 추가합니다. example.com처럼 오리진만 넣으면 CrUX 데이터가 가장 많으며 최대 5개까지 비교할 수 있습니다.
2. 모바일 또는 데스크톱을 선택하고 비교를 실행합니다.
3. 점수표에서 오늘의 LCP, INP, CLS 통과 여부를 확인하고 주간 추세 차트에서 각 지표가 좋음 구간에 가까워지는지 멀어지는지 봅니다.

필드 데이터 — 실제 사용자 핵심 웹 바이탈 측정

• PageSpeed Insights — 페이지·오리진 수준 CrUX 필드 데이터와 Lighthouse 실험실 보고서.
• Google Search Console 핵심 웹 바이탈 보고서 — 유사 페이지를 묶고 사이트 전체 필드 패턴을 표시해 실패 페이지 그룹을 가장 빠르게 찾습니다.
• CrUX API / BigQuery — 원본 데이터셋에서 맞춤형·국가별 분석.
• web-vitals JavaScript 라이브러리 — 자체 실제 사용자(RUM) 데이터를 수집해 분석 도구 등에 전송.

실험실 데이터 — 디버깅용(순위 판단용 아님)

• Lighthouse — 진단 기회와 순위에 쓰이지 않는 Performance Score.
• Chrome DevTools Performance 패널 — LCP, 레이아웃 이동, 긴 작업의 추적 수준 디버깅.
• PageSpeed Insights 실험실 섹션 — 필드 데이터 아래의 Lighthouse 기반 권장사항.

경험칙: GSC로 필드에서 어디가 실패하는지 찾기 → PSI로 페이지 수준 확인 → Lighthouse / DevTools로 진단하고 반복 개선하기.

시간을 들일 가치가 있는 자료

제 관련 글

• 핵심 웹 바이탈 개선 가이드(Ahrefs) — 세 지표와 수정 방법을 다룬 전체 실무 가이드.
• 핵심 웹 바이탈 데이터 연구(Ahrefs) — CrUX + 5,2M개 페이지에서 확인한 페이지·오리진 수준 통과율 차이.
• LCP 가이드(Ahrefs).
• CLS 가이드(Ahrefs).
• PageSpeed Insights 가이드(Ahrefs).
• 기술 SEO 초보자 가이드 — 큰 그림에서 페이지 경험의 위치.

공식 자료

• web.dev — Web Vitals와 공식 문서에 연결된 지표별 글.
• Google의 페이지 경험 문서와 순위 신호 설명 업데이트(Search Engine Land) — 2024년 3월 문서 변경에 대한 Barry Schwartz의 보도.

업계 자료

• Google 핵심 웹 바이탈 순위 요소: 동률 결정 이상(Search Engine Journal) — CWV가 동률 결정 요소 이상이지만 관련성을 대체하지 않는다는 John Mueller의 Reddit 발언 보도.
• 소규모·지역 비즈니스를 위한 Google 핵심 웹 바이탈 우선순위(Search Engine Roundtable) — 소규모·지역 비즈니스에서 CWV 작업이 최우선이어서는 안 된다는 Mueller의 Mastodon 발언.
• 확인: 핵심 웹 바이탈은 큰 순위 요소가 아님(Stan Ventures) — Mueller의 순위에서 거대한 요소가 아니라는 발언 맥락.
• 핵심 웹 바이탈이 SEO에 미치는 영향(RUMvision) — 2025년 11월 업데이트. 담당자 발언과 순위 신호의 미묘한 차이를 정리한 FAQ.
• Google 페이지 경험 업데이트: 동률 결정 요소(Search Engine Roundtable) — 업데이트 출시 전 Mueller/Illyes의 초기 동률 결정 설명.

인용할 만한 통계

• 제 CWV 데이터 연구(CrUX + Ahrefs Site Audit의 5,2M개 페이지)에서 세 가지 핵심 웹 바이탈을 모두 통과한 개별 페이지는 약 21,2%뿐이었고 오리진 수준은 약 33%였습니다. Google 시스템은 일반적으로 페이지를 개별 평가하므로 좋은 오리진 평균도 실패 페이지를 많이 숨길 수 있습니다. 출처
• 사이트가 가장 어려워하는 지표는 LCP입니다. 연구에서는 이전 FID와 CLS는 개선됐지만 LCP는 뒤처졌고 *“almost no sites on 3G or slower connections are passing.”*이었습니다. (번역) 3G 이하 연결에서 통과하는 사이트는 거의 없습니다. 출처
• “좋음” 기준: 필드 데이터의 p75 백분위수에서 LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1입니다. Google이 문서화한 목표입니다. 출처
• INP는 2024년 3월 12일 FID를 대체했습니다. 이날 FID는 핵심 웹 바이탈에서 제외되고 Search Console에서도 제거되었습니다. 출처

테스트: 핵심 웹 바이탈

핵심 웹 바이탈에 관한 다섯 문제입니다. 각각 답을 고른 뒤 확인하세요.

LCP/INP/CLS 수정이 실제로 반영됐는지 입증하기

성능 수정에서 흔한 함정은 출시 당일 실험실 점수를 보고 성공을 선언하는 것입니다. 실험실(Lighthouse)은 변경이 작동할 수 있는지 알려 주지만, 실제 사용자에게 효과가 있었는지는 필드 데이터(CrUX)만 알려 주며 이 데이터는 이동 28일 지연으로 움직입니다. 이 순서로 둘 다 실행하세요.

테스트 1 — 실험실 지표가 개선됨

• 실행할 테스트 — 변경 전후에 핵심 웹 바이탈 검사기, Lighthouse 또는 PageSpeed Insights로 페이지를 테스트합니다.
• 예상 결과 — 목표 실험실 지표가 올바른 방향으로 움직입니다. 예를 들어 LCP 요소가 더 빨리 렌더링되고, 새 레이아웃 이동이 없으며, 수정하려던 진단 항목이 해소됩니다.
• 실패 해석 — 실험실 수치가 움직이지 않았다면 변경이 중요 경로에 닿지 않은 것입니다. LCP가 아닌 요소나 차단하지 않던 스크립트를 최적화했을 수 있습니다.
• 모니터링 기간 — 즉시. 실험실 테스트는 요청할 때 실행됩니다.
• 롤백 조건 — 다른 지표가 악화된 경우입니다. LCP를 고쳤지만 CLS가 생겼거나 JavaScript 추가로 INP가 나빠졌다면 실제 사용자에게 닿기 전에 실험실에서 잡을 수 있습니다.

테스트 2 — 실제 사용자가 개선을 체감함(필드 데이터)

• 실행할 테스트 — 핵심 웹 바이탈 기록 및 경쟁사 비교나 GSC 핵심 웹 바이탈 보고서에서 페이지/오리진의 CrUX LCP, INP, CLS p75를 추적합니다.
• 예상 결과 — 수정한 지표의 p75가 **“좋음”**으로 들어가 유지됩니다. Google 기준은 LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1입니다.
• 실패 해석 — 실험실은 개선됐지만 필드가 그대로라면 빠른 연결의 테스트만 좋아졌거나 실제 기기·네트워크 조합에 효과가 없거나, 그룹 내 충분한 URL에 수정이 적용되지 않은 것입니다.
• 모니터링 기간 — 이동 28일. CrUX는 과거 28일 창이므로 신뢰할 만한 p75에는 약 4주의 필드 데이터가 필요합니다. 첫 주에 결론 내리지 마세요.
• 롤백 조건 — p75가 다시 “나쁨” 기준을 넘거나 템플릿 변경 후 GSC의 “좋음” URL 수가 줄면 실제 사용자 성능이 회귀했다는 강한 신호입니다.

이 주제의 상시 KPI

개별 수정 검증과 별개로, 페이지 경험이 건강한지 분기별로 확인할 지표입니다. Google이 기준값을 공개하므로 방어 가능한 벤치마크이며 수치를 지어내지 않습니다.

p75 LCP, INP, CLS(필드 데이터)

• 지표 — 페이지 그룹과 기기별 실제 방문에서 각 핵심 웹 바이탈의 p75 백분위수.
• 의미 — 실제 사용자 75%가 좋은 경험을 하는지 보여 줍니다. Google이 URL 통과를 분류하는 정확한 기준입니다. 평균이 아니라 p75가 느린 긴 꼬리를 반영하므로 중요합니다.
• 확인 방법 — 핵심 웹 바이탈 기록 및 경쟁사 비교의 CrUX, URL 패턴별 필드 데이터를 묶는 GSC 핵심 웹 바이탈 보고서, 단일 URL용 PageSpeed Insights.
• 벤치마크/현실적 범위 — Google 기준의 “좋음”은 LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1입니다. “개선 필요” / “나쁨” 구간은 각각 2,5–4s / >4s, 200–500ms / >500ms, 0,1–0,25 / >0,25입니다. 임의 목표가 아니라 공개 기준입니다.
• 주기 — 이동 28일이므로 매월 검토하세요. 매일 확인해도 같은 과거 창을 다시 읽을 뿐입니다. 실험실 점수는 선행 지표, CrUX p75는 후행 지표로 취급하세요.

사이트 전체의 “좋음 URL” 범위

• 지표 — GSC 핵심 웹 바이탈 보고서에서 색인된 URL 중 “좋음” 구간의 비율. 모바일과 데스크톱은 별도 추적합니다.
• 의미 — 수정이 얼마나 넓게 전파됐는지 보여 줍니다. 빠른 페이지 하나로 사이트가 움직이지 않지만 템플릿 수준 개선은 움직입니다.
• 확인 방법 — GSC → 핵심 웹 바이탈 보고서 → 시간에 따른 좋음 / 개선 필요 / 나쁨 URL 수.
• 벤치마크/현실적 범위 — 템플릿과 트래픽 구성에 따라 달라지는 상황별 지표입니다. 임의 비율을 좇지 말고 자체 기준선을 세워 좋음 비율을 계속 높이세요.
• 주기 — 매월, 또는 템플릿·테마 변경 직후 필드 창이 따라오는 동안 매주 확인합니다.

변경 내역