Largest Contentful Paint 이미지를 최적화하세요.

Largest Contentful Paint 이미지 최적화

이 가이드는 Largest Contentful Paint (LCP) 허브의 일부다. 대부분의 웹사이트에서 LCP 요소는 이미지다. 이미지를 잘못 처리하면 LCP 점수가 떨어진다. 이 글은 이미지를 빠르게 만드는 모든 기법을 다룬다.

Google에 따르면 인터넷 전체 페이지 뷰(데스크톱 및 모바일 포함)의 단 65%만이 '좋음(good)' Largest Contentful Paint 점수를 받는다. 즉, 35%의 페이지 뷰는 실패하며, 그 원인 중 하나는 이미지 관련 실수다. 이 글은 이미지가 Largest Contentful Paint 요소일 때 흔히 발생하는 모범 사례 패턴과 실수를 분석한다.

이 모든 요소가 중요하지만, LCP 요소가 이미지인 경우(매우 흔하다!) 로드 속도를 최대한 높이기 위해 취할 수 있는 간단한 단계가 있다.

Largest Contentful Paint 실험

나는 항상 말한다. 듣고 배우되 누구의 말도 맹신하지 마라. 잘못된 정보를 설파하는 '전문가'들이 너무 많다. 그래서 LCP 요소가 최적으로 로드되지 않을 때 어떤 일이 일어나는지 직접 확인할 수 있는 완전 자동화된 LCP 실험을 만들었다. github에서 내 LCP Test를 확인하거나 라이브 데모를 시도해 보라!

여러 LCP 시나리오를 자동으로 테스트하고 결과를 보여준다. 아래에서 이러한 시나리오를 논의하고, 어떻게 그리고 왜 LCP 이미지 요소의 속도를 높이거나 늦추는지 설명한다.

1. LCP 후보 제어: 텍스트 우선 전략

이미지 기반 Largest Contentful Paint를 개선하는 가장 빠른 방법은? 이미지를 사용하지 않는 것이다. 제대로 읽었다. 이유를 설명하겠다.

텍스트가 이미지보다 빠른 이유. 성능 차이는 요청 파이프라인에서 비롯된다. 텍스트 노드(<h1>이나 <p> 같은)는 메인 HTML 문서의 일부다. 별도의 리소스 요청이 없으며, 렌더링은 CSS에 의해서만 차단된다. 반면 이미지는 자체 HTTP 요청이 필요한 외부 리소스다. 이로 인해 CSS에 의해 차단될 뿐만 아니라 네트워크 지연(DNS, TCP, TLS 및 다운로드 시간)이 추가로 발생한다. 이 차이가 성능 차이의 핵심 이유이며, LCP 후보를 제어하는 것이 강력한 전문가 수준의 전략인 이유다.

그렇다면 이미지와 텍스트 중 무엇을 선택해야 할까? 이미지는 중요하다. 사이트를 시각적으로 매력적으로 만든다. 하지만 Core Web Vitals는 어떤 요소가 LCP가 되는지 신경 쓰지 않는다. LCP 요소가 텍스트 기반 요소일 때, 대개 First Contentful Paint와 동시에 발생한다.

그렇다면 텍스트 기반 Largest Contentful Paint 요소로 전환해야 할까? 상황에 따라 다르다! 이미지는 중요하며 사이트를 시각적으로 매력적으로 만든다. 즉, 지루하고 오래된 텍스트 요소로 전환하라고 권장하지는 않는다. 하지만 실수도 발생한다! "우발적 LCP(Accidental LCP)" 안티 패턴의 희생양이 된 카테고리 페이지가 너무 많다. 이는 페이지 상단에 설명적인 카테고리 텍스트를 추가하는 것을 "잊어버려", lazy loading된 제품 이미지가 LCP가 되고 로드 시간을 수 초 지연시키는 경우다. 디자이너가 주요 헤드라인보다 앞서 DOM 맨 위에 큰 히어로 배너를 배치할 때 자주 발생하며, 브라우저는 더 느린 LCP 후보를 선택할 수밖에 없게 된다.

2. 사용 가능한 가장 빠른 이미지 형식 사용

마지막 1바이트까지 짜내거나 WebP 대 AVIF의 완벽한 설정에 대한 열띤 논쟁은 접어두고, 한 가지는 동의하자. JPEG 및 PNG와 같은 구형 형식은 WebP나 AVIF와 같은 최신 형식에 비해 크기가 크고 느리다. 이미지 최적화 기법에 대한 전체 개요는 이미지 최적화 가이드를 참조하라.

일반적으로 LCP 이미지의 손실(lossy) WebP 또는 AVIF 버전을 제공해야 한다(모든 이미지에 이 형식을 사용하는 것이 더 좋지만, 여기서는 LCP에 초점을 맞춘다). WebP 지원이 약 95%, AVIF 지원이 약 92%이므로, 여전히 구형 fallback 이미지를 제공하는 것이 타당하다. 이를 위해 최신 형식을 지원하는 브라우저에만 제공하는 '점진적 향상(progressive enhancement)'을 사용하라.

디코딩 속도 대 압축률 트레이드오프

AVIF는 최고의 압축률(가장 작은 파일 크기)을 제공하지만, 복잡한 알고리즘으로 인해 렌더링 가능한 이미지로 디코딩할 때 WebP보다 더 많은 CPU 성능이 필요할 수 있다. 이는 브라우저의 래스터라이저(Rasterizer) 스레드에서 발생하는 CPU 바운드 작업이며, Element Render Delay를 직접적으로 증가시킨다. 파일 크기가 작은 AVIF가 다운로드는 더 빠를 수 있지만, 특히 모바일 기기에서는 디코딩 시간이 길어져 그 이점을 상쇄할 수 있다. Chrome DevTools Performance 패널에서 LCP 요소와 관련된 장기 실행 "Decode Image" 작업을 찾아 이를 진단할 수 있다. 이를 발견했다면, 단순한 다운로드 시간이 아니라 디코딩 속도가 병목 현상이라는 분명한 신호다.

전문가 인사이트: JPEG-XL의 경우. 진정한 전문가 가이드라면 JPEG XL을 다루어야 한다. 기술적으로 뛰어난 형식이며, 특히 기존 JPEG를 손실 없이 재압축할 수 있는 기능(레거시 사이트에 엄청난 이점)과 AVIF에는 없는 점진적 디코딩 지원 측면에서 그렇다. 하지만 Chrome에서 지원을 중단한 이후 광범위한 브라우저 지원이 부족하다는 것이 결정적인 단점이다. 이로 인해 아직 일반적인 웹 환경에서 사용하기는 어렵지만, 향후 주시해야 할 형식으로 자리 잡고 있다.

<picture> 요소 사용: <picture> 요소를 사용하면 브라우저가 지원하지 않는 이미지 형식을 건너뛰고, 처리할 수 있는 첫 번째 형식을 선택할 수 있다. 방법은 다음과 같다.

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

형식 협상과 반응형 크기 결합

최대 성능을 얻으려면 단일 <picture> 요소 내에서 형식 선택과 반응형 이미지 크기를 결합해야 한다. 이렇게 하면 모든 사용자가 기기에 맞는 최적의 형식과 최적의 크기를 얻을 수 있다. 브라우저는 위에서 아래로 <source> 요소를 평가하여 지원하는 첫 번째 형식을 선택한 다음, srcset 및 sizes 속성을 사용하여 올바른 해상도를 선택한다.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

이 패턴은 브라우저에 형식과 해상도의 최상의 조합을 선택할 수 있는 완전한 자유를 제공한다. 지원되는 브라우저를 사용하는 모바일 사용자는 작은 크기의 AVIF 파일을 받고, 구형 데스크톱 브라우저는 올바른 크기의 JPEG로 fallback된다.

콘텐츠 협상 사용

콘텐츠 협상을 사용하면 브라우저 지원 여부에 따라 서버가 다른 이미지 형식을 제공할 수 있다. 브라우저는 Accept 헤더를 통해 지원되는 형식을 알린다. 예를 들어, Chrome에서 이미지에 대한 Accept 헤더는 다음과 같다.

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

그런 다음 서버 측에서 accept 헤더를 읽고 헤더를 기반으로 '가장 좋은 형식'을 제공한다.

3. 반응형 이미지 사용

LCP 이미지를 최적화할 때 크기는 매우 중요하다. 가장 쉬운 개선 방법 중 하나는 사용자 화면에서 보기 좋은 가장 작은 크기의 이미지를 제공하는 것이다. 지나치게 큰 이미지는 아무런 기능도 하지 않으며, 특히 인터넷 연결이 느리거나 모바일 기기를 사용하는 사용자의 대역폭을 낭비하고 로드 시간을 늦춘다.

픽셀을 낭비하지 않으려면 다음 단계를 따르라.

반응형 이미지:

srcset 속성을 사용하여 사용자 기기에 따라 다른 이미지 크기를 제공하라. 이렇게 하면 작은 기기는 작은 이미지를 받게 되어 LCP 속도를 높이는 데 도움이 된다.

sizes 속성이 중요한 이유

w 설명자와 함께 srcset을 사용하면서 sizes 속성을 생략하는 것은 흔하고 비용이 많이 드는 실수다. sizes 속성이 없으면 브라우저는 기본값을 100vw(viewport 너비의 100%)로 가정할 수밖에 없다. 즉, 대형 데스크톱 화면에서 이미지가 작은 500px 열에만 표시되더라도 브라우저는 srcset 목록에서 거대한 이미지를 다운로드한다. 올바른 재료(srcset)는 제공했지만 레시피(sizes)는 빼먹은 셈이며, 이는 대역폭 낭비와 더 느린 LCP로 이어진다. sizes 속성은 브라우저에게 다양한 viewport 중단점에서 이미지가 실제로 얼마나 넓은지 알려주는 필수 레이아웃 컨텍스트를 제공하여 지능적인 다운로드 선택을 할 수 있게 한다.

w 및 x 설명자 이해

srcset 속성은 두 가지 유형의 설명자를 지원한다. viewport에 따라 이미지 크기가 변하는 반응형 디자인의 경우, w(너비) 설명자가 더 우수하고 필수적인 선택이다. 이는 sizes 속성과 함께 사용되어 브라우저가 레이아웃에서 렌더링되는 크기를 기반으로 최상의 이미지를 선택하도록 한다. 더 단순한 x(장치 픽셀 비율) 설명자는 화면의 픽셀 밀도만 고려하고 레이아웃에서 이미지가 실제로 얼마나 큰지는 무시하므로 아이콘과 같은 고정 크기 이미지에만 적합하다.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. 이미지를 화면 크기에 맞게 스케일링하라!

필요 이상으로 큰 이미지를 제공하지 마라. viewport에서 LCP 요소의 너비가 600px에 불과하다면 이미지 크기가 그보다 크지 않도록 하라. 이런 일은 매일 발생한다. 확인하려면 이렇게 하라. 이미지를 마우스 오른쪽 버튼으로 클릭하고 '요소 검사'를 선택하여 이미지를 검사한다. 이제 dev-tools가 표시되고 이미지 HTML이 파란색 배경으로 강조 표시된다. 이미지 렌더링 크기(443 x 139px)가 고유 이미지 너비(1090x343px)보다 훨씬 작은 것을 볼 수 있다. 이는 거의 3배나 크며 이미지를 리사이징했다면 파일 크기를 최소 50% 절약할 수 있었을 것이다.

5. Eager 로드된 LCP 이미지 사용

LCP에서 최고의 성능을 얻으려면 눈에 보이는 LCP 요소를 즉시 로드(eager load)하고 바로 보이지 않는 이미지는 lazy loading해야 한다. 이는 LCP 최적화에서 가장 흔한 실수 중 하나이며, lazy loading된 LCP 이미지 수정 관련 글에서 자세히 다룬다.

즉시 로딩(Eager Loading): LCP 요소(보통 스크롤 없이 볼 수 있는 영역의 콘텐츠)는 항상 즉시 로드되어야 한다. 이렇게 하면 가능한 한 빨리 표시되어 Largest Contentful Paint 렌더링에 걸리는 시간이 줄어든다. 기본적으로 이미지는 다르게 지정하지 않는 한 즉시 로드되지만, LCP 이미지에 loading="lazy"를 설정하지 않았는지 다시 확인하라. 이를 설정하면 LCP를 크게 지연시키고 Core Web Vitals 점수를 떨어뜨릴 수 있다. loading="eager"는 브라우저의 기본 동작이므로 속성을 완전히 생략해도 동일한 효과가 있다는 점을 이해하는 것이 중요하다. 핵심은 loading="lazy"가 없는지 확인하는 것이다.

기술적 경고: 지연(lazy) 이미지는 프리로드 스캐너에 의해 큐에 추가되지 않는다. 프리로드 스캐너는 중요한 리소스를 즉시 큐에 추가하는 매우 빠른 보조 HTML 스캐너다. 프리로드 스캐너를 우회하면 브라우저는 '보이는 이미지'를 큐에 추가하기 전에 렌더링 엔진이 완료될 때까지 기다려야 한다. 브라우저가 기본 loading="lazy"를 평가하려면 먼저 모든 render blocking CSS를 다운로드하고 파싱하여 렌더 트리를 구성해야 한다. 레이아웃이 계산된 후에야 브라우저는 이미지가 viewport 내에 있는지 확인할 수 있다. 즉, 전체 CSS가 LCP 이미지 다운로드를 위한 차단 종속성이 되며, 이는 성능에 재앙이다.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

스크롤 해야 보이는 영역(페이지가 처음 로드될 때 보이지 않는 이미지)의 경우, lazy loading을 하는 것이 맞다. 사용자가 이미지 근처로 스크롤할 때까지 로드를 지연시키면 LCP 요소와 같은 더 중요한 콘텐츠를 위해 대역폭을 확보할 수 있다. 이런 점에서 lazy loading은 양날의 검이다. 올바르게 사용하면 LCP 콘텐츠의 속도를 높이고, 잘못 사용하면 속도를 늦춘다!

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

어떻게 균형을 맞출까? 중요한 콘텐츠(예: LCP 이미지)는 즉시 로드하고 덜 중요한 리소스와 스크롤 해야 보이는 이미지는 lazy loading하라!

6. LCP 이미지 프리로드

LCP 이미지를 프리로드하면 브라우저가 HTML에서 이미지를 자연스럽게 발견하기 전에 즉시 가져오도록 지시한다. 프리로드에 대한 전체 가이드는 LCP 이미지 프리로드 전용 문서를 참조하라.

LCP 이미지를 프리로드하는 이유

브라우저가 페이지를 로드할 때 특정 순서로 HTML, 스타일시트 및 스크립트를 처리한다. 때로는 LCP 이미지가 체인 아래쪽에서 참조되어 브라우저가 예상보다 늦게 도달하는 경우가 있다. LCP 이미지를 프리로드하면 이 이미지가 중요하며 즉시 로드해야 함을 브라우저에 미리 알려주어 가장 큰 요소의 렌더링 지연을 줄인다.

LCP 이미지 프리로드 방법

<link rel="preload"> 태그를 사용하면 브라우저가 로딩 프로세스에서 가능한 한 빨리 LCP 이미지를 가져오기 시작하도록 할 수 있다.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

이렇게 하면 LCP 이미지가 처음부터 브라우저 큐에 포함되어, 이미지가 CSS나 스크립트 안에 묻혀 있을 때 흔히 발생하는 대기 시간을 피할 수 있다.

<!-- In the <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In the <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

기억하라: 너무 많은 리소스를 프리로드하면 브라우저에 과부하가 걸려 성능이 저하될 수 있으므로 LCP 이미지만 프리로드하라. Core Web Vitals에 가장 중요한 것에 집중하라.

7. LCP 이미지에서 페이드인(Fade-In) 애니메이션 제거

페이드인 애니메이션은 시각적으로 매력적일 수 있지만 숨겨진 LCP 병목 현상이다. LCP 요소(보통 이미지)에 페이드인 효과를 사용하면 브라우저는 애니메이션이 끝날 때까지 LCP를 계산하지 않는다. 이는 LCP 타이밍을 지연시키고 성능 지표를 크게 손상시킬 수 있다.

LCP 타이밍은 애니메이션 종료 후에 발생한다: 브라우저는 요소가 완전히 보일 때만 LCP가 완료된 것으로 간주한다. 페이드인 애니메이션이 있으면 이미지나 콘텐츠가 완전히 나타날 때까지 타이머가 계속 실행되어 LCP 점수에 몇 초가 쉽게 추가될 수 있다.

단순하게 유지하라: LCP 요소가 가능한 한 빨리 나타나도록 하려면 페이드인 효과를 피하라. 전환이나 애니메이션 없이 이미지가 로드되고 즉시 표시되도록 하라.

LCP 이미지에서 페이드인을 생략하라. 그 시각적 효과는 성능 비용을 감수할 가치가 없다.

8. LCP 요소 셀프 호스팅

LCP 이미지를 직접 호스팅(Self-host)하라. 타사 서버에 의존하면 통제할 수 없는 지연이 발생하여 LCP 및 전반적인 페이지 성능이 손상될 수 있다.

이렇게 생각해 보라: LCP 요소를 셀프 호스팅하지 않는 것은 이웃에게 끊임없이 설탕을 빌리는 것과 같다. 매번 걸어가서 문 앞에서 기다리고 그들이 집에 있기를 바라야 한다. LCP에 대해 타사 서버에 의존하면 웹사이트가 외부 리소스를 기다려야 하므로 로드 시간이 느려진다. 셀프 호스팅은 설탕을 자신의 주방에 보관하는 것과 같다. 빠르고, 직접적이며, 신뢰할 수 있다.

외부 의존성 줄이기: LCP 요소(예: 이미지)가 타사 서버에서 호스팅되는 경우 해당 서버의 속도, 가용성 및 추가적인 왕복 시간(RTT)에 휘둘리게 된다. 셀프 호스팅은 이러한 불확실성을 제거하여 자체 서버에서 직접 이미지를 제공할 수 있게 하므로 더 빠르고 안정적인 전송을 보장한다.

캐싱 및 최적화 사용: 셀프 호스팅을 하면 캐싱 전략을 최대한 활용할 수 있으며, 특히 CDN을 사용하는 경우 사용자에게 가장 가까운 서버에서 이미지를 제공할 수 있다. 이렇게 하면 LCP 요소를 로드하는 시간이 줄어들어 렌더링이 빨라진다.

이미지 최적화 제어: 셀프 호스팅을 사용하면 타사의 처리에 의존하지 않고 압축, 리사이징 또는 형식 선택 등 이미지가 최적화되는 방식을 제어할 수 있다. 이렇게 하면 이미지가 빠른 로딩에 완벽하게 맞춰지도록 보장할 수 있다.

9. LCP 요소에 대한 클라이언트 측 렌더링 피하기

클라이언트 측 렌더링(CSR)은 LCP에 할 수 있는 최악의 행동 중 하나다. LCP 요소(주로 큰 이미지, 텍스트 블록 또는 비디오)가 JavaScript를 통해 클라이언트 측에서 렌더링되는 경우, 브라우저가 중요한 콘텐츠를 표시하기 전에 스크립트를 다운로드, 파싱 및 실행할 때까지 기다려야 하므로 종종 LCP 시간이 느려진다.

렌더링 지연: CSR을 사용하면 브라우저가 JavaScript를 처리한 후에야 LCP 요소가 표시되므로 표시가 크게 지연될 수 있다. 이 시간이 길어질수록 LCP 점수는 나빠진다. 스크립트 처리에 1초를 더 쓸 때마다 사용자가 가장 중요한 콘텐츠를 보기 위해 기다려야 하는 시간도 길어진다.

서버 측 렌더링(SSR) 또는 정적 렌더링으로 전환: LCP 요소를 서버 측에서 렌더링하거나 정적 HTML 응답의 일부로 렌더링하면 브라우저가 JavaScript가 실행될 때까지 기다리지 않고 즉시 로드하고 표시할 수 있다. 브라우저가 HTML을 로드하기 시작할 때 LCP 요소를 바로 렌더링할 수 있으므로 LCP 타이밍이 크게 향상된다.

Critical Path에서 JavaScript 최소화: 일부 클라이언트 측 스크립트를 피할 수 없다면 LCP 요소 렌더링을 차단하지 않도록 하라. 중요하지 않은 스크립트는 지연(defer)시키거나 비동기(async) 처리하여 LCP 표시를 지연시키지 않도록 하라.

10. 레이아웃 이동(Layout Shifts)을 방지하기 위해 공간 예약

<img> 태그에 항상 명시적인 width 및 height 속성을 포함하라. 이는 브라우저에 대한 중요한 지침으로, 이미지가 다운로드되기 전에 브라우저가 이미지의 가로 세로 비율을 계산하고 레이아웃에 올바른 공간을 예약할 수 있게 한다.

전문가 인사이트: 최신 width 및 height 동작

일반적인 오해는 이러한 속성이 이미지를 비반응형으로 만든다는 것이다. 최신 브라우저에서는 더 이상 사실이 아니다. 브라우저는 이 HTML 속성을 사용하여 가로 세로 비율을 계산하고 공간을 확보하지만, CSS가 width: 100%; height: auto;로 설정되어 있으면 이미지는 여전히 완벽하게 반응형이다. 이 속성을 제공하는 것은 CSS aspect-ratio 속성만 사용하는 것보다 우수하다. render blocking CSS가 다운로드되고 파싱되기 전에 브라우저가 공간을 예약할 수 있어 중요한 시간적 우위를 제공하기 때문이다.

CSS 배경 이미지 처리

이 원칙은 CSS background-image의 컨테이너 역할을 하는 요소에도 적용된다. 레이아웃 이동의 일반적인 원인은 처음에 높이가 0으로 축소되었다가 배경 이미지가 적용될 때 크기가 커지는 <div>다. 이를 방지하려면 컨테이너 요소에 직접 CSS aspect-ratio 속성을 사용하여 처음부터 필요한 공간을 예약하라.

11. main thread 차단 감사(Audit)

LCP 이미지가 완벽하게 최적화되고 우선순위가 지정되었더라도, 브라우저의 main thread가 무거운 JavaScript를 실행하느라 바쁘면 최종 렌더링이 지연될 수 있다. 이러한 차단의 원인은 주로 분석, 광고 또는 고객 지원 위젯을 위한 타사 스크립트다. 이 스크립트는 CPU를 독점하여 Element Render Delay를 증가시킬 수 있다. Chrome DevTools의 Performance 패널을 사용하여 초기 로드 중 장기 실행 작업(long task)을 식별하고, 원인을 추적하며, 초기 렌더링에 중요하지 않은 작업은 지연시키거나 제거하라. 이 주제에 대한 자세한 내용은 Element Render Delay 가이드를 참조하라.

단계별 가이드: Chrome DevTools Performance 패널로 LCP 진단은 스로틀링(throttling)된 추적을 기록하고 Main 트랙에서 이러한 long task를 찾는 방법을 보여준다.

관련 LCP 최적화 가이드

이미지 최적화는 퍼즐의 한 조각일 뿐이다. 각 LCP 단계에는 자체 가이드가 있다.

• LCP 문제 해결 및 식별: field data와 실험실 도구를 사용하여 LCP 문제를 찾고 수정하는 완전한 진단 방법론이다.
• Resource Load Delay: 브라우저가 프리로드, fetchpriority 및 최적의 HTML 구조를 사용하여 가능한 한 빨리 LCP 리소스를 발견하도록 보장한다.
• Resource Load Duration: 압축, CDN 구성 및 네트워크 최적화를 통해 다운로드 시간을 단축한다.
• Element Render Delay: 브라우저가 다운로드 직후 LCP 요소를 그릴 수 있도록 main thread를 비운다.