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 테스트를 확인하거나 라이브 데모를 시도해 보세요!

여러 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" 안티 패턴의 희생양이 된 카테고리 페이지를 볼 때마다 돈을 받았다면 부자가 되었을 것입니다. 이는 페이지가 스크롤 없이 볼 수 있는 부분(above the fold)에 설명적인 카테고리 텍스트를 추가하는 것을 "잊어버려서" 지연 로드(lazy-loaded)된 제품 이미지가 LCP가 되고 로드 시간이 몇 초씩 지연되는 경우입니다. 이 현상은 디자이너가 DOM의 맨 위, 중요한 헤드라인 전에 큰 히어로 배너를 배치하여 브라우저가 더 느린 LCP 후보를 선택할 수밖에 없게 만들 때 자주 발생합니다.

2. 사용 가능한 가장 빠른 이미지 포맷 사용

마지막 바이트 하나까지 짜내거나 WebP 대 AVIF의 완벽한 설정에 대해 열띤 논쟁을 벌이지 않더라도 한 가지에는 동의합시다: JPEG나 PNG 같은 오래된 포맷은 WebP나 AVIF 같은 최신 포맷에 비해 크고 느립니다. 이미지 최적화 기법에 대한 전체 개요는 이미지 최적화 가이드를 참조하세요.

일반적인 규칙으로 LCP 이미지의 손실(lossy) WebP 또는 AVIF 버전을 제공해야 합니다 (가장 좋은 것은 모든 이미지에 이러한 포맷을 사용하는 것이지만, 여기서는 LCP에 중점을 둡니다). WebP 지원이 약 95%이고 AVIF 지원이 92%이므로 이전의 fallback 이미지도 함께 제공하는 것이 여전히 합리적입니다. 이를 위해 지원하는 브라우저에만 이러한 최신 포맷을 제공하는 '점진적 향상(progressive enhancement)'을 사용합니다.

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

AVIF는 최고의 압축률(가장 작은 파일 크기)을 제공하지만, 복잡한 알고리즘으로 인해 WebP에 비해 렌더링 가능한 이미지로 디코딩하는 데 더 많은 CPU 파워가 필요할 수 있습니다. 이는 브라우저의 래스터라이저 스레드에서 발생하는 CPU 바인딩 작업이며 Element Render Delay를 직접적으로 증가시킵니다. 더 작은 AVIF가 더 빨리 다운로드될 수 있지만, 특히 모바일 장치에서 디코딩 시간이 길어지면 그 이점이 무효화될 수 있습니다. Chrome DevTools 성능 패널에서 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됩니다.

콘텐츠 협상 사용

콘텐츠 협상(Content negotiation)을 통해 브라우저 지원에 따라 서버에서 다른 이미지 포맷을 제공할 수 있습니다. 브라우저는 Accept 헤더를 통해 지원되는 포맷을 알립니다. 예를 들어, Chrome에서 이미지에 대한 Accept 헤더는 다음과 같습니다:

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

그런 다음 서버 측에서 accept 헤더를 읽고 해당 헤더를 기반으로 '최고의 포맷'을 제공합니다.

3. 반응형 이미지 사용

LCP 이미지를 최적화할 때 크기는 정말 중요합니다. 가장 쉽게 얻을 수 있는 이점 중 하나는 사용자 화면에서 보기 좋게 유지되면서 가능한 한 가장 작은 치수의 이미지를 제공하는 것입니다. 큰 이미지는 아무런 기능도 하지 않으며, 특히 느린 연결이나 모바일 기기를 사용하는 사용자의 경우 대역폭을 낭비하고 로드 시간을 늦출 뿐입니다.

픽셀을 낭비하지 않으려면 다음 단계를 따르세요:

반응형 이미지:

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

sizes 속성이 중요한 이유

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

w 대 x 설명자 이해

srcset 속성은 두 가지 유형의 설명자를 지원합니다. 뷰포트에 따라 이미지 크기가 변경되는 반응형 디자인의 경우, 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. 화면 크기에 맞게 이미지 배율 조정!

필요 이상으로 큰 이미지는 제공하지 마십시오. LCP 요소가 뷰포트에서 600px 너비로만 표시된다면 이미지가 그보다 크지 않은지 확인하세요. 정말로, 저는 매일 이런 일이 일어나는 것을 봅니다! 확인하려면 이렇게 하세요: 이미지를 마우스 오른쪽 버튼으로 클릭하고 '요소 검사(inspect-element)'를 선택하여 이미지를 검사합니다. 이제 dev-tools가 보이고 이미지 HTML이 파란색 배경으로 강조 표시됩니다. 이제 이미지의 렌더링된 크기(443 x 139px)가 고유 이미지 너비(intrinsic image width)(1090x343px)보다 훨씬 작은 것을 볼 수 있습니다. 이는 거의 3배나 큰 크기이며, 이미지 크기를 조정했다면 파일 크기의 최소 50%를 절약할 수 있었을 것입니다.

5. 적극적(Eager) 로드 LCP 이미지 사용

LCP에서 최고의 성능을 얻으려면 눈에 보이는 LCP 요소를 적극적으로 로드해야 합니다(그리고 즉시 보이지 않는 이미지는 지연 로드해야 합니다). 이것은 LCP 최적화에서 가장 흔한 실수 중 하나이며, 지연 로드된 LCP 이미지 수정에 대한 문서에서 자세히 다룹니다.

적극적 로드(Eager Loading): LCP 요소(일반적으로 스크롤 없이 볼 수 있는(above-the-fold) 콘텐츠)는 항상 적극적으로 로드되어야 합니다. 이렇게 하면 가능한 한 빨리 나타나게 되어 Largest Contentful Paint가 렌더링되는 데 걸리는 시간을 줄입니다. 기본적으로 이미지는 다르게 지정되지 않는 한 적극적으로 로드되지만, LCP 이미지에 loading="lazy"를 설정하지 않았는지 다시 확인하세요. 그렇게 하면 LCP가 크게 지연되고 Core Web Vitals 점수가 떨어질 수 있습니다. loading="eager"가 브라우저의 기본 동작이므로 속성을 완전히 생략해도 같은 효과가 있다는 점을 이해하는 것이 중요합니다. 핵심 조치는 loading="lazy"가 존재하지 않도록 하는 것입니다.

Geek 알림: 지연(Lazy) 이미지는 프리로드 스캐너에 의해 대기열에 추가되지 않습니다. 프리로드 스캐너는 중요한 리소스를 즉시 대기열에 추가하는 초고속 보조 HTML 스캐너입니다. 프리로드 스캐너를 우회하면 브라우저는 '보이는 이미지'를 대기열에 추가하기 전에 렌더링 엔진이 완료될 때까지 기다려야 합니다. 브라우저가 네이티브 loading="lazy"를 평가하려면 먼저 모든 렌더링 차단 CSS를 다운로드하고 파싱하여 렌더 트리를 구성해야 합니다. 레이아웃이 계산된 후에야 브라우저가 이미지가 뷰포트 내에 있는지 확인할 수 있습니다. 즉, 전체 CSS가 LCP 이미지 다운로드의 차단 종속성이 되며, 이는 성능상 재앙입니다.

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

스크롤해야 볼 수 있는(below the fold) 이미지(페이지가 처음 로드될 때 보이지 않는 이미지)의 경우 지연 로드가 적절한 방법입니다. 사용자가 이미지 근처로 스크롤할 때까지 이러한 이미지의 로드를 지연시킴으로써 LCP 요소와 같은 더 중요한 콘텐츠를 위한 대역폭을 확보할 수 있습니다. 이런 방식에서 지연 로드는 양날의 검과 같습니다: 올바르게 사용하면 LCP 콘텐츠 속도를 높이고, 잘못 사용하면 느리게 만듭니다!

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

그 균형은? 중요한 콘텐츠(LCP 이미지 같은)는 적극적으로 로드하고, 덜 중요한 리소스와 스크롤해야 볼 수 있는 이미지는 지연 로드하는 것입니다!

6. LCP 이미지 사전 로드(Preload)

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 요소를 셀프 호스팅하세요. 타사 서버에 의존하면 통제할 수 없는 지연이 발생하여 LCP 및 전체 페이지 성능이 저하될 수 있습니다.

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

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

캐싱 및 최적화 사용: 셀프 호스팅을 사용하면 특히 CDN을 사용하는 경우 캐싱 전략을 최대한 활용하고 사용자에게 가장 가까운 서버에서 이미지를 제공할 수 있습니다. 이는 LCP 요소를 로드하는 데 걸리는 시간을 줄여 렌더링 속도를 높여줍니다.

이미지 최적화에 대한 통제: 셀프 호스팅을 사용하면 타사 처리에 의존하지 않고 압축, 크기 조정, 포맷 선택 등 이미지 최적화 방법을 제어할 수 있습니다. 이렇게 하면 이미지가 빠른 로딩에 완벽하게 맞춰지도록 할 수 있습니다.

9. LCP 요소에 대한 클라이언트 측 렌더링 방지

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

렌더링 지연: CSR에서는 브라우저가 JavaScript를 처리한 후에만 LCP 요소가 표시되므로 나타나는 시간이 크게 지연될 수 있습니다. 이 시간이 길어질수록 LCP 점수는 나빠집니다. 스크립트 처리에 소요되는 매 추가 초마다 사용자가 가장 중요한 콘텐츠를 보기 위해 더 오래 기다려야 함을 의미합니다.

서버 측 렌더링(SSR) 또는 정적 렌더링으로 전환: LCP 요소를 서버 측에서 렌더링하거나 정적 HTML 응답의 일부로 렌더링하면, 브라우저가 JavaScript가 시작되기를 기다리지 않고 즉시 로드하여 표시할 수 있습니다. 브라우저가 HTML 로딩을 시작할 때 즉시 LCP 요소를 렌더링할 수 있으므로 LCP 타이밍이 대폭 향상됩니다.

크리티컬 패스(Critical Path)의 JavaScript 최소화: 일부 클라이언트 측 스크립트를 피할 수 없다면, 해당 스크립트가 LCP 요소의 렌더링을 차단하지 않도록 하세요. 중요하지 않은 스크립트를 defer 또는 async 처리하여 LCP의 나타남을 지연시키는 것을 방지하세요.

10. 레이아웃 시프트를 방지하기 위한 공간 예약

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

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

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

CSS 배경 이미지 처리

이 원칙은 CSS background-image의 컨테이너 역할을 하는 요소에도 적용됩니다. 레이아웃 시프트의 흔한 원인은 초기에 높이가 0으로 축소되었다가 배경 이미지가 적용될 때 크기가 튀어나오는 <div>입니다. 이를 방지하려면 컨테이너 요소에 직접 CSS aspect-ratio 속성을 사용하여 시작부터 필요한 공간을 예약하세요.

11. 메인 스레드 차단에 대한 감사(Audit)

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

관련 LCP 최적화 가이드

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

• LCP 문제 수정 및 식별: 필드 데이터와 실습 도구를 사용하여 LCP 문제를 찾고 수정하기 위한 완벽한 진단 방법론입니다.
• Resource Load Delay: 프리로드, fetchpriority 및 최적의 HTML 구조를 통해 브라우저가 가능한 한 일찍 LCP 리소스를 발견하도록 합니다.
• Resource Load Duration: 압축, CDN 구성 및 네트워크 최적화를 통해 다운로드 시간을 줄입니다.
• Element Render Delay: 다운로드 후 바로 브라우저가 LCP 요소를 페인팅할 수 있도록 메인 스레드를 비웁니다.