Core Web Vitals: LCP, INP, CLS 설명 및 해결 방법
· 12분 읽기
목차
Core Web Vitals는 웹에서 사용자 경험을 측정하기 위한 Google의 공식 지표입니다. 2021년 6월 순위 요소가 된 이후, 개발자, SEO 전문가, 사이트 소유자가 페이지 성능에 접근하는 방식을 근본적으로 변화시켰습니다. 이 종합 가이드는 각 지표를 분석하고, 낮은 점수의 원인을 설명하며, 즉시 구현할 수 있는 구체적이고 실행 가능한 해결책을 제공합니다.
전자상거래 사이트, 콘텐츠 플랫폼 또는 SaaS 애플리케이션을 최적화하든, Core Web Vitals를 이해하고 개선하는 것은 더 이상 선택 사항이 아닙니다. 검색 가시성과 사용자 만족도 모두에 필수적입니다.
Core Web Vitals란 무엇인가?
Core Web Vitals(CWV)는 Google이 좋은 사용자 경험을 제공하는 데 필수적이라고 간주하는 세 가지 특정 지표 세트입니다. 사용자가 웹사이트를 인식하고 상호작용하는 방식에 직접적인 영향을 미치는 페이지 성능의 세 가지 중요한 차원을 측정합니다.
세 가지 Core Web Vitals는 다음과 같습니다:
- 최대 콘텐츠풀 페인트 (LCP) — 가장 큰 가시적 콘텐츠 요소가 렌더링되는 시점을 추적하여 로딩 성능을 측정합니다
- 다음 페인트까지의 상호작용 (INP) — 페이지가 모든 사용자 상호작용에 얼마나 빠르게 응답하는지 평가하여 상호작용성을 측정합니다
- 누적 레이아웃 이동 (CLS) — 페이지 로드 중 예상치 못한 레이아웃 이동을 정량화하여 시각적 안정성을 측정합니다
통제된 환경에서 실행되는 합성 실험실 테스트와 달리, Google은 Chrome 사용자 경험 보고서(CrUX)를 통해 실제 Chrome 사용자의 실제 데이터를 사용하여 Core Web Vitals를 평가합니다. 즉, 사이트가 개발 환경뿐만 아니라 다양한 네트워크 조건의 실제 기기에서 실제 사용자에게 잘 작동해야 합니다.
전문가 팁: Google은 각 지표에 대해 페이지 방문의 75%가 "좋음" 임계값을 충족해야 합니다. 단일 완벽한 테스트 점수로는 충분하지 않습니다. 전체 사용자 기반에서 일관된 성능이 필요합니다.
Core Web Vitals의 진화
Core Web Vitals는 정적이지 않습니다. Google은 원래 상호작용성 지표로 최초 입력 지연(FID)을 포함했지만, 2024년 3월에 다음 페인트까지의 상호작용(INP)으로 교체했습니다. 이 변경은 측정하기 쉬운 것이 아니라 사용자에게 실제로 중요한 것을 측정하려는 Google의 약속을 반영합니다.
FID에서 INP로의 전환은 중요했습니다. FID는 첫 번째 상호작용만 측정했지만, INP는 페이지 수명 주기 전체에 걸쳐 모든 상호작용을 평가하기 때문입니다. 이는 응답성에 대한 보다 포괄적인 관점을 제공하고 사용자 불만과 더 잘 상관관계가 있습니다.
Core Web Vitals가 SEO와 비즈니스에 중요한 이유
Core Web Vitals는 모바일 친화성, HTTPS 보안, 방해가 되는 삽입 광고의 부재도 포함하는 Google의 페이지 경험 신호의 일부입니다. 콘텐츠 관련성과 권위가 여전히 순위를 지배하지만, CWV는 동점 결정자 역할을 합니다. 두 페이지가 동등하게 관련성이 있을 때 성능이 더 나은 페이지가 승리합니다.
그러나 영향은 검색 순위를 훨씬 넘어 확장됩니다. 성능은 수익에 직접적인 영향을 미칩니다:
| 지표 개선 | 비즈니스 영향 | 출처 |
|---|---|---|
| 모든 CWV 임계값 통과 | 페이지 이탈 24% 감소 | Google/SOASTA 연구 |
| LCP 100ms 개선 | 전환율 1.7% 증가 | Deloitte Digital |
| CLS 0.1 개선 | 이탈률 3.2% 감소 | Akamai 연구 |
| INP 200ms 개선 | 참여도 5.8% 증가 | Chrome 사용자 경험 보고서 |
실제 사례 연구가 이러한 영향을 보여줍니다. Vodafone이 LCP를 31% 개선했을 때 매출이 8% 증가했습니다. Yahoo Japan이 CLS를 0.2 줄였을 때 세션 지속 시간이 15% 증가했습니다. 이것은 미미한 이득이 아니라 비즈니스를 변화시키는 개선입니다.
모바일 우선 현실
Google의 모바일 우선 색인으로 인해 모바일 Core Web Vitals 점수가 가장 중요합니다. 모바일 기기는 일반적으로 데스크톱 컴퓨터보다 프로세서가 느리고 메모리가 적으며 네트워크 조건이 더 가변적이어서 최적화가 더 어렵지만 더 중요합니다.
모바일 사용자는 또한 덜 관대합니다. Google의 연구에 따르면 모바일 사용자의 53%가 로드하는 데 3초 이상 걸리는 사이트를 포기합니다. 낮은 Core Web Vitals는 이러한 이탈률에 직접적으로 기여합니다.
최대 콘텐츠풀 페인트 (LCP)
최대 콘텐츠풀 페인트는 뷰포트에서 가장 큰 가시적 콘텐츠 요소가 렌더링되는 데 걸리는 시간을 측정합니다. 일반적으로 히어로 이미지, 비디오 썸네일, 큰 텍스트 블록 또는 배경 이미지입니다. LCP는 "이 페이지가 언제 로드되었는가?"에 대한 사용자의 인식과 직접적으로 상관관계가 있기 때문에 가장 직관적인 Core Web Vital입니다.
LCP 임계값
| 등급 | LCP 시간 | 사용자 경험 |
|---|---|---|
| 좋음 | ≤ 2.5초 | 빠르고, 반응적이며, 전문적 |
| 개선 필요 | 2.5 - 4.0초 | 허용 가능하지만 눈에 띄는 지연 |
| 나쁨 | > 4.0초 | 답답하고, 포기할 가능성이 높음 |
어떤 요소가 LCP로 계산되나?
페이지의 모든 요소가 LCP 요소가 될 수 있는 것은 아닙니다. 다음 요소 유형만 고려됩니다:
<img>요소<svg>내부의<image>요소- 포스터 이미지가 있는
<video>요소 - CSS
url()을 통해 로드된 배경 이미지가 있는 요소 - 텍스트 노드를 포함하는 블록 레벨 요소
LCP 요소는 페이지가 로드되면서 변경될 수 있습니다. 처음에는 텍스트 제목일 수 있지만, 히어로 이미지가 로드되면 그것이 새로운 LCP 요소가 됩니다. 최종 LCP는 사용자가 페이지와 상호작용을 시작하거나 이동할 때 기록됩니다.
일반적인 LCP 문제 및 해결책
문제 1: 느린 서버 응답 시간
첫 바이트까지의 시간(TTFB)이 느리면 다른 모든 것이 영향을 받습니다. 브라우저는 HTML 문서를 받을 때까지 렌더링을 시작할 수 없습니다.
해결책:
- 콘텐츠 전송 네트워크(CDN)를 사용하여 사용자에게 더 가까운 위치에서 콘텐츠 제공
- Redis 또는 Memcached로 서버 측 캐싱 구현
- 데이터베이스 쿼리 최적화 및 적절한 인덱스 추가
- 멀티플렉싱 및 헤더 압축을 위해 HTTP/2 또는 HTTP/3 사용
- Cloudflare Workers 또는 Vercel Edge Functions와 같은 엣지 컴퓨팅 솔루션 고려
문제 2: 렌더링 차단 리소스
<head>의 CSS 및 JavaScript 파일은 다운로드되고 처리될 때까지 렌더링을 차단합니다.
해결책:
- 스크롤 없이 볼 수 있는 콘텐츠에 대한 중요한 CSS를 HTML에 직접 인라인
media="print" onload="this.media='all'"을 사용하여 중요하지 않은 CSS 지연- 스크립트 태그에
async또는defer속성 추가 - PurgeCSS와 같은 도구로 사용하지 않는 CSS 및 JavaScript 제거
- 코드 분할로 큰 번들을 더 작은 청크로 분할
빠른 팁: 페이지 속도 분석기를 사용하여 렌더링 차단 리소스를 식별하고 사이트에 대한 구체적인 권장 사항을 받으세요.
문제 3: 큰 이미지 파일
최적화되지 않은 이미지는 가장 일반적인 LCP 원인입니다. 5MB 히어로 이미지는 LCP 점수를 망칠 것입니다.
해결책:
- WebP 또는 AVIF와 같은 최신 형식을 사용하여 이미지 압축 (JPEG보다 70-90% 작음)
srcset및sizes속성으로 반응형 이미지 구현- 이미지를 자동으로 최적화하고 크기를 조정하는 이미지 CDN 사용
- LCP 이미지에
fetchpriority="high"를 추가하여 다운로드 우선순위 지정 <link rel="preload" as="image">로 LCP 이미지 미리 로드
문제 4: 클라이언트 측 렌더링
LCP 요소가 JavaScript로 렌더링되면 사용자는 콘텐츠를 보기 전에 JS가 다운로드, 파싱 및 실행될 때까지 기다려야 합니다.
해결책:
- 서버 측 렌더링(SSR) 또는 정적 사이트 생성(SSG) 사용
- React Server Components 또는 유사한 기술로 스트리밍 SSR 구현
- 점진적 향상 사용—서버 측에서 기본 버전 렌더링, JavaScript로 향상
- JavaScript 실행 시간을 줄이기 위해 부분 하이드레이션 고려
고급 LCP 최적화
이미 2.5초 임계값을 충족하는 사이트의 경우, 이러한 고급 기법으로 최고 성능 계층으로 진입할 수 있습니다:
리소스 힌트: 중요한 타사 출처에 대해 <link rel="preconnect">를 사용하여 연결을 조기에 설정합니다. 덜 중요한 출처에는 <link rel="dns-prefetch">를 사용합니다.
우선순위 힌트: fetchpriority 속성은 브라우저에 어떤 리소스가 가장 중요한지 알려줍니다. LCP 이미지에 fetchpriority="high"를 설정하고 스크롤 아래 이미지에 fetchpriority="low"를 설정합니다.
103 Early Hints: 이 HTTP 상태 코드를 사용하면 서버가 주 응답이 준비되기 전에 미리 로드 힌트를 보낼 수 있어 브라우저가 중요한 리소스 다운로드를 먼저 시작할 수 있습니다.
다음 페인트까지의 상호작용 (INP)
다음 페인트까지의 상호작용은 전체 페이지 수명 주기 동안 사용자 상호작용에 대한 페이지의 응답성을 측정합니다. 첫 번째 상호작용만 측정한 이전 버전 FID와 달리, INP는 모든 클릭, 탭 및 키보드 누름을 평가하여 상호작용성에 대한 포괄적인 관점을 제공합니다.
INP는 사용자가 상호작용을 시작한 시점부터 브라우저가 해당 상호작용의 시각적 결과를 보여주는 다음 프레임을 그릴 때까지의 시간을 측정합니다. 여기에는 입력 지연, 처리 시간 및 표시 지연이 포함됩니다.
INP 임계값
| 등급 | INP 시간 | 사용자 경험 |
|---|---|---|
| 좋음 | ≤ 200밀리초 | 즉각적이고 반응적인 피드백 |
| 개선 필요 | 200 - 500밀리초 | 눈에 띄지만 견딜 수 있는 지연 |
| 나쁨 | > 500밀리초 | 느리고, 반응하지 않으며, 고장난 것처럼 느껴짐 |
INP 구성 요소 이해
INP는 세 가지 단계로 구성됩니다:
- 입력 지연: 사용자 작업부터 이벤트 핸들러가 실행을 시작할 때까지의 시간 (메인 스레드가 사용 가능해야 함)
- 처리 시간: 이벤트 핸들러 및 관련 JavaScript를 실행하는 데 소요되는 시간
- 표시 지연: 핸들러 완료부터 브라우저가 다음 프레임을 그릴 때까지의 시간
페이지 방문 중 가장 느린 상호작용이