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이 로딩 문제를 가지고 있다. 가장 느린 단계를 찾고, 고치고, 다시 측정하라.

진단 방법론: field data 먼저, lab data는 나중에

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

1. field data (RUM & CrUX)는 무슨 일이 일어나고 있는지 보여준다. field data는 사이트를 방문하는 실제 사용자로부터 수집된다. 이는 LCP 문제가 있는지, 어떤 페이지가 영향을 받는지, 어떤 사용자(모바일 또는 데스크톱)가 겪고 있는지 알려준다. 실제 문제가 존재하는지 확인하려면 항상 여기서 시작해야 한다.
2. lab data (Lighthouse, DevTools)는 왜 그런 일이 발생하는지 진단하도록 돕는다. lab data는 통제된 시뮬레이션 환경에서 수집된다. field data를 통해 특정 페이지의 문제를 확인했다면, lab 도구를 사용하여 지속적으로 문제를 재현하고 로딩 과정을 분석하여 근본 원인을 찾을 수 있다.

실제 사용자에게 영향을 미치는 변화를 목표로 하려면 field data로 시작하라.

1단계: field data로 LCP 문제 식별하기

첫 번째 작업은 실제 사용자 데이터를 사용하여 LCP가 저조한 페이지를 확인하는 것이다.

접근하기 쉬운 출발점: 구글 서치 콘솔

구글 서치 콘솔의 Core Web Vitals 보고서는 좋은 출발점이다. 로그인하여 보고서로 이동하고 모바일과 데스크톱 차트를 검토하라. 구글이 "LCP issue: longer than 2.5s"로 URL을 표시한다면, 일정 비율의 사용자가 열악한 경험을 하고 있다는 것을 CrUX (Chrome User Experience) 보고서로부터 확인한 것이다.

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

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

분석 백엔드로 데이터를 보내기 위해 web-vitals library를 사용하여 자체 RUM 설정을 구축할 수 있지만, 이는 상당한 엔지니어링 노력이 필요하다.

나는 정확히 이 목적을 위해 CoreDash를 만들었다. 스크립트 태그 하나를 추가하면 모든 실제 방문자의 LCP 데이터를 페이지, 기기, 요소별로 나누어 수집하기 시작한다.

좋은 RUM 도구는 다음을 볼 수 있게 해준다:

• 특정 URL에 대한 정확한 LCP 점수.
• 모든 LCP 요소(예: 이미지, 헤드라인)의 분석 및 느린 LCP와 가장 자주 연관되는 요소.
• 모든 페이지 뷰에 대한 4가지 LCP 단계별 정확한 타이밍으로, 병목 지점을 정확히 찾아낸다.

LCP 요소 그 이상을 보는 것이 중요하다. 잘 문서화된 사례 연구에서 Vodafone은 LCP를 31% 개선했고, 이는 매출 8% 증가에 직접적으로 기여했다. 이들의 최적화는 field data 분석과 표적화된 수정의 조합을 사용하여 주요 랜딩 페이지의 특정 LCP 병목 현상을 식별하고 해결하는 데 초점을 맞췄다. LCP 최적화는 단순히 이미지에 관한 것이 아니다. 전체 로딩 파이프라인(서버 응답, 리소스 발견, 다운로드, 페인트)을 이해해야 한다.

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

목표: field data를 사용하여 가장 느린 페이지와 가장 일반적인 LCP 요소를 찾아라. 그것이 당신의 타겟이다.

Performance Observer API로 LCP 측정하기

Performance Observer API를 사용하면 JavaScript에서 LCP 항목에 직접 접근할 수 있다. RUM 도구가 field data를 수집하기 위해 내부적으로 사용하는 것과 동일한 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 library를 사용해야 한다.

2단계: lab 도구로 병목 지점 진단하기

어떤 페이지를 고칠지 알았다. 이제 왜 느린지 파악하라. PageSpeed Insights나 Chrome DevTools의 Lighthouse 패널로 테스트를 실행하라.

보고서에서 "Diagnostics" 섹션으로 스크롤을 내리고 "Largest Contentful Paint element" 감사를 찾는다. 이 폭포수 차트는 LCP 시간을 4개의 하위 부분으로 세분화한다. RUM 도구도 field data를 기반으로 유사한 분석을 보여줄 것이다.

당신의 목표는 이 분석에서 가장 긴 단계를 찾는 것이다. 그것이 주요 병목 지점이며, 여기에 가장 먼저 최적화 노력을 집중해야 한다.

단계별 가이드: DevTools에서 작업하는 것을 선호하는가? Chrome DevTools Performance 패널로 LCP 진단하기는 스로틀링된 추적을 기록하고 LCP 분석 인사이트에서 동일한 4개의 하위 부분을 읽는 방법을 보여준다.

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

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

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

파일 크기와 렌더링 최적화로 넘어가기 전에 항상 TTFB가 빠르고 LCP 리소스를 발견할 수 있는지부터 확인하라.

4단계: 수정 사항 적용하기

병목 지점을 파악했다면 수정 사항을 적용하라. 구현은 당신의 스택에 따라 다르다. 아래의 각 단계는 먼저 보편적인 원칙을 다루고, 이어서 워드프레스 및 JS 프레임워크의 세부 사항을 다룬다.

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

TTFB가 느리다면(좋은 목표는 800ms 미만이다), LCP의 하한선이 높아진다. TTFB를 개선하면 다른 모든 로딩 지표가 향상된다.

보편적인 TTFB 솔루션

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

플랫폼별 TTFB 수정

워드프레스의 경우:

• 고품질 호스팅에 투자하라: 워드프레스에서 느린 TTFB는 호스팅 환경과 관련이 깊다. 저렴한 공유 호스팅은 병목 지점이 될 수 있다. 성능에 최적화된 매니지드 워드프레스 호스트를 고려하라.
• 캐싱 플러그인을 사용하라: 고품질 캐싱 플러그인(예: WP Rocket, W3 Total Cache)은 필수다. 이 플랫폼에서 효과적인 캐싱의 핵심인 정적 HTML 파일 생성을 처리한다.

JS 프레임워크의 경우:

• 적절한 호스팅 플랫폼을 선택하라: Node.js 애플리케이션의 경우 Vercel이나 Netlify 같은 플랫폼은 SSR/SSG 프레임워크에 고도로 최적화되어 있으며 기본적으로 지능형 캐싱과 서버리스 함수 실행을 제공한다.
• SSR 캐싱을 구현하라: Server-Side Rendering을 사용하는 경우 매 요청마다 다시 렌더링하지 않도록 서버에 렌더링된 페이지를 캐시하라(예: Redis나 인메모리 캐시 사용).
• 서버리스 콜드 스타트를 주의하라: 렌더링에 서버리스 함수를 사용하는 경우 "콜드 스타트"(비활성 기간 이후의 첫 번째 요청)에 높은 TTFB가 발생할 수 있음을 유의하라. 프로비저닝된 동시성이나 keep-alive 전략을 사용하여 이를 완화하라.

2. Resource Load Delay 줄이기

이것은 빈번하게 가장 큰 병목 지점이 된다. 이는 브라우저가 작업할 준비가 되었지만 메인 이미지나 폰트 파일을 즉시 찾지 못했음을 의미한다. 이 지연은 보통 리소스가 늦게 발견되거나 다운로드 우선순위가 낮게 설정되는 두 가지 문제 중 하나로 발생한다. 이 주제에 대한 전체 가이드는 Resource Load Delay 전용 가이드를 읽어보라.

보편적인 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 이미지 preload 방법에 대한 가이드를 참조하라.
• fetchpriority로 높은 우선순위를 보장하라: 리소스를 발견할 수 있더라도 브라우저가 가장 높은 다운로드 우선순위를 부여하지 않을 수 있다. <img> 태그나 <link rel="preload"> 태그에 fetchpriority="high"를 추가하는 것은 이 특정 리소스가 사용자 경험에 가장 중요하다는 것을 브라우저에 알리는 강력한 힌트가 되며, 다른 리소스와의 대역폭 경쟁에서 이기도록 돕는다.

플랫폼별 Load Delay 수정

워드프레스의 경우:

• 페이지 빌더의 배경 이미지를 피하라: 많은 페이지 빌더는 div의 CSS background-image로 히어로 이미지를 쉽게 설정하게 해준다. 이는 브라우저의 preload scanner에 보이지 않게 만든다. 가능하면 표준 <img> 블록을 대신 사용하라. 그렇지 않다면 해당 특정 이미지를 preload하기 위해 플러그인이나 커스텀 코드가 필요할 수 있다.
• LCP 이미지의 lazy loading을 비활성화하라: 많은 최적화 플러그인은 모든 이미지를 자동으로 lazy loading한다. 플러그인 설정에서 LCP 이미지(그리고 주로 페이지의 처음 몇 개 이미지)를 lazy loading에서 제외해야 한다. 이것은 너무나 흔한 실수이기 때문에 lazy loading된 LCP 이미지 수정에 대한 전용 기사가 있다.

JS 프레임워크의 경우:

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

3. Resource Load Duration 줄이기

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

보편적인 Load Time 솔루션

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

플랫폼별 Load Time 수정

워드프레스의 경우:

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

JS 프레임워크의 경우:

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

4. Element Render Delay 단축하기

리소스 다운로드는 끝났지만 아직 화면에 없다. 이는 브라우저의 main thread가 다른 작업으로 바빠서 요소를 페인트할 수 없음을 의미한다. 이것은 매우 흔하고 중요한 또 다른 병목 지점이다. 전체 가이드는 Element Render Delay 가이드를 읽어보라.

보편적인 Render Delay 솔루션

• 사용하지 않는 JavaScript를 연기하거나 제거하라: 페이지의 초기 시각적 부분을 렌더링하는 데 필수적이지 않은 모든 JS는 defer 또는 async 속성을 사용하여 연기해야 한다.
• 중요 CSS를 사용하라: 용량이 크고 render blocking을 일으키는 스타일시트는 렌더링을 지연시킬 수 있다. 중요 CSS 기법은 스크롤 위 콘텐츠의 스타일을 지정하는 데 필요한 최소한의 CSS를 추출하여 <head>에 인라인하고 나머지 스타일은 비동기적으로 로드하는 것이다.
• long task를 분할하라: 오래 실행되는 스크립트는 main thread를 장기간 차단하여 렌더링을 방해할 수 있다. 이는 저조한 Interaction to Next Paint (INP)의 주요 원인이기도 하다. 코드를 main thread에 yield하는 더 작은 비동기 청크로 분할하라.

플랫폼별 Render Delay 수정

워드프레스의 경우:

• 플러그인을 감사하라: 너무 많은 플러그인, 특히 슬라이더나 복잡한 페이지 빌더 같은 무거운 플러그인은 main thread를 차단하는 상당한 CSS와 JS를 추가할 수 있다. 플러그인을 하나씩 비활성화하여 성능을 저하시키는 요소를 식별하라.
• 가벼운 테마를 사용하라: 사용하지 않는 수십 개의 기능이 있는 비대한 테마는 render blocking 코드의 주요 소스가 될 수 있다. 성능에 초점을 맞춘 테마를 선택하라.
• 플러그인 에셋 매니저를 사용하라: Asset CleanUp이나 Perfmatters 같은 도구를 사용하면 필요하지 않은 페이지에서 특정 플러그인의 CSS와 JS를 조건부로 비활성화할 수 있다.

JS 프레임워크의 경우:

• 코드 스플리팅이 핵심이다: 앱의 모든 JavaScript를 하나의 거대한 번들로 전송하지 마라. 라우트별로(사용자가 방문하는 페이지의 코드만 다운로드하도록) 그리고 컴포넌트별로 코드를 분할하라.
• 컴포넌트를 lazy loading 하라: React.lazy와 Suspense를 사용하여 즉시 보이지 않는 컴포넌트(예: 스크롤 아래 또는 모달에 있는 컴포넌트)를 lazy loading하라. 이렇게 하면 초기 번들에서 제외된다.

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

초기 LCP를 수정하는 것도 중요하지만, 후속 페이지 로딩을 최적화하여 사이트 브라우징이 즉각적으로 느껴지게 만들 수 있다.

페이지가 Back/Forward Cache (bfcache)의 자격이 있는지 확인하라

bfcache는 사용자가 다른 페이지로 이동할 때 페이지의 전체 스냅샷을 메모리에 저장하는 브라우저 최적화다. 뒤로 가기 버튼을 클릭하면 페이지가 즉시 복원되어 거의 0에 가까운 LCP를 제공한다. unload 이벤트 리스너 같은 것들 때문에 많은 페이지가 이 캐시의 자격을 얻지 못한다. Lighthouse "bfcache" 감사를 사용하여 페이지를 테스트하고 차단 요소를 모두 제거하라.

Prerendering을 위해 Speculation Rules API를 사용하라

Speculation Rules API를 사용하면 사용자가 다음에 탐색할 가능성이 높은 페이지를 브라우저에 선언적으로 알려줄 수 있다. 그러면 브라우저가 백그라운드에서 이 페이지들을 가져와 pre-rendering 할 수 있다. 사용자가 prerendering된 페이지의 링크를 클릭하면 탐색이 즉각적으로 이루어져 거의 0에 가까운 LCP를 제공한다. HTML의 <script type="speculationrules"> 태그에서 이러한 규칙을 정의할 수 있다.

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

이 예제는 브라우저에게 현재 페이지에서 제품 페이지로 가는 링크를 찾고, 사용자가 링크에 호버할 때 prerendering을 시작하도록 지시한다.

4단계를 순서대로 진행하라. 가장 큰 병목 지점을 먼저 고치고, 다시 측정하고, 반복하라.

다음 단계: 각 LCP 단계 상세 정보

각 LCP 단계에는 전용 가이드가 있다:

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