Largest Contentful Paint (LCP) 문제 식별 및 해결

이 가이드는 Largest Contentful Paint (LCP) 허브의 일부입니다. LCP는 화면에서 가장 큰 요소가 얼마나 빨리 렌더링되는지 측정합니다. 구글은 이 시간이 2.5초 미만이기를 권장합니다. 다음은 제가 페이지 속도 컨설팅을 진행할 때 사용하는 정확한 진단 프로세스입니다.

LCP 진단 및 해결을 위한 컨설턴트 가이드

제 이름은 Arjen Karel이며 페이지 속도 컨설턴트입니다. 수년간 수백 개의 웹사이트를 감사해 오면서 가장 지속적으로 발생하는 문제 중 하나가 Largest Contentful Paint (LCP)입니다. 이 가이드에서는 LCP 문제를 진단하고 해결하기 위해 제가 사용하는 정확한 방법론을 공유하겠습니다. 이 프로세스에 필요한 정확한 데이터를 얻기 위해 제가 만든 RUM 도구인 CoreDash에 대한 언급을 보실 수 있습니다. 여기서 설명하는 원칙은 보편적이지만, 제가 매일 구축하고 사용하는 도구의 실제 사례를 보여드리는 것이 좋다고 생각합니다.

LCP를 개선하는 것은 소거법의 과정입니다. 2025 Web Almanac에 따르면 모바일 오리진의 66%만이 LCP를 통과합니다. 즉, 웹의 3분의 1이 로딩 문제를 겪고 있다는 뜻입니다. 가장 느린 단계를 찾고, 고치고, 다시 측정하세요.

진단 방법론: 필드 데이터 먼저, 랩 데이터 나중

효과적으로 최적화하려면 2단계 진단 워크플로우를 채택해야 합니다. 이는 랩 환경에서 단순히 점수만 쫓는 것이 아니라, 사용자가 실제로 직면하고 있는 문제를 해결하도록 보장합니다.

1. 필드 데이터 (RUM 및 CrUX)는 무슨 일이 일어나고 있는지(WHAT)를 보여줍니다. 필드 데이터는 사이트를 방문하는 실제 사용자로부터 수집됩니다. LCP 문제가 있는지, 어떤 페이지가 영향을 받는지, 그리고 어떤 사용자(모바일 또는 데스크톱)가 그 문제를 겪고 있는지 알려줍니다. 실제 문제가 존재하는지 확인하려면 항상 여기서부터 시작해야 합니다.
2. 랩 데이터 (Lighthouse, DevTools)는 왜 그런 일이 발생하는지(WHY)를 진단하는 데 도움을 줍니다. 랩 데이터는 통제된 시뮬레이션 환경에서 수집됩니다. 필드 데이터를 통해 특정 페이지의 문제를 확인한 후에는 랩 도구를 사용하여 문제를 일관되게 재현하고 로딩 과정을 분석하여 근본 원인을 찾을 수 있습니다.

필드 데이터로 시작하여 최적화 노력이 실제 사용자에게 실제로 영향을 미치는 변화를 목표로 하도록 하세요.

1단계: 필드 데이터로 LCP 문제 식별하기

여러분의 첫 번째 과제는 실제 사용자 데이터를 사용하여 어떤 페이지에서 불량한 LCP가 발생하는지 확인하는 것입니다.

접근하기 쉬운 시작점: 구글 서치 콘솔

시작하기 좋은 곳은 구글 서치 콘솔의 Core Web Vitals 보고서입니다. 로그인하여 해당 보고서로 이동한 다음, 모바일 및 데스크톱 차트를 검토하세요. 구글이 "LCP 문제: 2.5초 초과"로 URL에 플래그를 지정하고 있다면, 특정 비율의 사용자가 좋지 않은 경험을 하고 있다는 것을 Chrome User Experience (CrUX) 보고서에서 확인한 것입니다.

서치 콘솔은 문제를 확인해주지만, 업데이트가 느리고 URL을 그룹화하여 보여줍니다. 실시간으로 페이지 수준의 세부 정보를 보려면 RUM 도구가 필요합니다.

Real User Monitoring (RUM): 페이지 수준의 세부 정보

web-vitals 라이브러리를 사용하여 데이터를 애널리틱스 백엔드로 보내는 자신만의 RUM 설정을 구축할 수도 있지만, 이는 상당한 엔지니어링 노력이 필요합니다.

저는 이를 위해 특별히 CoreDash를 구축했습니다. 스크립트 태그 하나만 추가하면 모든 실제 방문자로부터 페이지, 기기, 요소별로 분류된 LCP 데이터를 수집하기 시작합니다.

좋은 RUM 도구를 사용하면 다음을 확인할 수 있습니다:

• 특정 URL에 대한 정확한 LCP 점수.
• 모든 LCP 요소(예: 이미지, 헤드라인)의 분류와 어떤 요소가 느린 LCP와 가장 자주 연관되는지 파악.
• 모든 페이지 뷰에 대한 4가지 LCP 단계 각각의 정확한 타이밍으로 병목 현상의 위치 파악.

LCP 요소 그 자체를 넘어서서 살펴보는 것이 중요합니다. 잘 문서화된 사례 연구에서, 보다폰(Vodafone)은 LCP를 31% 개선했으며 이는 매출의 8% 증가로 직접 이어졌습니다. 그들의 최적화는 필드 데이터 분석과 타겟팅된 수정 사항의 조합을 사용하여 주요 랜딩 페이지에서 특정 LCP 병목 현상을 식별하고 해결하는 데 집중되었습니다. LCP 최적화는 단순히 이미지에 관한 것만이 아닙니다. 서버 응답, 리소스 발견, 다운로드 및 페인트와 같은 전체 로딩 파이프라인을 이해해야 합니다.

예를 들어, CoreDash에서는 LCP 페이지로 이동하여 가장 느린 LCP 요소를 보여주는 데이터 테이블을 볼 수 있습니다. 특정 요소(예: 히어로 이미지의 특정 CSS 클래스)를 클릭하면 모든 지표를 필터링하여 해당 요소가 LCP였던 페이지의 성능 데이터만 볼 수 있습니다.

목표: 필드 데이터를 사용하여 가장 느린 페이지와 그 페이지에서 가장 흔한 LCP 요소를 찾는 것입니다. 그것이 여러분의 타겟입니다.

Performance Observer API로 LCP 측정하기

Performance Observer API를 사용하면 JavaScript에서 LCP 항목에 직접 액세스할 수 있습니다. 이는 RUM 도구가 필드 데이터를 수집하기 위해 내부적으로 사용하는 것과 동일한 API입니다. 다음 스니펫은 요소, 요소의 크기, 렌더링 시간을 포함하여 브라우저가 식별하는 모든 LCP 후보를 기록합니다.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

이는 개발 중 빠른 검증에는 유용하지만, 프로덕션 환경에서의 측정을 위해서는 탭 가시성 변경 및 뒤로/앞으로 캐시 복원과 같은 엣지 케이스를 처리하는 web-vitals 라이브러리를 사용해야 합니다.

2단계: 랩 도구로 병목 현상 진단하기

어떤 페이지를 고쳐야 할지 알았습니다. 이제 왜 느린지 파악해 봅시다. PageSpeed Insights 또는 Chrome DevTools의 Lighthouse 패널로 테스트를 실행하세요.

보고서에서 "Diagnostics" 섹션으로 스크롤을 내려 "Largest Contentful Paint element" 감사를 찾습니다. 이 워터폴 차트는 LCP 시간을 네 가지 하위 부분으로 나눕니다. 사용 중인 RUM 도구도 필드 데이터를 기반으로 유사한 분석을 보여주어야 합니다.

목표는 이 분석에서 가장 긴 단계를 찾는 것입니다. 그것이 주요 병목 현상이며, 가장 먼저 최적화 노력을 집중해야 할 부분입니다.

3단계: LCP 4가지 단계 이해하기

모든 LCP 점수는 순차적인 네 가지 단계의 합입니다. 이 사이트의 각 단계에는 특정 최적화 기술을 다루는 전용 가이드가 있습니다.

• Time to First Byte (TTFB): 이는 건너뛸 수 없는 기초입니다. 서버 응답이 느려지면 밀리초 단위로 LCP에 직접 더해집니다. 단 하나의 이미지를 최적화하기 전에 먼저 서버가 빠르게 응답하는지 확인해야 합니다. TTFB 최적화에 대해 자세히 알아보세요.
• Resource Load Delay: 이것은 "발견 문제(discovery problem)"이자 가장 흔한 문제 중 하나입니다. 브라우저는 알지 못하는 리소스를 다운로드할 수 없습니다. LCP 이미지가 CSS나 JavaScript 파일에 숨겨져 있거나, HTML에 있더라도 다른 리소스가 먼저 요청된다면 브라우저가 이미지를 너무 늦게 발견하여 귀중한 시간을 낭비하게 됩니다. Resource Load Delay에 대한 전체 가이드를 읽어보세요.
• Resource Load Duration: 이는 LCP 리소스 자체의 다운로드 시간입니다. 크고 압축되지 않은 이미지나 느린 네트워크 환경은 이 단계를 병목 현상으로 만들 수 있습니다. Resource Load Duration에 대한 전체 가이드를 읽어보세요.
• Element Render Delay: 이것은 "페인팅하기에 너무 바쁜" 문제입니다. LCP 이미지 파일이 완전히 다운로드되었더라도, 무거운 JavaScript 실행으로 인해 브라우저의 메인 스레드가 차단되면 화면에 이미지를 페인팅할 여유가 없습니다. Element Render Delay에 대한 전체 가이드를 읽어보세요.

파일 크기 및 렌더링 최적화로 넘어가기 전에 항상 TTFB가 빠르고 LCP 리소스를 검색할 수 있는지 확인하는 것부터 시작하세요.

4단계: 수정 사항 실행하기

병목 현상이 확인되었으면 수정 사항을 적용합니다. 구현 방식은 사용 중인 스택에 따라 다릅니다. 아래의 각 단계에서는 보편적인 원칙을 먼저 다룬 다음, WordPress 및 JS 프레임워크와 관련된 구체적인 내용을 설명합니다.

1. Time to First Byte (TTFB) 최적화

TTFB가 느리다면 (좋은 목표는 800ms 미만입니다), 이는 LCP의 하한선을 높게 설정하게 됩니다. TTFB를 개선하면 다른 모든 로딩 지표도 개선됩니다.

보편적인 TTFB 솔루션

• 캐싱 활성화: 이는 TTFB를 개선하는 가장 효과적인 방법 중 하나입니다. 캐싱은 페이지의 복사본을 생성하고 저장하여, 방문할 때마다 서버가 처음부터 페이지를 빌드할 때까지 기다릴 필요 없이 즉시 제공할 수 있게 해줍니다.
• CDN 사용: 콘텐츠 전송 네트워크(CDN)는 사용자와 물리적으로 가까운 서버에서 콘텐츠를 제공하여 네트워크 대기 시간을 줄여줍니다. CDN의 엣지(edge)에서 전체 HTML 페이지를 캐싱하는 것은 빠르고 글로벌한 TTFB를 위한 강력한 전략입니다. CDN 구성에 대한 자세한 팁은 최적의 성능을 위한 Cloudflare 구성 방법에 대한 가이드를 참조하세요.
• Brotli 또는 Gzip 압축 사용: 서버가 HTML, CSS, JavaScript와 같은 텍스트 기반 애셋을 압축하고 있는지 확인하세요. Brotli는 Gzip보다 더 나은 압축률을 제공하므로 우선적으로 고려해야 합니다.
• 0-RTT와 함께 HTTP/3 사용: 서버가 HTTP/3를 사용하도록 구성되어 있는지 확인하세요. 이는 더 나은 멀티플렉싱을 포함하여 상당한 성능 이점을 제공합니다. 0-RTT (Zero Round Trip Time Resumption)를 지원하여 재방문자의 연결 설정 시간을 없애고 즉각적인 TTFB 향상을 제공합니다.
• 103 Early Hints 사용: 고급 수준의 속도 향상을 원한다면 103 Early Hints 상태 코드를 사용하세요. 이를 통해 서버나 CDN은 전체 HTML 문서를 준비하는 동안 브라우저에 중요한 CSS 및 JS 파일에 대한 힌트를 보낼 수 있으며, 다운로드가 더 일찍 시작될 수 있습니다. 전체 구현 가이드는 103 Early Hints에 대한 기사를 참조하세요.

플랫폼별 TTFB 수정

WordPress에서:

• 품질 좋은 호스팅에 투자하세요: WordPress에서 느린 TTFB는 종종 호스팅 환경과 관련이 있습니다. 저렴한 공유 호스팅은 병목 현상이 될 수 있습니다. 성능에 최적화된 매니지드 WordPress 호스팅을 고려해 보세요.
• 캐싱 플러그인 사용: 고품질 캐싱 플러그인(예: WP Rocket, W3 Total Cache)은 필수입니다. 이 플랫폼에서 효과적인 캐싱의 핵심인 정적 HTML 파일 생성을 대신 처리해 줍니다.

JS 프레임워크에서:

• 올바른 호스팅 플랫폼 선택: Node.js 애플리케이션의 경우 Vercel이나 Netlify와 같은 플랫폼은 SSR/SSG 프레임워크에 매우 최적화되어 있으며 지능형 캐싱 및 서버리스 함수 실행 기능을 기본적으로 제공합니다.
• SSR 캐싱 구현: Server-Side Rendering을 사용하는 경우, 모든 요청마다 다시 렌더링하는 것을 피하기 위해 렌더링된 페이지를 서버에 캐싱(예: Redis 또는 인메모리 캐시 사용)하세요.
• 서버리스 콜드 스타트 주의: 렌더링을 위해 서버리스 함수를 사용하는 경우 "콜드 스타트(cold start)"(일정 기간 활동이 없는 후의 첫 번째 요청) 시 높은 TTFB가 발생할 수 있다는 점에 유의하세요. 이를 완화하기 위해 프로비저닝된 동시성(provisioned concurrency) 또는 keep-alive 전략을 사용하세요.

2. Resource Load Delay 감소

이것은 종종 가장 큰 병목 현상입니다. 브라우저가 작업할 준비가 되었지만 메인 이미지나 폰트 파일을 즉시 찾지 못했다는 의미입니다. 이러한 지연은 일반적으로 두 가지 문제 중 하나로 인해 발생합니다. 즉, 리소스가 늦게 검색되거나 다운로드 우선순위가 낮게 부여된 경우입니다. 이 주제에 대한 전체 가이드를 보려면 Resource Load Delay에 대한 전용 가이드를 읽어보세요.

보편적인 로드 지연 솔루션

Resource Load Delay에 대한 보편적인 솔루션은 초기 HTML 마크업에서 LCP 리소스를 검색할 수 있게 하고 브라우저에서 높은 우선순위를 부여받도록 하는 것입니다. 이를 달성하는 방법은 다음과 같습니다:

• LCP 리소스 검색 가능하게 만들기: 가장 중요한 단계는 서버가 전송하는 HTML에 LCP 요소가 존재하도록 하는 것입니다. 브라우저는 고속 "프리로드 스캐너(preload scanner)"를 사용하여 원시 HTML을 미리 살펴보고 다운로드할 이미지 및 스크립트와 같은 리소스를 찾습니다. LCP 이미지가 CSS background-image를 통해 로드되거나 JavaScript로 주입되는 경우, 이 스캐너에는 보이지 않아 심각한 지연이 발생합니다. 가장 견고한 해결책은 항상 서버에서 렌더링된 HTML에 src 속성이 있는 표준 <img> 태그를 사용하는 것입니다.
• preload를 사용해 로드 순서 제어: LCP 리소스를 직접 검색할 수 있게 만들 수 없는 경우(폰트나 CSS 배경 이미지에서 흔히 발생), 차선책은 <link rel="preload">를 사용하는 것입니다. 이 태그는 HTML <head> 내에서 명시적인 지시어 역할을 하여, 브라우저가 자연스럽게 리소스를 발견했을 때보다 훨씬 일찍 중요한 리소스의 다운로드를 시작하도록 지시합니다. 구현 세부 정보 및 예제는 LCP 이미지를 미리 로드하는 방법에 대한 가이드를 참조하세요.
• fetchpriority로 높은 우선순위 확보: 리소스를 검색할 수 있는 경우라도 브라우저가 해당 리소스에 가장 높은 다운로드 우선순위를 부여하지 않을 수 있습니다. <img> 태그 또는 <link rel="preload"> 태그에 fetchpriority="high"를 추가하는 것은 이 특정 리소스가 UX에 가장 중요하다는 강력한 힌트를 브라우저에 제공하여, 다른 리소스와의 대역폭 경쟁에서 이길 수 있도록 돕습니다.

플랫폼별 로드 지연 수정

WordPress에서:

• 페이지 빌더의 배경 이미지 피하기: 많은 페이지 빌더에서 히어로 이미지를 div에 CSS background-image로 쉽게 설정할 수 있게 합니다. 이로 인해 브라우저의 프리로드 스캐너가 이미지를 볼 수 없게 됩니다. 가능하면 표준 <img> 블록을 대신 사용하세요. 그렇지 않다면 해당 특정 이미지를 미리 로드하기 위해 플러그인이나 커스텀 코드가 필요할 수 있습니다.
• LCP 이미지에 대한 지연 로딩 비활성화: 많은 최적화 플러그인이 모든 이미지를 자동으로 지연 로딩(lazy-load)합니다. 플러그인 설정에서 LCP 이미지(그리고 종종 페이지의 처음 몇 개 이미지)가 지연 로딩에서 제외되도록 설정해야 합니다. 이는 매우 흔한 실수이므로 지연 로드된 LCP 이미지 수정에 대한 전용 기사를 마련했습니다.

JS 프레임워크에서:

• Server-Side Rendering (SSR) 사용: 이것은 종종 가장 효과적인 수정 방법입니다. 기본 Client-Side Rendered (CSR) React 앱은 최소한의 HTML만 전송하며, 큰 JS 번들이 다운로드되고 실행된 후에야 LCP 요소가 존재하게 됩니다. Next.js나 Remix와 같은 SSR 프레임워크는 <img> 태그를 포함한 완전한 HTML을 전달하므로 브라우저가 이를 즉시 발견할 수 있습니다.
• 프레임워크 전용 이미지 컴포넌트 사용: Next.js와 같은 프레임워크는 priority prop이 있는 이미지 컴포넌트를 제공합니다. priority prop을 사용하면 LCP 이미지에 자동으로 fetchpriority="high" 및 기타 최적화가 적용됩니다.

3. Resource Load Duration 단축

LCP 리소스를 가능한 한 작게 유지하는 것은 여전히 프로세스의 필수적인 부분입니다. 이 단계는 네트워크를 통해 LCP 리소스 파일을 다운로드하는 데 걸리는 시간에 관한 것입니다. 이미지 최적화 기술에 대한 전체 가이드는 LCP 이미지 최적화에 대한 기사를 참조하고, 특히 Resource Load Duration에 대한 자세한 내용을 확인하세요.

보편적인 로드 시간 솔루션

• 최신 형식과 반응형 이미지를 통한 파일 크기 축소: 다운로드 시간을 단축하는 가장 직접적인 방법은 파일을 더 작게 만드는 것입니다. 이미지의 경우 이는 AVIF 또는 WebP와 같은 현대적이고 효율적인 형식을 사용하는 것을 의미합니다. 또한 <picture> 요소 또는 srcset 및 sizes 속성을 사용하여 반응형 이미지를 제공해야 합니다. 이렇게 하면 모바일 기기 사용자가 거대한 데스크톱 크기의 이미지를 강제로 다운로드하는 대신, 더 작은 화면에 적절하게 크기가 조정된 이미지를 받을 수 있습니다. 400픽셀 너비의 모바일 화면에는 2000픽셀 너비의 이미지 파일이 필요하지 않습니다. 텍스트 기반 LCP의 경우, 폰트가 효율적인 WOFF2 형식인지 확인하고 사용하지 않는 문자를 제거하기 위해 서브셋(subset) 처리되었는지 확인하세요.
• 네트워크 경합 감소: LCP 리소스는 사용자의 제한된 네트워크 대역폭을 위해 경쟁해야 합니다. 애널리틱스 스크립트나 스크롤 아래 콘텐츠용 CSS와 같은 중요하지 않은 리소스의 로드를 지연시키면, 브라우저가 대역폭을 확보하여 LCP 리소스를 더 빠르게 다운로드하는 데 집중할 수 있습니다.
• 기본 도메인에 중요 리소스 호스팅: 가능한 경우 다른 도메인에서 LCP 리소스를 로드하지 마세요. 다른 서버에 대한 새로운 연결을 설정하면 시간이 많이 소요되는 DNS 조회 및 핸드셰이크가 추가됩니다.

플랫폼별 로드 시간 수정

WordPress에서:

• 이미지 최적화 플러그인 사용: ShortPixel이나 Smush 같은 도구는 업로드 시 이미지를 자동으로 압축하고 WebP/AVIF 같은 최신 형식으로 변환하며 반응형 srcset 크기를 생성할 수 있습니다.
• 수동으로 이미지 크기 조절: 업로드하기 전에 이미지를 필요한 크기 이상으로 크지 않게 조절하세요. 가장 큰 화면에서도 1200px 너비밖에 안 되는 공간에 4000px 너비의 이미지를 업로드하지 마세요.

JS 프레임워크에서:

• 이미지 CDN 사용: 강력한 솔루션입니다. Cloudinary, Imgix 또는 Akamai의 Image & Video Manager와 같은 서비스는 전체 최적화 프로세스를 자동화할 수 있습니다. 고품질 이미지 하나를 업로드하면, 빠른 CDN을 통해 각 사용자에게 완벽하게 크기 조정, 압축 및 포맷된 버전을 제공합니다.
• 빌드 도구 활용: 최신 프레임워크의 컴포넌트로 이미지를 임포트할 때 Webpack이나 Vite 같은 빌드 도구는 빌드 프로세스의 일부로 파일을 자동으로 해시(hash)하고 최적화할 수 있습니다.

4. Element Render Delay 단축

리소스 다운로드가 완료되었지만 아직 화면에 표시되지 않습니다. 이는 브라우저의 메인 스레드가 다른 작업으로 바빠서 요소를 페인트할 수 없음을 의미합니다. 이것은 또 다른 매우 흔하고 심각한 병목 현상입니다. 전체 가이드를 보려면 Element Render Delay에 대한 가이드를 읽어보세요.

보편적인 렌더 지연 솔루션

• 사용하지 않는 JavaScript 지연 또는 제거: 페이지의 초기 표시 부분 렌더링에 필수가 아닌 모든 JS는 defer 또는 async 속성을 사용하여 지연시켜야 합니다.
• Critical CSS 사용: 크기가 큰 렌더링 차단 스타일시트는 렌더링을 지연시킬 수 있습니다. Critical CSS 기법은 스크롤 위쪽(above-the-fold) 콘텐츠를 스타일링하는 데 필요한 최소한의 CSS를 추출하여 <head>에 인라인으로 배치하고, 나머지 스타일은 비동기적으로 로드하는 방법입니다.
• 긴 작업 나누기(Break Up Long Tasks): 장기 실행 스크립트는 메인 스레드를 장기간 차단하여 렌더링을 방해할 수 있습니다. 이는 Interaction to Next Paint (INP) 저하의 주요 원인이기도 합니다. 코드를 작고 비동기적인 덩어리로 쪼개어 메인 스레드에 제어권을 yield 하도록 하세요.

플랫폼별 렌더 지연 수정

WordPress에서:

• 플러그인 감사(Audit): 너무 많은 플러그인, 특히 슬라이더나 복잡한 페이지 빌더와 같은 무거운 플러그인은 메인 스레드를 차단하는 상당한 CSS와 JS를 추가할 수 있습니다. 플러그인을 하나씩 비활성화하면서 성능을 저하시키는 원인을 식별하세요.
• 가벼운 테마 사용: 사용하지 않는 수십 가지 기능이 포함된 무거운 테마는 렌더링 차단 코드의 주요 원인이 될 수 있습니다. 성능 중심의 테마를 선택하세요.
• 플러그인 애셋 관리자 사용: Asset CleanUp 또는 Perfmatters와 같은 도구를 사용하면 특정 플러그인의 CSS 및 JS가 필요하지 않은 페이지에서 이를 조건부로 비활성화할 수 있습니다.

JS 프레임워크에서:

• 코드 스플리팅이 핵심입니다: 앱의 모든 JavaScript를 하나의 거대한 번들로 전송하지 마세요. 라우트별(사용자가 방문하는 페이지의 코드만 다운로드하도록) 및 컴포넌트별로 코드를 분할하세요.
• 컴포넌트 지연 로딩: 즉시 보이지 않는 컴포넌트(예: 스크롤 아래에 있거나 모달 창의 컴포넌트)를 지연 로드하려면 React.lazy 및 Suspense를 사용하세요. 이렇게 하면 초기 번들에서 해당 컴포넌트들을 제외할 수 있습니다.

심화: 후속 탐색을 위한 LCP 최적화

초기 LCP를 고치는 것도 중요하지만, 후속 페이지 로드를 최적화하면 사이트 브라우징이 즉각적으로 느껴지게 만들 수 있습니다.

페이지가 Back/Forward Cache (bfcache)의 자격 요건을 갖추었는지 확인

bfcache는 사용자가 다른 곳으로 이동할 때 메모리에 페이지의 완전한 스냅샷을 저장하는 브라우저 최적화입니다. 사용자가 뒤로 가기 버튼을 클릭하면 페이지를 즉시 복원할 수 있어 0에 가까운 LCP 결과를 얻을 수 있습니다. 많은 페이지가 unload 이벤트 리스너와 같은 이유로 이 캐시를 사용할 수 없습니다. Lighthouse의 "bfcache" 감사를 사용하여 페이지를 테스트하고 차단하는 기능을 제거하세요.

사전 렌더링(Prerendering)을 위해 Speculation Rules API 사용

Speculation Rules API를 사용하면 사용자가 다음에 이동할 가능성이 높은 페이지를 브라우저에 선언적으로 알려줄 수 있습니다. 그러면 브라우저가 배경에서 해당 페이지를 가져와 사전 렌더링(pre-render)할 수 있습니다. 사용자가 사전 렌더링된 페이지의 링크를 클릭하면 즉각적으로 이동이 이루어져 0에 가까운 LCP를 달성하게 됩니다. 이 규칙은 HTML의 <script type="speculationrules"> 태그에 정의할 수 있습니다.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

이 예제는 브라우저에게 현재 페이지에서 제품 페이지로 연결되는 링크를 찾고 사용자가 링크 위에 마우스를 올릴 때 사전 렌더링을 시작하도록 지시합니다.

네 가지 단계를 순서대로 진행하세요. 가장 큰 병목 현상을 먼저 수정하고 다시 측정한 다음 반복하세요.

다음 단계: 각 LCP 단계 상세

각 LCP 단계에는 고유한 가이드가 있습니다:

• LCP 이미지 최적화: 이미지 형식 선택, 반응형 이미지, 사전 로드 및 일반적인 이미지 최적화 실수에 대한 완벽한 가이드.
• Resource Load Delay: preload, fetchpriority, 그리고 적절한 HTML 구조를 사용하여 브라우저가 LCP 리소스를 최대한 빨리 발견할 수 있도록 보장하는 방법.
• Resource Load Duration: 파일 압축, 최신 형식, CDN 구성 및 네트워크 최적화를 통해 LCP 리소스의 다운로드 시간을 줄이는 방법.
• Element Render Delay: 브라우저 메인 스레드를 비워 다운로드 직후 LCP 요소를 페인트할 수 있도록 하는 방법으로, Critical CSS, JavaScript 지연(deferral), content-visibility를 다룹니다.