중급Google
Core Web Vitals 완전 정복: LCP·INP·CLS 측정과 개선
핵심 요약 (TL;DR)
Google의 핵심 사용자 경험 지표인 LCP(2.5초)·INP(200ms)·CLS(0.1) 기준과 측정 방법, 각 지표별 개선 전략을 실전 코드와 함께 설명합니다.
Core Web Vitals란 무엇인가
Core Web Vitals(CWV)는 Google이 2020년 발표한 사용자 경험(UX) 측정 지표 세트로, 실제 사용자 데이터를 기반으로 웹페이지의 품질을 정량화합니다. 2021년 6월부터 공식 구글 랭킹 팩터로 적용되었습니다.
2024년 3월 12일 중요 변경: FID(First Input Delay)가 INP(Interaction to Next Paint)로 공식 교체되었습니다. INP는 FID보다 훨씬 포괄적으로 페이지 반응성을 측정합니다.
< 2.5sLCP 목표Largest Contentful Paint
< 200msINP 목표Interaction to Next Paint
< 0.1CLS 목표Cumulative Layout Shift
75th측정 기준전체 페이지 로드의 75번째 백분위수
LCP — Largest Contentful Paint: 로딩 성능
LCP는 페이지가 로드되기 시작한 후, 뷰포트 내에서 가장 큰 콘텐츠 요소가 렌더링되는 시간을 측정합니다. 사용자가 "페이지가 뜬다"고 느끼는 시점과 가장 유사한 지표입니다.
LCP 측정 대상 요소
- 이미지 (
<img>, CSS background-image) - 비디오 (
<video>썸네일) - 블록 수준 텍스트 (
<p>,<h1>등 내 텍스트)
| LCP 값 | 평가 | 사용자 경험 |
|---|---|---|
| 0 ~ 2.5초 | 🟢 Good | 쾌적함 |
| 2.5 ~ 4.0초 | 🟡 Needs Improvement | 개선 필요 |
| 4.0초 이상 | 🔴 Poor | 이탈 위험 높음 |
LCP 개선 전략
- 히어로 이미지 최적화: WebP/AVIF 포맷, 올바른 srcset으로 화면 크기에 맞는 이미지 제공
- fetchpriority="high" 설정: LCP 요소에 지정해 브라우저의 우선 로딩 지시
- preload 힌트 추가:
<link rel="preload">로 LCP 이미지를 HTML 파싱 단계에서 미리 요청 - 서버 응답 시간(TTFB) 개선: CDN 활용, 서버 사이드 캐싱
- 렌더 블로킹 리소스 제거: CSS·JS를 async/defer로 비동기 로드
<!-- LCP 이미지 최적화 예시 -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="히어로 이미지" fetchpriority="high" loading="eager"
width="1200" height="600">
INP — Interaction to Next Paint: 반응성 (2024년 FID 대체)
INP는 2024년 3월 FID(First Input Delay)를 교체한 새 반응성 지표입니다. FID가 첫 번째 인터랙션의 입력 지연만 측정했다면, INP는 페이지 방문 전체에 걸쳐 모든 인터랙션의 응답 시간을 측정하는 더 포괄적인 지표입니다.
INP vs FID 비교
| 항목 | FID (구) | INP (신) |
|---|---|---|
| 측정 범위 | 첫 번째 인터랙션만 | 페이지 전체 방문 중 모든 인터랙션 |
| 측정 대상 | 입력 지연(Input Delay)만 | 입력 지연 + 처리 시간 + 표시 지연 전체 |
| Good 기준 | 100ms 미만 | 200ms 미만 |
| 교체 일시 | - | 2024년 3월 12일 공식 적용 |
INP 개선 전략
- Long Task 분리: 50ms 이상 실행되는 JavaScript 작업을 작게 나눠라 (
scheduler.yield()활용) - 이벤트 핸들러 최적화: 클릭 핸들러 내 무거운 DOM 조작 최소화
- Third-party Script 지연 로드: 광고·분석 스크립트가 메인 스레드를 차지하지 않도록
- Web Worker 활용: CPU 집약적 작업을 백그라운드 스레드로 이동
CLS — Cumulative Layout Shift: 시각 안정성
CLS는 페이지가 로드되는 동안 예기치 않게 발생하는 레이아웃 이동(Layout Shift)의 누적 점수입니다. 글을 읽다가 갑자기 버튼이 이동해 다른 것을 클릭하는 경험이 바로 높은 CLS의 결과입니다.
| CLS 값 | 평가 |
|---|---|
| 0 ~ 0.1 | 🟢 Good |
| 0.1 ~ 0.25 | 🟡 Needs Improvement |
| 0.25 이상 | 🔴 Poor |
CLS 주요 원인과 해결법
| 원인 | 해결 방법 |
|---|---|
| 이미지/비디오에 크기 미지정 | width·height 속성 반드시 명시 또는 CSS aspect-ratio 설정 |
| 광고 공간이 예약되지 않음 | 광고 컨테이너의 min-height 미리 지정 |
| 웹폰트 로딩 중 텍스트 이동 | font-display: optional 또는 swap 사용, 폰트 preload |
| 동적 콘텐츠 삽입 (배너, 공지 등) | 상단 삽입 대신 예약된 공간 활용 |
| 애니메이션이 레이아웃 속성 변경 | top/left 대신 transform·opacity만 변경 |
CWV 측정 도구 모음
| 도구 | 데이터 유형 | 특징 |
|---|---|---|
| Google Search Console → CWV 보고서 | 실사용자 데이터 (CrUX) | URL별 현황 파악, 개선 필요 URL 목록 제공 |
| PageSpeed Insights (PSI) | 실사용자 + 랩 데이터 | 가장 빠른 진단, URL 하나씩 분석 |
| Chrome DevTools → Performance | 랩 데이터 | 세밀한 타임라인 분석, Long Task 시각화 |
| Lighthouse | 랩 데이터 | CI/CD 파이프라인 통합 가능 |
| web-vitals.js 라이브러리 | 실사용자 데이터 | 직접 수집·GA4로 전송 가능 |
자주 묻는 질문 (FAQ)
Q. Core Web Vitals가 실제로 순위에 큰 영향을 미치나요?
CWV는 타이브레이커(동점 결정) 수준의 랭킹 팩터입니다. 콘텐츠 관련성, E-E-A-T, 백링크 등 핵심 신호가 동등한 경우, CWV가 좋은 페이지가 우선순위를 받습니다. 하지만 CWV가 나쁘다고 좋은 콘텐츠가 갑자기 순위에서 밀리지는 않습니다. Google의 John Mueller도 "콘텐츠 품질이 속도보다 중요하다"고 밝혔습니다. 그럼에도 사용자 경험 측면에서 CWV 개선은 이탈률 감소와 체류 시간 증가로 이어져 간접적으로 SEO에 영향을 줍니다.
Q. INP가 FID를 대체한 이유는 무엇인가요?
FID는 첫 번째 인터랙션의 입력 지연만 측정했기 때문에, 페이지 로드 후 발생하는 느린 반응을 포착하지 못했습니다. 예를 들어, 페이지 로드 직후에는 빠르지만 스크롤 후 버튼 클릭 시 3초간 멈추는 페이지도 FID에서는 "Good"으로 평가됐습니다. INP는 전체 방문 중 모든 인터랙션을 측정하고, 가장 느린 인터랙션(정확히는 98번째 백분위수)을 보고하므로 실제 사용자 경험을 더 잘 반영합니다.
Q. 필드 데이터와 랩 데이터 중 어떤 것을 봐야 하나요?
두 가지 모두 봐야 합니다. 필드 데이터(CrUX, GSC CWV 보고서)는 실제 사용자 환경을 반영하므로 순위에 직접 영향을 미칩니다. 랩 데이터(Lighthouse, DevTools)는 통제된 환경에서 재현 가능한 디버깅에 유리합니다. 먼저 필드 데이터에서 문제 URL을 발견하고, 랩 데이터에서 원인을 진단하여 개선하는 것이 권장 워크플로입니다.
Q. CWV 점수가 모바일과 데스크톱에서 다른 이유는?
Google은 모바일과 데스크톱의 CWV를 별도로 측정합니다. 모바일 기기는 CPU 성능이 낮고 네트워크가 불안정하므로 LCP와 INP가 더 느린 경향이 있습니다. Google의 Mobile-First Indexing 정책에 따라 모바일 CWV가 순위에 더 직접적인 영향을 미칩니다. 따라서 모바일 최적화를 우선시하되, 데스크톱도 함께 관리하세요.
Q. Third-party 스크립트(광고, 분석)가 CWV를 악화시키는데 어떻게 해야 하나요?
Third-party 스크립트는 CWV(특히 INP와 LCP)의 가장 흔한 악화 원인입니다. 해결 방법: (1)
defer 또는 async 속성으로 로딩 지연, (2) Partytown 라이브러리로 Web Worker에서 실행, (3) 페이지 상호작용 후(예: 스크롤 시) 동적 로드, (4) 불필요한 스크립트 과감히 제거. Google Tag Manager를 사용한다면 트리거를 "Window Loaded" 이후로 설정하세요.