코어 웹 바이탈(Core Web Vitals)은 구글이 페이지의 실사용자 경험을 측정하는 3대 핵심 지표입니다. 로딩 속도를 재는 LCP, 반응성을 재는 INP, 화면 안정성을 재는 CLS로 구성되고, 셋 다 실제 방문자 데이터의 75번째 백분위수로 평가해요.
기준값은 명확합니다. LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하면 "좋음"이에요. 그리고 2024년 3월 12일부터 INP가 기존 지표 FID를 공식 대체했기 때문에, FID 기준으로 쓰인 자료는 이제 구버전입니다.
국내 문서 상당수가 아직 FID 기준으로 남아 있어서, 서치폴라리스가 용어사전 시리즈로 현행 기준을 정리했습니다.
빠르게 훑으면 이렇습니다.
- LCP·INP·CLS 세 지표가 각각 로딩·반응성·시각 안정성을 담당합니다
- 평가는 평균이 아니라 실사용자 75번째 백분위수 기준이에요
- 측정 도구는 필드 데이터와 랩 데이터로 나뉘고, 점수가 서로 다른 게 정상입니다
- 다른 검색 용어는 GEO 용어사전에 모아뒀어요
세 지표가 각각 재는 것
세 지표는 방문자가 페이지에서 겪는 경험을 단계별로 쪼갠 겁니다. 건강검진 수치와 비슷해요. 혈압·혈당·콜레스테롤이 각각 다른 문제를 잡아내듯, 세 지표는 서로 다른 불편을 잡아냅니다.
| 지표 | 측정 대상 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | 가장 큰 콘텐츠가 뜨는 시간 | 2.5초 이하 | 2.5~4.0초 | 4.0초 초과 |
| INP (Interaction to Next Paint) | 클릭·입력 후 화면 반응 지연 | 200ms 이하 | 200~500ms | 500ms 초과 |
| CLS (Cumulative Layout Shift) | 로딩 중 레이아웃 밀림 정도 | 0.1 이하 | 0.1~0.25 | 0.25 초과 |
기준값의 출처는 구글의 web.dev 공식 문서입니다. 여기서 자주 놓치는 게 75번째 백분위수 규칙이에요. 평균이 아니라 방문 100건 중 느린 쪽 25번째 방문이 기준선입니다. 평균이 좋아도 저사양 폰 사용자 4분의 1이 느리게 겪으면 평가에서 떨어져요. 모바일과 데스크톱도 따로 평가합니다.
FID는 은퇴했습니다.
2024년 3월 12일, 첫 입력 지연만 재던 FID(First Input Delay) 대신 상호작용 전체의 반응 지연을 재는 INP가 세 번째 지표로 들어왔어요. 처음엔 이름만 바뀐 줄 알았는데, 실제 사이트를 점검해 보면 FID로 통과하던 페이지가 INP에서 무더기로 떨어집니다. 첫 클릭만 빠르면 됐던 시험이 모든 클릭을 보는 시험으로 바뀐 셈이라서요.
측정법: 두 종류 점수가 다르게 나오는 이유
측정 도구는 두 계열입니다. 계열이 다르면 점수도 달라요.
필드 데이터는 실제 방문자의 크롬 브라우저에서 수집된 기록입니다. CrUX(Chrome UX Report)가 원천이고, 서치 콘솔의 코어 웹 바이탈 보고서가 이 데이터를 URL 그룹별로 보여줍니다. 구글이 평가에 쓰는 건 이쪽이에요.
랩 데이터는 시뮬레이션입니다. Lighthouse와 PageSpeed Insights의 진단 점수, 크롬 개발자도구 성능 패널이 여기 속해요. 고정된 가상 환경에서 재기 때문에 재현과 디버깅에 유리하지만, 실사용자 조건과는 다릅니다.
그래서 PageSpeed Insights 점수는 나쁜데 서치 콘솔은 통과, 혹은 그 반대가 흔하게 일어나요. 오류가 아닙니다. 랩은 가상 기기 하나의 조건이고, 필드는 우리 사이트 방문자 전체의 실측이라 방문자 기기 분포에 따라 갈리는 거예요. 판정 기준은 언제나 필드 데이터입니다. 랩 데이터는 원인을 찾는 현미경으로 쓰세요.
서치폴라리스 팀은 고객사 진단 때 서치 콘솔 보고서로 문제 URL 그룹을 먼저 좁히고, 그다음에 PageSpeed Insights로 개별 원인을 파는 순서를 씁니다. 반대로 하면 가상 점수 쫓다가 실사용자 문제를 놓쳐요.
순위에 얼마나 영향을 주나: 솔직한 답
구글의 공식 입장은 절제돼 있습니다. Search Central 문서 기준으로 코어 웹 바이탈은 페이지 경험 요소의 하나로 랭킹 시스템에 반영되지만, 단독 결정 요인이 아니에요. 콘텐츠 관련성이 훨씬 큰 변수입니다.
~~속도만 올려서 순위가 뛰는 마법은 없습니다.~~
그래서 우리는 코어 웹 바이탈을 순위 부스터가 아니라 탈락 방지선으로 봅니다. 경쟁 콘텐츠 품질이 비슷할 때 갈림길이 되고, "나쁨" 구간은 이탈률로 먼저 손해를 봐요. AI 검색 시대에도 성능은 기본기입니다. 페이지가 늦게 뜨거나 렌더링이 불안정하면 크롤러의 수집 효율부터 나빠져서, 인덱서빌리티 점검과 묶어서 보는 쪽을 권해요.
경계선도 분명합니다. 이미 세 지표가 전부 "좋음"인 사이트가 LCP를 0.3초 더 줄이는 데 개발 리소스를 쓰는 건 추천하지 않아요. 그 시간이면 콘텐츠 갭을 메우는 편이 낫습니다. 반대로 "나쁨"이 하나라도 있으면 콘텐츠보다 성능이 먼저예요.
아직 확실하지 않은 것도 있습니다. AI 답변 엔진들이 인용 판단에 페이지 성능을 얼마나 반영하는지는 공개된 근거가 부족해요. 다만 느린 페이지가 수집·렌더링 단계에서 불리한 건 검색이든 AI든 같습니다.
지표는 결국 방문자의 짜증을 숫자로 번역한 것뿐입니다. 숫자를 좋아하는 건 구글이지만, 그 숫자를 만드는 건 기다리다 지친 사람들이에요.
자주 묻는 질문
Q: 코어 웹 바이탈이란 무엇인가요?
구글이 페이지의 실사용자 경험을 측정하는 3대 지표입니다. 로딩 속도의 LCP(2.5초 이하), 반응성의 INP(200ms 이하), 시각 안정성의 CLS(0.1 이하)로 구성되고, 실제 방문자 데이터의 75번째 백분위수로 평가합니다.
Q: INP는 왜 FID를 대체했나요?
FID는 첫 입력의 지연만 측정해서 페이지 사용 중 반응성을 못 잡았어요. 2024년 3월 12일부터 모든 상호작용의 반응 지연을 재는 INP가 세 번째 지표로 공식 교체됐습니다. FID 기준으로 통과하던 페이지도 INP에서는 떨어질 수 있어 재점검이 필요해요.
Q: PageSpeed Insights와 서치 콘솔 점수가 왜 다른가요?
측정 계열이 달라서입니다. PageSpeed Insights의 진단 점수는 가상 환경의 랩 데이터이고, 서치 콘솔 보고서는 실제 방문자 기록인 CrUX 필드 데이터예요. 구글 평가에 쓰이는 건 필드 데이터라 판정은 서치 콘솔 기준으로 보고, 랩 데이터는 원인 분석용으로 씁니다.
