홍은표 · 넥스트티 대표 · SEO/GEO 컨설턴트 | 작성 2026-05-26
DEFINITION · 한 문장 정의
Core Web Vitals(CWV)는 구글이 정한 페이지 경험 지표 세트로, 로딩(LCP)·반응성(INP)·시각적 안정성(CLS) 3가지로 사용자가 페이지를 어떻게 체감하는지를 정량화합니다. 검색 랭킹 신호의 일부이자, 사용자 이탈을 추적할 수 있는 운영 KPI입니다.
1분 요약 · KEY TAKEAWAYS
3 METRICS
가장 큰 콘텐츠 요소가 그려지는 데 걸리는 시간
페이지 첫 화면에서 가장 큰 이미지·텍스트 블록이 보이기까지 걸리는 시간. 로딩 체감의 대표 지표입니다.
상호작용 후 다음 화면이 그려지기까지의 시간
페이지 전체 수명 동안 모든 상호작용의 응답 시간을 측정 — 상호작용 50회 미만은 최대값, 50회 이상은 상위 98 percentile을 대표값으로 사용합니다. 반응성 체감 지표.
페이지 로드·사용 중 누적된 레이아웃 이동량
요소가 예상치 못하게 움직이는 정도. 광고·이미지가 늦게 끼어들며 본문이 밀려나는 경험의 시각 안정성 지표.
세 지표 모두 모바일과 데스크톱 임계값이 동일합니다. 단, 동일 사이트라도 두 환경의 점수는 보통 모바일이 더 나쁩니다 — 같은 코드가 더 약한 CPU·더 느린 네트워크에서 돌기 때문입니다. 검색 랭킹 신호 평가는 환경별로 독립적이므로, 모바일 점수를 기준선으로 두는 것이 안전합니다.
2024-03 · 반응성 지표 교체
페이지 로드 후 첫 번째 입력에 대한 지연만 측정. 첫 인상 이후의 반응성은 보지 않았기에, "처음만 빠르고 사용 중엔 느린" 페이지가 좋은 점수를 받았습니다.
페이지 전체 수명 동안 모든 상호작용의 응답 시간을 측정. 상호작용이 50회 미만이면 최대값, 50회 이상이면 상위 98 percentile 값을 대표값으로 사용 — 사용 중 누적 반응성을 본다는 점에서 사용자 경험에 더 정직합니다.
FID 기준으로는 통과했던 사이트가 INP에서는 자주 떨어집니다. 특히 장시간 사용·복잡한 인터랙션이 있는 페이지(검색 필터, 무한 스크롤, 폼 상호작용)에서 차이가 두드러집니다. INP는 사용 중 한 번이라도 크게 느려진 순간이 있으면 그 영향이 대표값에 반영되기 때문입니다.
실무 함의 — 첫 로드 최적화만으로는 부족합니다. 메인 스레드 점유(긴 JS 태스크, 무거운 리스너), 외부 스크립트의 지연 실행, 인터랙션 이후의 렌더 비용까지 보아야 INP가 안정됩니다.
OPTIMIZATION PATTERNS
fetchpriority="high" · preload로 LCP 후보 우선 로드font-display: swaploading="lazy"scheduler.yield()·requestIdleCallback으로 양보defer·idle 시점)width·height 속성으로 종횡비 예약size-adjust·font-display로 폰트 교체 시 점프 줄이기넥스트티는 자체 사이트에서 이미지 약 1,900개를 webp/avif로 일괄 변환하는 작업을 별도로 진행했습니다(제작 방법론). 이미지 용량 축소는 LCP의 출발선을 끌어내리는 가장 단순한 레버이지만, INP는 같은 작업으로 개선되지 않으므로 지표별로 다른 작업이 필요합니다.
우리 사이트의 LCP·INP·CLS가 어디에 있는지 — 측정부터
SEO Checker로 무료 진단 →MEASURE · Lab vs Field
같은 페이지의 CWV 점수도 측정 방식에 따라 다릅니다. 가장 중요한 구분은 Lab data(시뮬레이션)와 Field data(실제 사용자)입니다. 둘은 용도가 다르므로 어느 쪽 데이터를 보는지 명확히 해야 합니다.
| 도구 | 데이터 종류 | 언제 보나 |
|---|---|---|
| PageSpeed Insights | Lab + Field | 한 URL의 종합 진단. Field 섹션이 실제 사용자 데이터(CrUX) |
| CrUX | Field | 실제 Chrome 사용자 28일 데이터 분포. 검색 랭킹 신호의 근거 |
| Search Console (Page Experience) | Field | 사이트 전체 URL을 좋음/개선/나쁨 그룹별로 집계해 추이 모니터링 |
| Lighthouse (DevTools) | Lab | 로컬에서 시뮬레이션. 코드 변경의 즉시 효과를 디버깅 |
| Web Vitals JS / RUM | Field (자사) | 자체 사용자 실시간 데이터 수집. 외부 도구 없이 측정 가능 |
결정 규칙 — 검색 랭킹·실제 사용자 경험은 Field data로 봅니다. 코드 변경 효과를 빨리 검증할 때는 Lab data. 둘이 어긋날 때는 Field를 우선합니다.
SOURCES — web.dev — Core Web Vitals 개요 · web.dev — INP 정의·측정 · Chrome for Developers — CrUX · Search Central — Page Experience
OFTEN MISUNDERSTOOD · 실제 진단에서 자주 보는 오해
CWV 점수가 좋다고 SEO가 좋은 건 아니고, 점수를 올리려다 SEO를 망치기도 합니다.
진단 현장에서 자주 보는 두 가지 오해를 정리합니다.
MISCONCEPTION 01
CWV는 SEO의 기본 체력에 가깝습니다. 체력이 좋다고 시합에서 이기는 건 아닙니다. 비슷한 품질의 두 페이지가 경쟁할 때 페이지 경험이 가르는 정도지, 콘텐츠 자체의 깊이·검색 의도 적합성·내부 링크 권위·엔티티 신호가 부족하면 95점도 결과를 만들지 못합니다.
상담에서 가장 자주 듣는 질문 중 하나이고, 답이 한 줄로 끝나지 않는 질문입니다. CWV는 통로를 넓혀줄 뿐 — 검색 의도 적합성·내부 링크 권위·엔티티 신호가 그 위에 쌓여야 결과가 납니다.
MISCONCEPTION 02
빠르게 만들려는 작업이 오히려 봇 가시성을 떨어뜨리는 경우가 흔합니다. 진단 현장에서 자주 보는 3가지:
세 패턴 모두 "빠르게"가 아니라 "빠르되 봇이 핵심을 잡을 수 있게"라는 원칙을 놓쳐서 생깁니다.
원칙 — CWV는 그 자체로 신호가 아니라 콘텐츠가 잘 도달되게 하는 통로입니다. 점수가 목표가 되면 통로를 넓히려다 콘텐츠를 끊는 일이 생깁니다.
FAQ
DIAGNOSE · CORE WEB VITALS
LCP·INP·CLS Field data 진단 · 메인 스레드 점유 추적 · 외부 스크립트 정리 · 한국 모바일 환경 기준 측정.
넥스트티가 지표별 병목과 작업 우선순위를 정리해드립니다.