Core Web Vitals 통과 방법: 단계별 가이드 (2026)

Core Web Vitals를 통과하는 가장 빠른 방법

Core Web Vitals 개선이 필요하다는 것을 알고 계실 것입니다. Google Search Console에 빨간색이나 주황색 경고가 표시되거나, 클라이언트가 문의를 하거나, PageSpeed Insights에서 나쁜 결과를 받았을 수 있습니다. 이 페이지는 제가 사이트를 실패 상태에서 통과 상태로 가장 빠르게 전환하기 위해 사용하는 워크플로우입니다.

저는 이 워크플로우를 사용하여 수십만 개의 페이지에서 사이트가 Core Web Vitals를 통과하도록 도왔습니다. WordPress, Shopify, 맞춤형 빌드 및 그 사이의 모든 플랫폼에서 효과가 있습니다. 수정하는 순서가 중요합니다. 기초를 먼저 수정한 다음 바깥쪽으로 작업하세요. 그렇지 않으면 근본적인 문제가 덮어버릴 것들을 최적화하느라 시간을 낭비하게 됩니다.

웹의 현재 위치

2025 Web Almanac(2025년 7월 CrUX 데이터 기준)에 따르면 모바일 웹사이트의 48%와 데스크톱 웹사이트의 56%가 3가지 Core Web Vitals를 모두 통과합니다. 이는 2024년 모바일 44%에서 개선된 수치이지만, 여전히 모바일 웹의 절반 이상이 실패하고 있음을 의미합니다.

지표별로 나누어 보면(모바일에서 "우수(good)" 평가를 받은 출처(origins)의 비율):

출처: 2025 Web Almanac (HTTP Archive, 2025년 7월 CrUX 데이터). 모니터링된 사이트 전반의 CoreDash RUM 데이터도 비슷한 분포를 보여줍니다.

LCP가 병목 현상입니다. 77%가 INP를 통과하고 81%가 CLS를 통과하지만, 62%만이 LCP를 통과합니다. 이것이 전체 통과율을 48%로 끌어내리는 원인입니다. 아래 워크플로우에서 TTFB와 LCP를 가장 먼저 우선시하는 이유가 바로 이 때문입니다.

CoreDash의 집계 데이터도 같은 이야기를 해줍니다. 이 정확한 워크플로우(TTFB → LCP → INP → CLS 순서)를 구현한 사이트 전체에서, CrUX 기준 "실패"에서 "3가지 지표 모두 통과"로 가는데 걸린 평균 시간은 4~6주였습니다: 구현에 1~2주, 그리고 28일의 CrUX 롤링 기간(rolling window)이 개선 사항을 반영하는 데 2~4주. TTFB를 먼저 수정하지 않고 JavaScript 최적화로 직행한 사이트들은 기초가 불안정했기 때문에 통과 상태에 도달하는 데 2~3배 더 오래 걸렸습니다.

1단계: 현재 상태 평가하기

무언가를 변경하기 전에, 정확히 어떤 지표가 어떤 페이지에서 실패하고 있는지 파악하세요. 이 단계를 건너뛰고 추측하면 잘못된 것을 수정하느라 시간을 낭비하게 됩니다.

Google Search Console 확인하기

Search Console 속성으로 이동하여 "경험(Experience)" 아래의 Core Web Vitals 보고서를 엽니다. 여기에서 다음을 확인할 수 있습니다:

• 우수(Good), 개선 필요(Needs Improvement), 또는 좋음(Poor)으로 평가된 URL의 수
• 어떤 특정 지표가 실패하고 있는지 (LCP, INP 또는 CLS)
• 동일한 문제를 공유하는 URL 그룹 (예: 모든 제품 페이지가 INP에서 실패함)

Search Console은 28일 롤링 기간 동안 Chrome 사용자의 실제 필드 데이터를 사용합니다. 이것이 Google이 순위를 매기는 데 사용하는 데이터입니다. Search Console에서 통과하는 것으로 나타나면, Lighthouse의 결과와 관계없이 통과하는 것입니다.

주요 페이지에서 PageSpeed Insights 실행하기

홈페이지, 블로그 게시물, 제품 페이지, 카테고리/컬렉션 페이지 등 각 페이지 유형의 URL을 하나 이상 테스트하세요. PageSpeed Insights는 특정 진단 결과와 함께 필드 데이터(사용 가능한 경우)와 랩(lab) 데이터를 모두 제공합니다.

먼저 필드 데이터 섹션("실제 사용자의 환경을 파악하세요(Discover what your real users are experiencing)"라고 표시됨)을 확인하세요. 3가지 지표 모두 녹색으로 표시되면 해당 페이지는 통과한 것입니다. 필드 데이터를 사용할 수 없는 경우, 해당 페이지는 CrUX 데이터를 위한 트래픽이 충분하지 않은 것입니다. Google은 대신 출처(origin) 수준 또는 URL 그룹 데이터를 사용할 수 있습니다.

RUM (Real User Monitoring) 설정하기

Search Console과 CrUX는 28일 롤링 기간을 가지므로 개선 사항이 나타나기까지 몇 주가 걸립니다. 변경 사항의 즉각적인 영향을 확인하려면 CoreDash와 같은 RUM 솔루션을 설정하세요. RUM은 모든 페이지, 모든 디바이스, 모든 국가에 대한 실시간 필드 데이터를 제공하므로, 다음 단계로 이동하기 전에 각 수정 사항이 효과가 있는지 검증할 수 있습니다.

2단계: 먼저 수정할 지표 식별하기

여러 지표가 실패하는 경우 다음 순서로 수정하세요:

TTFB 자체는 Core Web Vitals가 아니지만, TTFB의 매 밀리초는 LCP 및 FCP에 직접 추가됩니다. 800ms의 TTFB를 가진 페이지는 브라우저가 렌더링을 시작하기도 전에 이미 2.5초의 LCP 예산 중 3분의 1을 사용한 것입니다. TTFB의 CrUX "우수" 임계값은 800ms이지만, TTFB 개선은 페인트(paint) 지표로 직접 전달되기 때문에 빠를수록 항상 좋습니다. 자세한 내용은 Time to First Byte 가이드에서 확인하세요.

3단계: 기초 수정 (TTFB)

Time to First Byte가 지속적으로 400ms 이상인 경우 여기에서 시작하세요. 일반적인 문제는 다음과 같습니다:

• 느린 호스팅: 서버 수준의 캐싱을 제공하는 고품질 호스팅으로 업그레이드하세요. WordPress용 관리형 호스트(Kinsta, SiteGround, Cloudways) 또는 Shopify의 내장 인프라가 이를 처리합니다.
• 페이지 캐싱 없음: 서버가 매 요청마다 재생성하지 않도록 CMS가 완전히 렌더링된 HTML을 캐시하는지 확인하세요.
• CDN 없음: 방문자와 가까운 엣지(edge) 위치에서 페이지를 제공하도록 CDN(Cloudflare는 무료)을 설정하세요. Cloudflare 구성 가이드를 참조하세요.
• 리디렉션: 모든 리디렉션은 전체 왕복 시간(round trip)을 추가합니다. 불필요한 리디렉션 체인을 제거하세요.
• 느린 백엔드: 최적화되지 않은 데이터베이스 쿼리, 과도한 WordPress 플러그인 또는 무거운 서버 측 처리. 병목 현상을 식별하기 위해 쿼리 모니터링 도구를 사용하세요.

목표: 대부분의 방문자에 대해 TTFB를 200ms 미만으로 낮추십시오. 최소한 400ms 미만으로 낮추세요.

4단계: LCP 수정

TTFB가 안정되면 Largest Contentful Paint를 수정하세요. 과정은 다음과 같습니다:

LCP 요소 식별하기

실패한 페이지를 PageSpeed Insights에서 실행하고 진단(Diagnostics) 섹션에서 "Largest Contentful Paint 요소"를 찾으세요. 보통 히어로 이미지(hero image), 추천 이미지(featured image) 또는 큰 텍스트 블록입니다.

LCP가 이미지인 경우

1. 브라우저가 HTML에서 이를 찾을 수 있는지 확인하세요. 이미지 URL은 data-src 속성 뒤에 숨겨져 있거나 JavaScript로 로드되지 않고 일반적인 <img src=""> 태그에 있어야 합니다. 브라우저의 HTML 파서가 이미지 URL을 볼 수 없다면 일찍 로딩을 시작할 수 없습니다. 2025 Web Almanac에 따르면 웹사이트의 7%가 여전히 이런 방식으로 LCP 이미지를 숨기고 있습니다.
2. <img> 태그에 fetchpriority="high"를 추가하세요. 이는 대역폭을 두고 경쟁하는 다른 리소스보다 이 이미지를 우선시하도록 브라우저에 지시합니다. 이것이 없으면 브라우저는 스타일시트, 스크립트 및 다른 이미지를 먼저 다운로드할 수 있습니다. Google Flights를 대상으로 한 Google 테스트에서 이 단일 변경 사항으로 LCP가 2.6초에서 1.9초로 개선되었습니다.
3. loading="lazy"를 제거하세요. 지연 로딩(Lazy loading)은 이미지가 뷰포트 근처에 올 때까지 요청을 지연시킵니다. LCP 이미지에서 이 지연은 LCP 점수에 직접적인 영향을 미칩니다.
4. 파일 크기를 최적화하세요. WebP 또는 AVIF로 변환하세요. srcset과 sizes를 사용하여 뷰포트에 맞는 정확한 크기(dimensions)를 제공하세요.
5. 이미지가 HTML에 없는 경우 (CSS 배경 이미지, JavaScript를 통해 로드됨, 또는 <img> 태그를 변경할 수 없는 페이지에 있는 경우): 사전 로드(preload)를 추가하세요. <head>에 <link rel="preload" as="image" href="..." fetchpriority="high">를 사용하세요. 사전 로드는 이미지가 HTML 소스에 보이지 않더라도 브라우저가 일찍 이미지를 발견하도록 강제합니다. 이미 일반 <img> 태그에 있는 이미지의 경우, 파서가 이미 발견하기 때문에 사전 로드는 보통 불필요합니다.

LCP가 텍스트인 경우

1. 렌더링 차단 CSS를 제거하세요. 브라우저가 외부 스타일시트를 기다리지 않고 텍스트를 렌더링할 수 있도록 중요(critical) CSS를 생성하고 인라인으로 삽입하세요.
2. 폰트 로딩을 최적화하세요. 텍스트가 렌더링되기 전의 시간을 줄이기 위해 폰트를 직접 호스팅(Self host)하고 기본 폰트 파일을 사전 로드(preload)하세요.
3. 렌더링 차단 JavaScript를 최소화하세요. 중요하지 않은 JavaScript를 지연(Defer)시켜 HTML 파서를 차단하지 않도록 하세요.

5단계: INP 수정

LCP가 통과되면 Interaction to Next Paint를 해결하세요. INP는 사용자 상호 작용 중에 JavaScript가 메인 스레드를 차단할 때 실패합니다.

병목 지점 찾기

Chrome DevTools를 열고 성능(Performance) 패널로 이동하여 페이지와 상호 작용하는 자신을 기록(record)하세요. 긴 작업(long tasks) (50ms가 넘는 작업, 빨간색 막대로 표시됨)을 찾아보세요. 이것들이 브라우저가 클릭에 반응하는 것을 차단합니다.

메인 스레드를 일반적으로 차단하는 요소들:

• 메인 스레드 시간을 두고 경쟁하는 서드 파티 스크립트 (분석, 광고, 채팅 위젯, 마케팅 태그)
• 페이지 로드 중 실행되는 프레임워크, 페이지 빌더 또는 플러그인의 대용량 JavaScript 번들
• 클릭이나 키 입력에 대한 응답으로 너무 많은 작업을 수행하는 최적화되지 않은 이벤트 핸들러

수정 우선순위

1. 서드 파티 스크립트를 지연시키세요. 채팅, 분석, 소셜 및 마케팅 스크립트는 페이지 로드 중이 아니라 첫 번째 사용자 상호 작용 후에 로드되어야 합니다.
2. 중요하지 않은 퍼스트 파티 JavaScript를 지연(Defer)시키세요. 페이지가 대화형(interactive)이 되기 전에 실행할 필요가 없는 스크립트에는 defer 또는 async를 사용하세요.
3. 긴 작업을 나누세요. 만약 당신의 코드에 50ms 이상 걸리는 함수가 있다면, 작업 덩어리 사이사이에 브라우저가 사용자 입력을 처리할 수 있도록 메인 스레드에 양보(yield)하세요. 최신 방식은 scheduler.yield()입니다(Chrome 129+ 및 Edge에서 지원됨). 더 넓은 브라우저 지원을 원한다면 Promise 내부의 setTimeout(resolve, 0)으로 작업을 감싸는 대체 방법(fallback)을 사용하세요:

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. 사용하지 않는 JavaScript를 제거하세요. Chrome DevTools의 커버리지(Coverage) 탭을 사용하여 로드되지만 실행되지 않는 JavaScript를 식별하세요. 제거하거나 조건부로 로드하세요.

전체 INP 최적화 전략에 대해서는 INP 최적화 가이드를 참조하세요.

6단계: CLS 수정

CLS는 보통 수정하기 가장 쉬운 지표입니다. 가장 흔한 원인과 해결책:

크기(Dimensions)가 없는 이미지

모든 <img> 태그에는 명시적인 width 및 height 속성이 필요합니다. 이것들이 없으면 브라우저는 공간을 얼마나 확보해야 할지 알지 못하고 이미지가 로드될 때 콘텐츠가 이동(shift)합니다. 이것이 전 세계적으로 CLS의 첫 번째 원인입니다. CLS 가이드를 확인하세요.

웹 폰트 교체 (Web Font Swapping)

웹 폰트가 로드되고 대체 폰트(fallback)를 교체할 때, 텍스트가 리플로우(reflow)되어 주변 요소를 이동시킬 수 있습니다. 해결책: 폰트를 직접 호스팅(self host)하고, font-display: optional을 사용하거나 CSS size-adjust 속성을 사용하여 대체 폰트의 기준(metrics)을 웹 폰트와 맞추세요.

동적으로 주입되는 콘텐츠

로드 후 콘텐츠를 아래로 밀어내는 쿠키 배너, 알림 바, 광고 슬롯 및 팝업. 해결책: CSS min-height로 이러한 요소를 위한 공간을 확보하거나, 주변 레이아웃에 영향을 주지 않는 방식(예: 인라인 주입 대신 오버레이)으로 로드하세요.

7단계: 필드 데이터로 검증하기

수정 사항을 적용한 후에는 Lighthouse뿐만 아니라 실제 환경에서 효과가 있는지 검증해야 합니다.

• 즉시 검증: 실시간 필드 데이터를 보려면 CoreDash 또는 다른 RUM 도구를 사용하세요. 몇 시간 내에 변경 사항을 확인할 수 있어야 합니다.
• CrUX 검증: Chrome 사용자 환경 보고서(Chrome User Experience Report)는 28일 롤링 기간을 사용합니다. 개선 사항이 CrUX 데이터에 완전히 반영될 때까지 2~4주가 걸릴 것으로 예상하세요.
• Search Console 검증: Search Console의 Core Web Vitals 보고서는 CrUX를 기반으로 업데이트됩니다. CrUX가 개선을 나타내면 Search Console도 그에 따를 것입니다.

이러한 시차 때문에 RUM이 필수적입니다. RUM이 없으면 몇 주가 지날 때까지 변경 사항이 실제로 효과가 있었는지에 대한 가시성이 없습니다.

8단계: 모니터링 및 유지 관리

성능은 다시 저하될 수 있습니다. 모든 새로운 플러그인, 테마 업데이트 또는 서드 파티 스크립트는 작업을 원점으로 되돌릴 수 있습니다. 지속적인 모니터링을 설정하세요:

• 매주 Search Console Core Web Vitals 보고서를 확인하세요.
• 경고 기능이 있는 지속적인 실시간 모니터링을 위해 CoreDash를 사용하세요.
• 중요한 변경 사항(새 플러그인, 테마 업데이트, 새 서드 파티 스크립트)이 있을 때마다 PageSpeed Insights에서 다시 테스트하세요.
• 분기별로 서드 파티 스크립트를 감사(audit)하세요. 더 이상 필요하지 않은 것은 모두 제거하세요.

확인해야 할 모든 항목에 대한 완벽한 참고 자료는 Ultimate Core Web Vitals Checklist를 사용하세요.

빠른 승리: 가장 영향력이 큰 수정 사항

5가지만 할 시간이 있다면, 모든 플랫폼에서 가장 영향력이 큰 수정 사항은 다음과 같습니다:

이러한 효과 범위는 최적화 프로젝트 전반의 CoreDash RUM (Real User Monitoring) 데이터에서 나온 것입니다. 실제 개선 사항은 시작 지점, 호스팅 및 트래픽 프로필에 따라 다릅니다. 아주 나쁜 점수(LCP가 5초 이상)에서 시작하는 사이트는 더 큰 개선 효과를 보는 경우가 많습니다. 이미 임계값에 가까운 사이트는 절대적인 상승폭은 작을 수 있지만 실패와 통과의 차이를 만들 수 있습니다.

2025 Web Almanac 데이터는 이러한 우선순위를 뒷받침합니다. 홈페이지는 모바일에서 45%의 비율로 Core Web Vitals를 통과하는 반면, 보조 페이지는 56%가 통과합니다. 이 격차는 홈페이지가 더 동적인 콘텐츠, 더 큰 히어로 이미지, 더 많은 서드 파티 스크립트를 갖는 경향이 있기 때문입니다. 홈페이지가 실패하고 있지만 내부 페이지는 통과하고 있다면 LCP 및 INP 최적화 노력을 특히 홈페이지 템플릿에 집중하세요.