LCP 리소스 로드 지연(Resource Load Delay) 최적화

이 가이드는 Largest Contentful Paint (LCP) 허브의 일부입니다. 리소스 로드 지연(Resource Load Delay)은 종종 불량한 LCP 점수에 가장 큰 영향을 미치는 단일 요인입니다. 실제 문제는 브라우저가 이미지를 너무 늦게 발견했다는 것임에도 불구하고, 대부분의 팀은 이미지 압축에만 집중합니다.

LCP 리소스 로드 지연(Resource Load Delay) 최적화

Largest Contentful Paint (LCP)는 TTFB, 리소스 로드 지연(Resource Load Delay), 리소스 로드 시간(Resource Load Duration), 요소 렌더링 지연(Element Render Delay)의 네 가지 단계로 구성됩니다. 개발 노력은 종종 파일 압축을 통해 로드 시간을 줄이는 데 집중되지만, 이는 종종 더 큰 지연의 원인이 되는 리소스 로드 지연을 간과하는 것입니다. 다운로드가 시작되기 전의 이 지연은 LCP에 수백 밀리초를 추가하여 2.5초의 'Good' 임계값을 초과하게 만들 수 있습니다.

간단한 팁: LCP가 이미지인 경우 거의 항상 텍스트보다 결과가 나쁠 것입니다. RUM 데이터에서 LCP 요소 유형을 추적해야 합니다. 그렇지 않으면 눈을 가리고 비행하는 것과 같습니다.

정확한 정의: 다운로드 전의 결정적인 대기 시간

리소스 로드 지연(Resource Load Delay)은 TTFB와 브라우저가 LCP 리소스의 다운로드를 시작하는 시점 사이의 시간입니다. 이는 다운로드 시간이 아니라 페치(fetch)가 시작되기 전에 발생하는 발견 지연(discovery latency)입니다. 이 값이 높으면 브라우저가 초기 HTML payload에서 리소스 URL을 찾을 수 없는 아키텍처상의 문제가 있음을 나타냅니다. 이 리소스 로드 지연은 브라우저가 LCP 리소스가 필요하다는 것을 식별하고 페치하기로 결정하는 데 소요되는 시간으로 볼 수 있습니다.

시스템 글꼴을 사용하여 렌더링되는 텍스트 기반의 LCP 요소의 경우, 외부 리소스를 페치할 필요가 없기 때문에 이 리소스 로드 지연은 일반적으로 0입니다. 높은 리소스 로드 지연 값은 이미지나 비디오 파일과 같은 외부 네트워크 리소스에 의존하는 LCP 요소에만 국한됩니다.

발견 엔진: 프리로드 스캐너(Preload Scanner) 대 DOM 파서(DOM Parser)

리소스 로드 지연을 줄이려면 브라우저가 리소스를 발견하는 방법을 이해해야 합니다. 이 발견 프로세스의 효율성이 지연을 결정하는 주요 요인입니다. 브라우저는 빠른 경로와 느린 경로라는 두 가지 메커니즘을 사용합니다.

• 프리로드 스캐너(The Preload Scanner - 빠른 경로): 이는 <img> 또는 <link> 태그에 있는 것과 같은 리소스 URL에 대해 원시 HTML을 스캔하는 고속 보조 파서입니다. CSS가 구문 분석되거나 JavaScript가 실행되기 전에 즉시 다운로드를 위해 대기열에 추가합니다. 이는 중요한 리소스에 대한 최적의 경로입니다.
• DOM 파서(The DOM Parser - 느린 경로): 전체 문서 객체 모델(DOM)과 CSS 객체 모델(CSSOM)을 구성하는 메인 파서입니다. CSS background-image나 JavaScript에 의해 주입된 요소와 같이 초기 HTML에서 찾을 수 없는 리소스는 이 파서에 의해서만 발견됩니다. 이는 다른 파일이 먼저 다운로드되고 실행되는 것에 의존하므로 높은 지연을 유발하는 종속성 체인을 만들기 때문에 느린 경로입니다.

리소스 로드 지연을 최적화하기 위한 전체 전략은 단 하나의 원칙, 즉 LCP 리소스 URL을 프리로드 스캐너가 발견할 수 있도록 보장하는 것에 기초합니다. 초기 HTML 문서에서 URL을 숨기는 모든 패턴은 브라우저가 느린 발견 경로를 사용하도록 강제합니다. 이 대기 시간은 리소스 로드 지연으로 직결됩니다. 모든 효과적인 최적화는 LCP 리소스를 빠른 경로에 배치하도록 HTML을 설계하는 것에 관한 것입니다. 브라우저 리소스 우선순위 지정에 대한 전체 가이드는 리소스 우선순위 지정에 관한 저희 기사를 참조하세요.

로드 지연이 중요한 이유

느린 LCP가 "파일 크기" 문제라는 것은 흔한 오해입니다. 이로 인해 팀은 리소스 로드 시간을 줄이기 위해 이미지 압축에만 집중하게 됩니다. 자산 최적화가 하나의 요인이긴 하지만, 실제 필드 데이터 분석에 따르면 LCP가 좋지 않은 많은 사이트에서 주요 성능 병목 현상은 리소스 로드 시간이 아니라 리소스 로드 지연(Resource Load Delay)입니다.

필드 데이터에 따르면 LCP 점수가 불량한 사이트의 중앙값은 1.3초의 리소스 로드 지연을 가집니다. 이는 'Good' LCP 점수를 위한 전체 2.5초 예산의 절반 이상이며, LCP 리소스 다운로드가 시작되기도 전에 모두 소비됩니다. 이 데이터는 이러한 사이트들이 실제 다운로드에 걸리는 시간보다 다운로드가 시작되기를 기다리는 데 거의 4배나 더 많은 시간을 소비한다는 것을 나타냅니다.

이 데이터는 개발 노력의 빈번한 방향 상실을 드러냅니다. 팀은 로드 시간을 몇 밀리초 단축하기 위해 이미지에서 몇 킬로바이트를 제거하는 데 몇 주를 보낼 수 있는 반면, 1.5초의 로드 지연을 유발하는 아키텍처 문제는 해결되지 않은 채 남아 있습니다. LCP는 순차적 프로세스입니다. 초기 단계의 지연은 후속 단계를 최적화한다고 해서 복구될 수 없습니다. 페치가 1초 이상 지연되면 다운로드 시간의 100ms 차이는 최종 LCP 점수와 무관합니다. 가장 큰 영향을 미치는 최적화는 단순한 자산 압축이 아니라 리소스 검색 가능성 향상과 같은 아키텍처 변경을 수반합니다. 자산을 더 작게 만드는 것에서 자산을 더 빨리 발견할 수 있도록 보장하는 것으로 초점을 옮겨야 합니다.

리소스 로드 지연을 감지하는 방법

리소스 로드 지연을 수정하려면 먼저 정확하게 측정해야 합니다. 전문적인 워크플로우는 먼저 실제 사용자 데이터(RUM)로 문제를 정의하고, 그 다음에 심층 분석을 위해 Chrome DevTools로 이동하는 것입니다.

1단계: 필드 데이터 분석(RUM)

필드 데이터 또는 Real User Monitoring(RUM)은 실제 사용자 세션에서 수집됩니다. 공개 Chrome User Experience Report (CrUX) 또는 제 도구인 CoreDash와 같은 RUM 도구는 '현실 세계에서 무슨 일이 일어나고 있는가?'라는 질문에 답합니다. 모든 기능을 갖춘 RUM 도구는 LCP 하위 부분의 분석도 제공하여 사용자 전체의 중앙값인 리소스 로드 지연을 보여줍니다. 이 데이터는 LCP 문제가 존재함을 검증하고, 어떤 URL이 영향을 받는지 보여주며, 사용자가 실제로 보고 있는 일반적인 LCP 요소를 드러냅니다. 진짜 문제를 해결하고 있는지 확인하려면 여기서부터 시작해야 합니다.

2단계: DevTools로 진단

RUM 데이터가 대상 페이지와 LCP 요소를 식별하면 Chrome DevTools를 사용하여 원인을 진단합니다. 여기서 목표는 문제를 재현하고 LCP 하위 부분을 측정하여 정확한 리소스 로드 지연 값을 얻는 것입니다. DevTools는 또한 Main Thread 분석을 수행하여 어떤 작업이 실행 중이고 렌더링 프로세스를 차단할 가능성이 있는지 정확히 확인하는 곳입니다.

Chrome DevTools Performance 패널 단계별 가이드

Chrome DevTools의 Performance 패널은 LCP를 해부하고 로드 지연을 정량화하는 데 없어서는 안 될 도구입니다.

1. 설정 및 구성:

• 페이지를 마우스 오른쪽 버튼으로 클릭하고 "검사(Inspect)"를 선택하거나 Ctrl+Shift+I (Windows/Linux) 또는 Cmd+Option+I (Mac) 단축키를 사용하여 Chrome DevTools를 엽니다.
• Performance 탭으로 이동합니다.
• 캡처 설정에서 Web Vitals 확인란이 활성화되어 있는지 확인합니다. 그러면 성능 타임라인에 Core Web Vitals 정보를 오버레이합니다.
• 현실적인 사용자 조건을 시뮬레이션하려면 CPU 및 Network 스로틀링을 적용합니다. CPU의 경우 "4x slowdown"을, 네트워크 프로필의 경우 "Fast 3G" 또는 "Slow 4G"를 사용하는 것이 모바일 테스트의 일반적인 시작점입니다.

2. 성능 프로필 기록:

• Performance 패널에서 "새로고침하여 프로필 기록(Record and reload page)" 버튼(원형 화살표 아이콘)을 클릭합니다. 그러면 기록이 시작되고 페이지가 새로고침되며, 페이지가 완전히 로드되면 기록이 중지됩니다.

3. 분석 및 해석:

• Timings 트랙: 기본 타임라인 보기에서 Timings 트랙을 찾습니다. LCP라는 레이블이 지정된 마커를 볼 수 있습니다. 이 마커 위로 마우스를 가져가면 기본 뷰포트 스크린샷에서 해당 LCP 요소가 강조 표시되고 전체 LCP 시간이 표시됩니다.
• 단계별 LCP 분석: Timings 트랙에서 LCP 마커를 클릭합니다. 패널 하단의 Summary 탭에서 LCP 타이밍에 대한 자세한 분석을 찾을 수 있습니다. 이 분석은 Load delay를 포함한 4개의 하위 부분 각각의 지속 시간을 밀리초 단위로 명시적으로 보여줍니다. 이 값은 해당 특정 페이지 로드에 대한 리소스 로드 지연을 가장 직접적이고 정확하게 측정한 것입니다.
• Main Thread 분석: 타임라인을 검사하는 동안 긴 작업(빨간색 삼각형이 표시된 활동 블록)이 있는지 Main 트랙을 살펴봅니다. 이러한 긴 작업이 LCP 리소스 로드가 완료된 후 LCP 마커가 나타나기 전에 발생한다면, 관련은 있지만 구별되는 문제인 요소 렌더링 지연(Element Render Delay)에 기여하고 있을 가능성이 높습니다.

일반적인 원인과 영향력이 큰 솔루션

높은 리소스 로드 지연은 LCP 리소스가 늦게 발견되거나 낮은 페치 우선순위가 부여되는 두 가지 이유 중 하나로 인해 발생합니다. 다음은 가장 일반적인 아키텍처상의 실수와 그 해결책입니다.

원인: CSS를 통해 로드된 LCP

문제: 프리로드 스캐너는 CSS 파일을 파싱하지 않습니다. LCP 이미지가 CSS background-image로 정의된 경우 그 URL은 이 고속 스캐너에 보이지 않습니다. 브라우저는 HTML을 다운로드하고, CSS 파일 링크를 찾고, CSS 파일을 다운로드하고, CSSOM을 구축한 다음 스타일을 적용한 후에야 비로소 이미지를 발견할 수 있습니다. 이 종속성 체인은 높은 리소스 로드 지연을 직접적으로 유발합니다. 이 패턴에 대한 자세한 내용은 백그라운드 이미지 지연에 대한 가이드를 참조하세요.

해결책: 올바른 구현 방법은 중요한 LCP 요소에 background-image를 사용하지 않는 것입니다. 대신 표준 <img> 태그를 사용하세요. 이렇게 하면 이미지 URL이 HTML에 직접 배치되어 프리로드 스캐너가 즉시 찾을 수 있습니다. CSS를 사용하여 동일한 시각적 결과를 얻을 수 있습니다.

구현 예시:

안티 패턴(이렇게 하지 마세요):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

모범 사례(대신 이렇게 하세요):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

이 구현은 동일한 시각적 결과를 제공하면서도 LCP 이미지를 가능한 한 가장 이른 순간에 발견할 수 있게 하여 로드 지연을 최소화합니다.

원인: 클라이언트 측 렌더링 및 JavaScript 주입

문제: React 또는 Vue와 같은 클라이언트 측 렌더링(CSR) 프레임워크를 사용하는 애플리케이션은 종종 최소한의 HTML 셸을 제공합니다. LCP <img> 태그를 포함한 실제 콘텐츠는 대용량 프레임워크 번들이 다운로드, 구문 분석 및 실행된 후에야 JavaScript에 의해 DOM에 삽입됩니다. 이 프로세스는 근본적으로 프리로드 스캐너로부터 LCP 리소스를 숨겨 높은 발견 지연을 초래합니다.

해결책: 가장 효과적인 솔루션은 초기 렌더링을 클라이언트에서 서버로 이동하는 것입니다.

• 서버 측 렌더링(SSR) 또는 정적 사이트 생성(SSG): SSR 또는 SSG와 같은 아키텍처 패턴은 서버에서 전체 HTML을 생성합니다. 브라우저는 <img> 태그와 그 src 속성을 포함하는 완전한 문서를 수신하여 프리로드 스캐너가 LCP 리소스를 즉시 발견할 수 있게 합니다. 이는 성능이 중요한 모든 페이지에 필수적인 아키텍처입니다.
• 프레임워크별 최적화: 최신 프레임워크는 내장된 최적화 기능도 제공합니다. 예를 들어 Next.js <Image> 컴포넌트에는 priority 속성이 있습니다. 이것을 true로 설정하면 프레임워크가 올바른 <link rel="preload"> 및 fetchpriority="high" 속성을 자동으로 추가하도록 지시하여 이미지가 올바른 우선순위로 발견되고 페치되도록 보장합니다.

원인: LCP 이미지에 loading="lazy" 사용

문제: 이것은 빈번하고 큰 영향을 미치는 실수입니다. loading="lazy" 속성은 뷰포트에 가까워질 때까지 이미지 페치를 지연시키라는 브라우저에 대한 직접적인 지시입니다. 이는 스크롤 아래(below-the-fold) 이미지에는 올바른 최적화이지만, 스크롤 위(above-the-fold)의 LCP 요소에 적용하는 것은 역효과를 낳습니다. 브라우저의 프리로드 스캐너는 loading="lazy"가 있는 이미지를 무시하도록 설계되어 있으므로 늦은 발견과 높은 리소스 로드 지연이 보장됩니다.

해결책: 이 해결책은 주의가 필요합니다.

• LCP 이미지에서 loading="lazy" 제거: LCP 요소가 될 가능성이 있는 모든 이미지는 loading="lazy" 속성을 가져서는 안 됩니다. 브라우저의 기본 동작은 loading="eager"이며, 이는 중요한 스크롤 위 콘텐츠에 대한 올바른 설정입니다. loading 속성을 완전히 생략해도 동일한 효과가 있습니다.
• 타사 도구 감사 및 구성: 타사 도구도 감사해야 합니다. WordPress 및 다양한 이미지 최적화 플러그인과 같은 많은 CMS 플랫폼은 자동으로 모든 이미지에 지연 로딩을 적용합니다. 이러한 동작에서 LCP 이미지를 제외하도록 이 도구들을 구성하는 것이 필수적입니다. 이 과정에는 종종 페이지의 처음 한두 개 이미지에 대한 제외 규칙을 만드는 것이 포함됩니다.

원인: 최적화되지 않은 HTML 구조 및 큰 문서

문제: 프리로드 스캐너는 HTML 문서를 위에서 아래로 처리합니다. 헤더 아이콘이나 채팅 위젯 스크립트와 같이 중요하지는 않지만 대역폭을 많이 사용하는 리소스가 <body>에서 LCP 요소보다 높은 곳에 배치되면 먼저 발견되고 다운로드 대기열에 추가됩니다. 이는 초기 네트워크 대역폭을 소비하고 LCP 리소스 다운로드를 지연시킬 수 있습니다. 큰 HTML 문서도 문제가 될 수 있습니다. 브라우저가 수신하는 첫 번째 데이터 청크(약 14KB)에 LCP 요소가 없으면 검색이 최소 한 번의 네트워크 왕복만큼 지연됩니다.

해결책: HTML 내에서 콘텐츠의 구조와 우선순위를 최적화합니다.

• HTML 재정렬: 가능한 한 LCP 요소의 <img> 태그나 텍스트 블록이 <body> 태그 내에서 최대한 일찍 나타나도록 합니다.
• 중요하지 않은 이미지의 우선순위 낮추기: HTML 소스의 초반에 나타나야 하는 비필수 이미지(헤더의 아이콘 등)의 경우 loading="lazy"를 적용합니다. 이는 프리로드 스캐너에게 해당 이미지를 건너뛰라고 지시하여 LCP 요소에 대한 다운로드 대기열을 보존합니다.
• 비필수 스크립트 지연: 분석, 광고 또는 소셜 미디어 위젯을 위한 스크립트는 초기 렌더링에 거의 중요하지 않습니다. <script> 태그를 <body> 끝으로 옮기거나 defer 속성을 사용하세요. 이렇게 하면 파서를 차단하거나 LCP 리소스와 네트워크 대역폭을 놓고 경쟁하는 것을 방지할 수 있습니다.

리소스 힌트를 사용한 고급 우선순위 지정

HTML에서 LCP 리소스를 발견할 수 있게 되면 리소스 힌트를 사용하여 브라우저가 해당 리소스를 페치하는 방법에 대해 더 명시적인 지시를 내릴 수 있습니다. 이러한 힌트는 검색 및 우선순위 지정에 대한 세밀한 제어를 제공합니다.

<link rel="preload">를 사용한 조기 발견 강제

<link rel="preload">는 힌트가 아니라 지시문입니다. 이는 메인 파서에서 아직 발견할 수 없더라도 브라우저가 리소스를 높은 우선순위로 다운로드하도록 강제합니다. 이것을 HTML의 <head>에 배치하는 것은 글꼴, CSS background-image 또는 DOM 깊숙이 위치한 LCP 이미지와 같은 리소스의 늦은 검색 문제를 해결하는 가장 직접적인 방법입니다. 전체 구현 세부 정보 및 예제는 LCP 이미지를 미리 로드하는 방법에 대한 전용 가이드를 참조하세요.

메커니즘

HTML 문서의 <head>에 preload 링크가 배치되면 프리로드 스캐너가 이를 식별하고 즉시 지정된 리소스를 다운로드 대기열에 추가합니다. 이는 외부 스타일시트의 @font-face를 통해 로드된 글꼴, CSS background-image LCP(<img> 태그를 사용하는 것이 선호되지만) 또는 복잡한 DOM 구조 내 깊은 곳에 위치한 LCP 이미지와 같은 리소스에 이상적입니다.

반응형 프리로딩

반응형 이미지를 미리 로드할 때는 중요한 구현 세부 정보가 필요합니다. 브라우저가 사용자의 뷰포트에 맞게 올바른 크기의 이미지를 미리 로드하고 낭비적인 이중 다운로드를 방지하려면 <link rel="preload"> 태그에 해당 <img> 태그의 속성을 완벽하게 반영하는 imagesrcset 및 imagesizes 속성이 반드시 포함되어야 합니다.

반응형 프리로딩 예시:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

잠재적인 함정

프리로딩은 페치 타이밍(로드 지연 및 로드 시간)을 해결하지만 페인트 타이밍은 해결하지 못합니다. 미리 로드된 이미지가 도착했을 때 메인 스레드가 무거운 JavaScript나 렌더링 차단 CSS로 인해 차단되어 있다면 이미지는 여전히 렌더링되기를 기다려야 하며, 이로 인해 병목 현상이 로드 지연에서 요소 렌더링 지연으로 바뀔 수 있습니다.

fetchpriority="high"와 브라우저의 우선순위 대기열

fetchpriority 속성은 리소스 다운로드의 상대적인 중요도를 신호하는 힌트입니다. 이를 통해 브라우저의 다운로드 대기열 내에서 리소스의 우선순위에 영향을 줄 수 있습니다.

브라우저 우선순위 작동 방식

브라우저는 페이지 로드 중에 리소스를 발견하면 각 리소스에 내부 우선순위 수준을 할당합니다. 기본적으로 뷰포트 내의 이미지는 "낮음(Low)" 우선순위로 시작하여 브라우저가 레이아웃을 완료하고 화면에 보인다고 판단하면 나중에 "높음(High)"으로 업그레이드됩니다. 이 업그레이드를 수행하려면 브라우저가 CSS를 먼저 다운로드하고 구문 분석해야 하므로 지연이 발생합니다. fetchpriority="high" 속성은 이미지가 발견되는 순간부터 우선순위를 "높음"으로 설정하여 이 과정을 완전히 우회합니다. 이는 우선순위 업그레이드 지연을 제거하기 때문에 LCP 이미지에 특히 큰 영향을 미칩니다.

preload 대 fetchpriority

이 두 가지 힌트는 다르지만 상호 보완적인 목적을 제공합니다. preload는 리소스가 언제 발견되어 대기열에 추가되는지에 영향을 미칩니다. fetchpriority는 일단 대기열에 들어간 리소스의 우선순위 수준에 영향을 미칩니다. 이 차이를 이해하는 것이 중요합니다. 프리로드는 늦은 발견을 해결하고, fetchpriority는 낮은 우선순위 지정을 해결합니다. 이미 HTML에 있는 많은 LCP 이미지의 경우 fetchpriority만으로 충분할 수 있습니다. 이것들이 어떻게 상호 작용하는지에 대한 전체 가이드는 리소스 우선순위 지정에 대한 기사를 참조하세요.

LCP 모범 사례

LCP 이미지의 경우 최적의 전략은 이 둘을 함께 사용하는 것입니다. 첫째, <img> 태그를 HTML 앞부분에 배치하거나 preload를 사용하여 조기 발견을 보장합니다. 둘째, <img> 태그(및 사용하는 경우 preload 링크)에 fetchpriority="high"를 직접 추가합니다. 이 조합은 리소스가 조기에 발견될 뿐만 아니라 스타일시트나 글꼴과 같은 다른 리소스와의 네트워크 대역폭 경쟁에서 승리할 수 있도록 가능한 가장 높은 우선순위를 부여하도록 보장합니다.

예시:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

fetchpriority="low"를 사용해야 하는 경우

fetchpriority 속성은 단순히 우선순위를 높이기 위한 것만이 아닙니다. fetchpriority="low"를 사용하여 LCP 이미지와 대역폭을 놓고 경쟁하는 비필수 리소스의 우선순위를 낮출 수도 있습니다. 일반적인 대상으로는 LCP 요소가 아닌 스크롤 위 이미지(헤더의 작은 아이콘이나 아바타 등), 그리고 필요하긴 하지만 시급하지 않은 미리 로드된 리소스가 있습니다. 이러한 경쟁 리소스의 우선순위를 명시적으로 낮춤으로써 LCP 이미지를 위한 더 많은 대역폭 여유 공간을 확보할 수 있습니다.

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

입증된 효과

Google Flights와 관련된 사례 연구에서 LCP background-image에 fetchpriority="high"를 추가하자 LCP 시간이 2.6초에서 1.9초로 단축되어 700ms가 향상되었습니다.

타사 연결 최적화: preconnect 및 dns-prefetch

문제

LCP 리소스가 이미지 CDN 또는 Google Fonts와 같은 글꼴 공급자와 같은 타사 도메인에서 호스팅되는 경우 브라우저는 해당 도메인에 대한 새로운 네트워크 연결을 설정해야 합니다. 이 과정에는 DNS 조회, TCP 핸드셰이크, TLS 협상이 포함되며, 이 모든 것이 리소스의 첫 번째 바이트를 다운로드하기 전에 완료되어야 합니다. 이 연결 설정 시간은 교차 출처(cross-origin) 자산의 리소스 로드 지연에 직접적인 원인이 됩니다.

해결책

• preconnect: 이 힌트는 브라우저가 지정된 타사 출처에 대한 전체 연결 설정(DNS, TCP 및 TLS)을 백그라운드에서 미리 수행하도록 지시합니다. 리소스가 실제로 요청될 때 연결이 이미 워밍업되어 설정 지연을 제거합니다. 이것은 매우 효과적이며 LCP 리소스를 제공하는 가장 중요한 한두 개의 타사 도메인에 권장됩니다.
• dns-prefetch: 이것은 도메인에 대한 DNS 조회만 수행하는 더 가벼운 힌트입니다. preconnect보다 절약되는 시간은 적지만 브라우저 지원 범위가 넓으며 fallback으로 또는 덜 중요한 타사 도메인에 유용합니다.

구현 모범 사례

최대한의 호환성을 보장하려면 두 가지 힌트를 모두 제공하세요. 브라우저는 지원되는 경우 preconnect를 사용하고 그렇지 않은 경우 dns-prefetch로 fallback합니다. crossorigin 속성은 글꼴과 같이 CORS를 사용하여 페치되는 리소스에 필수적입니다.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

표: LCP 최적화를 위한 리소스 힌트 비교

오용을 방지하고 이러한 강력한 힌트들의 고유한 역할을 명확히 하기 위해 다음 표에서는 비교 요약을 제공합니다.

총체적이고 미래지향적인 전략

리소스 힌트를 넘어 광범위한 아키텍처 결정은 리소스 로드 지연을 훨씬 더 줄일 수 있습니다.

최신 CDN의 역할

콘텐츠 전송 네트워크(CDN)는 특히 LCP 리소스의 리소스 로드 지연을 간접적이지만 크게 줄여주는 웹 성능의 핵심 기술입니다.

• 연결 오버헤드 감소: 글로벌 서버 네트워크 전체에 자산을 분산시킴으로써 CDN은 지리적으로 사용자와 더 가까운 곳에 콘텐츠를 배치합니다. 이는 본질적으로 연결 설정 시간의 구성 요소인 DNS 조회, TCP 핸드셰이크 및 TLS 협상에 필요한 왕복 시간(RTT)을 줄여줍니다. CDN에서 호스팅되는 LCP 이미지의 경우 이는 로드 지연을 직접적으로 감소시킵니다.
• 이미지 CDN: 특화된 이미지 CDN은 이중의 이점을 제공합니다. 표준 CDN의 근접성 이점을 제공하는 동시에, 실시간 이미지 크기 조정, 압축, AVIF 및 WebP와 같은 최신 형식으로의 변환 등 리소스 로드 시간을 줄여주는 많은 복잡한 최적화를 자동화합니다.
• 고급 프로토콜: 현대의 많은 CDN은 TCP 대신 QUIC를 사용하는 HTTP/3를 사용합니다. HTTP/3는 연결 설정 시간을 줄이고 HOLB(head-of-line blocking)를 완화하여 전반적으로 더 빠르고 효율적인 리소스 전송을 이끌어냅니다.

Speculation Rules를 사용하여 지연 완전히 제거

Speculation Rules API는 후속 탐색에 대한 LCP 지연을 완전히 제거할 수 있습니다.

메커니즘

이 API를 통해 개발자는 사용자가 다음에 이동할 가능성이 있는 URL을 브라우저에 선언적으로 알릴 수 있습니다. 이러한 규칙에 따라 브라우저는 사용자가 링크를 클릭하기도 전에 숨겨진 백그라운드 탭에서 대상 페이지를 미리 렌더링(prerender)하도록 선택할 수 있습니다.

LCP에 미치는 영향

사용자가 미리 렌더링된 페이지의 링크를 클릭하면 탐색이 거의 즉각적으로 이루어집니다. 페이지는 이미 완전히 로드되어 백그라운드에서 렌더링되었습니다. 이 탐색의 경우 TTFB, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연이 사용자 관점에서 효과적으로 0에 가깝게 줄어듭니다.

활용 사례 예시

전자상거래 카테고리 페이지에서 speculation rules를 사용하여 목록의 처음 몇 개 항목에 대한 제품 상세 페이지를 미리 렌더링할 수 있습니다. 사용자가 이 제품들 중 하나를 클릭하면 페이지가 즉시 나타납니다.

사례 연구 종합: 이론에서 실무까지

이러한 최적화는 측정 가능한 실제 효과를 갖습니다.

• 사례 1: 프리로딩의 놀라운 효과: 높은 로드 지연을 가진 페이지에 대해 DebugBear가 수행한 실험은 극적인 예를 제공합니다. LCP 이미지가 요청 체인에 숨겨져 있어 리소스 로드 지연이 총 LCP 시간의 무려 75%를 차지했습니다. 이미지를 조기에 발견할 수 있도록 단일 <link rel="preload"> 힌트를 구현함으로써 리소스 로드 지연이 LCP 시간의 단 2%로 단축되었습니다. 이는 단순한 아키텍처 수정이 얼마나 거대한 성능 병목 현상을 해결할 수 있는지 보여줍니다.
• 사례 2: 실제 loading="lazy" 안티 패턴: Stack Overflow의 한 개발자는 빠른 네트워크에도 불구하고 데스크톱 LCP에 1,430ms라는 당혹스러운 로드 지연이 발생한다고 보고했습니다. 그 원인은 src 속성을 투명한 자리표시자 SVG로 대체하여 LCP 이미지에 지연 로딩을 잘못 적용하고 있던 이미지 최적화 플러그인으로 추적되었습니다. 확실한 해결책은 LCP 요소에 대해 이 동작을 비활성화하여 즉시(eagerly) 발견되고 로드될 수 있도록 하는 것이었습니다. 이는 타사 도구가 어떻게 의도치 않게 심각한 로드 지연을 유발할 수 있는지 보여줍니다.
• 사례 3: fetchpriority 성능 향상: Google Flights 사례 연구는 명시적인 우선순위 지정의 효과에 대한 명확한 증거를 제공합니다. 페이지의 LCP background-image에 fetchpriority="high"를 단순히 추가하는 것만으로 LCP 점수가 2.6초에서 1.9초로 단축되어 700ms 향상되었습니다. 이는 리소스를 발견할 수 있는 경우에도 브라우저에 높은 중요성을 신호하는 것이 네트워크 대역폭 경쟁에서 이기는 중요한 단계임을 증명합니다.

Chrome DevTools에서의 네트워크 검사(Network Inspection): Ctrl + Shift + I 단축키를 사용하여 Chrome의 개발자 도구를 연 다음 "Network" 탭을 선택하고 페이지를 새로 고칩니다. 로드 순서를 살펴보세요. LCP 리소스는 다운로드를 위해 대기열에 추가된 첫 번째 항목 중 하나여야 합니다. 다른 요소에 비해 뒤처진다면 리소스 로드 지연 문제가 있는 것입니다. 아래는 리소스 로드 지연이 최적화되지 않은 사이트의 예입니다.

Real User Monitoring (RUM) 데이터 사용: Real User Monitoring 도구는 종종 LCP 어트리뷰션 데이터를 기록합니다. RUM을 사용하면 (시간 경과에 따라 또는 페이지별로) LCP 하위 부분의 분석을 시각화할 수 있으므로 전체 사이트 또는 페이지별로 LCP 요소에 대한 로드 지연 상황을 명확하게 파악할 수 있습니다. 아래 예시는 해당 로드 지연과 함께 글로벌 LCP 분석을 보여줍니다.

로드 지연 개선 방법

리소스 로드 지연은 리소스의 다운로드 순서와 타이밍이 최적이지 않을 때 발생합니다. 이를 수정하는 두 가지 직접적인 방법이 있습니다. 본질적으로 LCP 리소스의 우선순위를 높이거나 비 LCP 리소스의 우선순위를 낮추는 것입니다. 몇 가지 일반적인 패턴을 살펴보겠습니다.

LCP 팁: 프리로드 스캐너 이해하기: 최신 브라우저는 HTML을 빠르게 스캔하여 리소스를 다운로드 대기열에 추가하는 프리로드 스캐너라는 메커니즘을 사용합니다. 리소스를 프리로드 스캐너로 대기열에 넣을 수 없으면 더 느린 DOM 파서를 기다려야 하므로 지연이 발생합니다. 프리로드 스캐너가 LCP 리소스를 검색할 수 있도록 보장하면 로드 지연을 줄이는 데 큰 차이를 만들 수 있습니다.

1. HTML 구조 최적화

브라우저(또는 프리로드 스캐너)는 HTML을 위에서 아래로 처리하여 나타나는 순서대로 리소스를 대기열에 추가합니다. 이는 LCP 리소스가 HTML에서 높게 나타날수록 더 빨리 대기열에 등록됨을 의미합니다. 이를 최적화하려면 HTML 상단에서 불필요한 리소스를 제거하거나 지연시키세요.

• 중요하지 않거나 숨겨진 이미지 지연 로드: 때로는 이미지(예: 사이트의 특정 언어 버전에 대한 플래그나 메뉴의 이미지)가 사이트 HTML의 맨 위에서 발견됩니다. 이러한 이미지는 LCP 요소만큼 중요하지 않습니다. 이러한 이미지를 지연 로드(lazy-load)하면 프리로드 스캐너가 이미지를 건너뛰고 로드 프로세스 중 조금 늦게 대기열에 추가합니다.
• 중요하지 않은 스크립트를 페이지 하단으로 이동: 초기 로드에 전혀 중요하지 않은 스크립트를 페이지 하단으로 이동하여 중요한 리소스를 지연시키지 않도록 하세요. 예를 들어 채팅 위젯이 있습니다. 인터넷 역사상 페이지가 보이기도 전에 채팅해야 했던 사람은 아무도 없습니다!

2. Background Image 피하기

Background image는 프리로드 스캐너에 보이지 않으므로 항상 훨씬 느린 DOM 파서에 의해 대기열에 추가됩니다. 이러한 지연을 피하려면 대신 일반 <img> 태그를 사용하고 CSS 속성 object-fit: cover를 결합하여 background image의 모양을 모방하세요. 이렇게 하면 프리로드 스캐너가 즉시 이미지를 감지하고 대기열에 넣을 수 있습니다.

3. Fetch Priority 사용

LCP 요소에 fetchpriority="high" 속성을 추가하여 처음부터 이 리소스의 우선순위를 높여야 한다는 힌트를 브라우저에 제공하세요. 보통 이미지는 기본적으로 낮음 또는 중간 우선순위로 로드됩니다. 레이아웃 단계에서 브라우저는 화면에 보이는 요소를 높은 우선순위로 업그레이드합니다. fetchpriority="high"를 설정하면 다운로드가 즉시 높은 우선순위로 시작되어 더 빠른 LCP를 보장합니다.

Fetchpriority는 요소의 상대적인 우선순위를 설정하기 때문에(이 경우 이미지가 다른 이미지보다 상대적으로 더 중요함) 프리로딩보다 덜 방해적이고(그리고 덜 효과적)이지만, 예를 들어 스타일시트나 비차단 스크립트보다 더 중요하게 만들지는 않습니다.

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. 프리로딩(Preloading) 구현

프리로딩은 프리로드 스캐너가 파일을 대기열에 추가하는 순서를 변경합니다. 페이지의 head에 <link rel="preload"> 태그를 배치하여 브라우저에 LCP 이미지와 같은 중요한 리소스를 가능한 한 빨리 페치하도록 지시하세요. 프리로드를 사용하여 나중에 HTML에서 참조되는(따라서 나중에 대기열에 추가되는) 리소스를 미리 로드하거나 심지어 HTML에서 아직 참조되지 않은 리소스(일부 슬라이더의 경우처럼)를 미리 로드할 수도 있습니다. 최대의 효과를 얻으려면 프리로드를 스타일시트 뒤, 스크립트 앞 페이지 헤드에 배치하는 것이 좋습니다.

<link rel="preload" as="image" href="hero-image.jpg">

5. 스타일 최적화

스타일시트는 일반적으로 LCP 리소스보다 먼저 대기열에 추가되며 그만한 이유가 있습니다. 스타일시트 없이는 브라우저가 페이지가 어떻게 보일지 알 수 없으며 렌더링 단계를 시작할 수 없습니다. 그러나 과도한 CSS 크기와 너무 많은 수의 스타일시트는 초기 대역폭을 확보하기 위해 LCP 리소스와 경쟁하게 됩니다.

6. 효율적인 지연 로딩(Lazy-Loading) 구현

loading 속성은 양날의 검이 될 수 있습니다. LCP 리소스에는 loading="eager"를 사용하고(또는 "eager"가 브라우저 기본값이므로 단순히 속성을 생략), 화면 밖의 이미지에는 loading="lazy"를 적용하세요.

• LCP 요소를 즉시 로드(Eager Load): LCP 요소가 지연 로드되면 프리로드 스캐너에 의해 대기열에 추가되지 않고 훨씬 늦게 로드되어 성능에 부정적인 영향을 미칩니다.
• 뷰포트 이미지 지연 로드: 화면에 보이는 뷰포트에 있지만 LCP 리소스가 아닌 이미지의 경우 loading="lazy"를 사용하여 약간 늦게 다운로드 대기열에 넣습니다. 이는 LCP 리소스와의 대역폭 경쟁을 줄여줍니다.
• 화면 밖 이미지 지연 로딩 피하기: 보이는 뷰포트에 없는 이미지는 애초에 다운로드를 트리거하지 않으므로 대역폭 경쟁을 완전히 제거합니다.

7. 브라우저 캐싱

브라우저 캐싱을 사용하면 사용자의 기기에 이미 로컬로 저장된 리소스에 대한 네트워크 요청을 건너뛸 수 있습니다. 첫 번째 페이지 뷰의 속도를 높이지는 않지만 후속 페이지 뷰 및 재방문 사용자의 로드 시간을 개선합니다. 브라우저 캐싱이 리소스 로드 지연에 어떻게 도움이 되는지 다음과 같습니다.

• 경쟁 리소스 캐시: LCP 리소스 자체를 캐싱하는 것도 좋은 전략이지만, 브라우저 캐싱은 스크립트, 스타일시트, 이미지와 같이 LCP 리소스와 경쟁하거나 지연시킬 수 있는 네트워크 리소스를 저장함으로써 LCP 리소스 로드 지연을 개선합니다.
• 서버 부하 감소: 캐싱은 서버로 전송되는 요청 수를 줄여주어 대역폭을 확보하고 서버 CPU 주기를 줄임으로써 다른 리소스의 성능을 향상시킬 수 있습니다.

8. Speculation Rules 사용

Speculation Rules를 사용하면 브라우저가 예측된 사용자 탐색을 기반으로 웹 페이지를 prefetch(미리 가져오기)하거나 prerender(미리 렌더링)할 수 있습니다. Prefetching은 LCP의 Time to First Byte 하위 부분을 효과적으로 제거하며 리소스 로드 지연에 영향을 미치지 않습니다. Prerendering은 숨겨진 탭에서 다음 페이지를 렌더링하고 모든 페이지 리소스를 다운로드합니다. 이 미리 렌더링된 페이지의 LCP 분석 예제에 나와 있듯이 LCP 요소에 대한 모든 로드 지연을 제거합니다.

9. 클라이언트 측 렌더링(Client-Side Rendering) 피하기

다음 단계: 지속적인 LCP 최적화

리소스 로드 지연은 4가지 LCP 단계 중 하나입니다. 발견 지연을 최소화했다면 다음 가이드를 계속 살펴보세요.

• LCP 문제 해결 및 식별: 모든 LCP 문제를 찾고 해결하기 위한 완전한 진단 방법론입니다.
• LCP 이미지 최적화: 이미지 형식 선택, 반응형 이미지, 프리로딩 및 일반적인 이미지 실수.
• 리소스 로드 시간(Resource Load Duration): 브라우저가 리소스를 발견한 후 압축, 최신 형식 및 CDN 최적화를 통해 다운로드에 걸리는 시간을 줄입니다.
• 요소 렌더링 지연(Element Render Delay): 리소스가 다운로드된 후 Main Thread를 정리하여 브라우저가 리소스를 즉시 그릴 수 있도록 보장합니다.