LCP 리소스 로드 기간 최적화

다운로드부터 디스플레이까지: Largest Contentful Paint의 리소스 로드 기간 부분을 개선하는 방법 알아보기

Arjen Karel - linkedin

Last update: 2026-03-03

이 가이드는 Core Web Vitals 리소스 센터의 Largest Contentful Paint (LCP) 섹션의 일부입니다. 리소스 로드 기간(Resource Load Duration)은 4개의 순차적인 LCP 단계 중 세 번째로, 네트워크를 통해 LCP 리소스를 다운로드하는 데 걸리는 시간을 측정합니다. Resource Load Delay가 LCP 시간에서 더 큰 비중을 차지하는 경우가 많지만, 다운로드 기간을 최적화하는 것은 좋은 LCP 점수를 얻기 위해 여전히 필수적입니다.

LCP 리소스 로드 기간 최적화

Largest Contentful Paint (LCP)는 온라인 user experience를 측정하는 세 가지 Core Web Vitals 성능 메트릭 중 하나입니다. LCP는 가장 큰 콘텐츠 요소(이미지, 비디오 또는 텍스트 블록)가 뷰포트에 표시되는 데 걸리는 시간을 포착합니다. Resource Load Duration은 LCP 요소에 대한 네트워크 리소스를 가져오는 데 소요되는 시간을 나타내는 LCP의 하위 부분입니다.

LCP에서 Resource Load Duration이란 무엇인가요?

흔히 Load Duration이라고 불리는 Resource Load Duration은 브라우저가 결국 LCP 요소가 될 네트워크 리소스(예: 이미지)를 다운로드하는 데 필요한 시간을 의미합니다. 이미지 및 비디오의 경우, 이 기간은 이미지 다운로드가 시작된 시점부터 브라우저가 다운로드를 완료할 때까지입니다. 텍스트 기반 LCP 요소의 경우 로드 기간은 일반적으로 0입니다. Google의 LCP 최적화 가이드는 LCP를 4개의 순차적 하위 부분으로 나누며, Resource Load Duration은 실제로 리소스 바이트를 다운로드하는 데 소요된 시간입니다.

Resource Load Duration은 브라우저가 LCP 리소스 다운로드를 시작한 순간부터 다운로드를 완료할 때까지 측정됩니다. 네 가지 주요 요소가 리소스 로드 기간을 결정합니다:

파일 크기: 파일이 클수록 더 긴 다운로드 시간이 필요합니다.
네트워크 속도: 연결이 느리면 자연스럽게 로드 기간이 늘어납니다.
서버 응답성: 서버 응답 지연은 리소스 가져오기를 느리게 합니다.
동시 다운로드: 동시에 다운로드되는 리소스는 대역폭을 놓고 경쟁하며, 이로 인해 로드 시간이 늘어날 수 있습니다.

Resource Load Duration을 감지하는 방법

리소스 로드 기간을 식별하고 측정하는 효과적인 두 가지 방법이 있습니다:

Chrome DevTools의 네트워크 검사: Ctrl + Shift + I 단축키를 사용하여 Chrome의 개발자 도구를 연 다음, "Network" 탭을 선택하고 페이지를 새로고침하세요. 네트워크 요청에서 LCP 요소를 찾으세요(LCP 요소를 알고 싶다면 Core Web Vitals Visualizer를 시도해 보세요). 네트워크 검사기는 리소스를 다운로드하는 데 걸린 시간을 보여줍니다.

꿀팁: 큰 요청 행(large request rows)을 활성화하여 LCP 지연 시간, 전송된 크기, 실제 크기와 같은 추가 세부 정보를 확인하세요.

Real User Monitoring (RUM) 데이터 사용:

RUM 도구는 종종 LCP 속성(attribution) 데이터를 기록합니다. Largest Contentful Paint에 대한 속성 데이터에는 resource load duration에 대한 정보가 포함됩니다. 이 데이터를 사용하여 시간 경과에 따른 로드 기간 추세 또는 페이지별 로드 기간을 차트로 만들고, 속도를 저하시키는 페이지 또는 요소를 찾아낼 수 있습니다.

LCP 로드 기간 개선 방법

리소스 로드 기간 문제는 리소스가 너무 크거나 최적이 아닌 네트워크 경로를 통해 전달될 때 발생합니다. 이를 해결하기 위한 두 가지 주요 접근 방식은 데이터 크기 줄이기 또는 데이터 전달 최적화입니다.

1. 파일 크기 최적화

파일 크기를 최적화하면 네트워크를 통해 전송할 바이트 수가 줄어듭니다. 데이터가 적다는 것은 다운로드 시간이 줄어든다는 것을 의미합니다. 이미지 최적화에 대한 전체 가이드는 이미지 최적화 방법에 대한 도움말을 참조하세요.

올바른 품질 설정 선택

WebP 및 AVIF와 같은 최신 이미지 포맷은 시각적 저하가 눈에 띄기 전에 상당한 품질 감소를 허용합니다. 일반적으로 WebP의 경우 75~85, AVIF의 경우 60~75 사이의 품질 설정은 일반적인 시청 거리에서 원본과 동일하게 보이지만 파일 크기는 훨씬 작습니다. 최적의 품질은 콘텐츠 유형(사진 vs. 일러스트레이션 vs. 텍스트가 많은 이미지)에 따라 다르므로 항상 특정 이미지로 테스트하세요.

Sharp를 이용한 이미지 압축 자동화

빌드 시간 이미지 최적화를 위해 sharp 라이브러리는 Node.js 생태계에서 가장 빠르고 널리 사용되는 도구 중 하나입니다. 다음 예제는 최적화된 품질 설정으로 이미지를 WebP 및 AVIF 형식으로 변환하고 압축하는 방법을 보여줍니다:

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

이 방식은 최신 형식 지원이 포함된 반응형 <picture> 요소에 필요한 모든 변형(variants)을 생성합니다. WordPress 사이트의 경우 ShortPixel 또는 Imagify와 같은 플러그인이 업로드 시 이 변환을 자동으로 처리합니다.

반응형 이미지

<picture> 요소와 srcset 속성은 화면에 따라 다른 이미지 크기를 제공합니다: 모바일용은 작은 버전, 큰 화면용은 고해상도. 설정 예시는 다음과 같습니다:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Description" width="800" height="450">
</picture>

올바른 이미지 크기

반응형 이미지는 반응형이라고 해서 크기가 올바르다는 것을 의미하지 않으므로 솔루션의 일부일 뿐입니다. 이미지 크기를 디스플레이 크기에 맞추는 것은 제가 자주 보는 가장 흔한 실수 중 하나입니다. 500px 디스플레이 영역에 2000px 너비의 이미지를 제공하면 대역폭이 낭비되고 로드 속도가 눈에 띄게 느려질 수 있습니다.

폰트 파일 최적화

LCP 요소가 커스텀 웹 폰트로 렌더링된 텍스트인 경우, 폰트 파일이 LCP 리소스가 됩니다. 다음과 같이 폰트 로드 기간을 최적화하세요:

WOFF2 포맷 사용: WOFF2는 웹 폰트에 가장 우수한 압축을 제공하며, 일반적으로 WOFF보다 30% 작고 TTF 또는 OTF 파일보다 훨씬 작습니다.
폰트 서브셋 생성: 사이트에서 라틴 문자만 사용하는 경우, 폰트를 서브셋화하여 사용하지 않는 문자 세트(키릴 문자, 그리스어, CJK)를 제거하세요. glyphhanger 또는 pyftsubset과 같은 도구가 이를 자동화하여 폰트 파일 크기를 종종 50% 이상 줄일 수 있습니다.
폰트 변형(variations) 제한: 각 두께와 스타일(일반, 굵게, 기울임꼴)은 별도의 파일 다운로드입니다. 디자인에서 실제로 사용하는 두께만 포함하세요.

2. 네트워크 성능 향상

리소스 크기가 최적화되면 다음 단계는 네트워크 속도를 극대화하거나 심지어 네트워크를 완전히 우회하는 것입니다.

브라우저 캐싱으로 네트워크 요구사항 우회

건너뛴 네트워크 연결보다 더 빠른 네트워크 연결은 없습니다. 브라우저는 로컬 캐시에서 직접 정적 콘텐츠(이미지, 스크립트, 스타일시트)를 제공할 수 있습니다. 브라우저에 올바른 캐싱 지침을 보내도록 서버를 구성하세요.

가장 효과적인 설정은 다음과 같이 Cache-Control 헤더를 보내는 것입니다:

Cache-Control: public, max-age=31536000, immutable

public: 브라우저와 중간 캐시 모두에서 리소스를 캐시할 수 있도록 허용합니다.
max-age=31536000: 리소스가 최신 상태로 간주되는 최대 시간을 1년(31,536,000초)으로 설정합니다.
immutable: 리소스가 시간이 지나도 변경되지 않음을 나타내어 불필요한 재검증 요청을 방지합니다.

이 전략이 안전하게 작동하려면 콘텐츠 해시 파일 이름(예: hero-abc123.webp)을 사용하여 이미지가 변경될 때 파일 이름도 변경되어 캐시가 자동으로 무효화되도록 하세요.

Brotli 대 Gzip 압축

텍스트 기반 리소스(HTML, CSS, JavaScript, SVG)의 경우 서버 측 압축이 필수적입니다. Google에서 개발한 Brotli는 비슷한 압축 해제 속도를 유지하면서 압축률에서 지속적으로 Gzip을 능가합니다. 다음 비교는 그 차이를 보여줍니다:

기능	Gzip	Brotli
일반적인 크기 감소	60-70%	70-80%
압축 속도	더 빠름	더 느림 (높은 레벨에서)
압축 해제 속도	빠름	Gzip과 비슷함
브라우저 지원	보편적	97%+ (모든 최신 브라우저)
용도	동적 콘텐츠, 실시간 압축	정적 자산, 사전 압축된 파일
HTTPS 필요 여부	아니요	예

이상적인 설정은 빌드 프로세스 동안 높은 압축 수준(예: 레벨 11)에서 Brotli로 정적 에셋을 사전 압축하고, Brotli를 지원하지 않는 클라이언트를 위한 fallback으로 Gzip을 사용하는 것입니다. Cloudflare를 포함한 대부분의 CDN은 이를 자동으로 처리합니다. CDN 구성에 대한 자세한 내용은 성능 향상을 위한 Cloudflare 구성 가이드를 참조하세요.

HTTP/2 및 HTTP/3: 최신 프로토콜의 이점

전송 프로토콜은 브라우저가 동시에 여러 리소스를 다운로드할 때 가장 중요합니다.

HTTP/2는 멀티플렉싱(multiplexing)을 도입하여 단일 TCP 연결을 통해 여러 요청과 응답을 동시에 보낼 수 있도록 했습니다. 이는 하나의 느린 리소스가 다른 모든 리소스를 지연시킬 수 있는 HTTP/1.1의 head-of-line blocking 문제를 제거합니다. 또한 HTTP/2는 헤더 압축(HPACK)과 서버 푸시(server push)를 지원합니다.
HTTP/3는 TCP를 UDP 기반 프로토콜인 QUIC로 대체하여 이를 더욱 발전시켰습니다. HTTP/3는 TCP 수준의 head-of-line blocking(단일 손실 패킷이 모든 스트림을 지연시키는 현상)을 제거하고, 0-RTT(재방문자를 위한 Zero Round Trip Time 재개)를 통해 더 빠른 연결 설정을 제공하며, 패킷 손실을 더 유연하게 처리합니다. 이러한 개선 사항은 주로 Time to First Byte 속도를 높이지만, 리소스 로드 기간도 줄여줍니다.

HTTP/3가 활성화되어 있는지 확인하려면, Ctrl+Shift+I 단축키를 눌러 네트워크를 검사하면 됩니다. 네트워크 탭을 선택하고 네트워크 열 헤더를 우클릭한 후 'protocol'이 활성화되어 있는지 확인하세요. 페이지를 새로고침하고 프로토콜을 확인합니다. HTTP/3의 경우 프로토콜에 'h3'라고 표시되어야 합니다.

Content Delivery Networks (CDN)

CDN은 사용자와 더 가까운 위치에서 이미지, CSS 및 JavaScript와 같은 정적 리소스를 캐시하고 제공하는 분산 서버 네트워크입니다. 이는 Resource Load Duration에 직접적인 영향을 미치는 데이터 이동 시간(왕복 시간)을 줄여줍니다.

근접성 외에도 최신 CDN은 로드 기간을 단축하는 여러 가지 성능상 이점을 제공합니다:

자동 이미지 최적화: 많은 CDN은 이미지를 즉석에서 압축, 크기 조정 및 변환할 수 있습니다. 예를 들어, Cloudflare Polish, Imgix 및 Cloudinary는 브라우저의 Accept 헤더를 기반으로 WebP 또는 AVIF를 자동으로 제공할 수 있습니다.
엣지 캐싱(Edge caching): 정적 리소스는 전 세계 엣지 노드에 캐시되어 오리진 서버에서 가져올 필요가 전혀 없습니다.
프로토콜 최적화: CDN은 일반적으로 서버 측 구성 변경 없이 Brotli 압축과 함께 HTTP/2 및 HTTP/3를 기본적으로 활성화합니다.
연결 재사용: CDN이 단일 도메인에서 모든 리소스를 제공하므로 브라우저가 단일 연결을 재사용하여 여러 DNS 조회 및 TLS 핸드셰이크의 오버헤드를 제거합니다.

전문 이미지 CDN은 포맷 변환, 크기 조정, 압축과 같은 실시간 자동 최적화를 제공하여 이를 한 단계 더 발전시킬 수 있습니다.

자체 호스팅 리소스

중요하고 초기에 필요한 네트워크 리소스는 기본적으로 항상 오리진 서버에서 호스팅되어야 합니다. 자체 호스팅은 서드파티 서버에 연결해야 하는 필요성을 회피하며, 추가적인 DNS 조회, SSL 협상 및 연결 설정으로 인한 상당한 지연을 방지할 수 있습니다. 자체 호스팅은 이미 열려 있는 단일 연결의 재사용을 보장하고 별도의 연결을 설정하는 오버헤드를 줄입니다. 자체 호스팅된 리소스는 압축 및 캐시 정책에 대한 완전한 제어도 가능하게 합니다.

3. 리소스 우선순위 최적화

리소스 크기를 줄이고 네트워크를 최적화한 후에는 네트워크 경쟁 문제도 있습니다. 느린 연결 환경에서 브라우저가 여러 리소스를 동시에 요청하면 대역폭을 놓고 경쟁합니다. 리소스 다운로드 일정을 조율하여 이러한 경쟁을 최소화하세요.

주요 리소스 우선순위 지정

히어로 이미지나 스크롤 상단(above-the-fold) CSS와 같은 필수 리소스에는 fetchpriority="high" 플래그를 지정하세요. 이는 브라우저에 해당 자산을 먼저 다운로드하라는 신호를 보내어, 즉시 로드할 필요가 없는 스크립트, 위젯 또는 서드파티 요소에 의해 다운로드가 지연되는 것을 방지합니다. 이러한 중요한 리소스의 우선순위를 지정하면 사용자가 가장 관심을 갖는 콘텐츠의 로드 시간이 줄어듭니다. preload(늦은 발견(late discovery)을 해결하기 위함)와 fetchpriority="high"(네트워크 경합(network contention)을 해결하기 위함)의 조합은 LCP 리소스를 가능한 한 일찍, 가장 빠르게 가져오도록 보장하는 가장 강력한 기술입니다.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

네트워크 경합 줄이기

필수적이지 않은 자산(assets)을 지연시키거나 지연 로딩(lazy-loading)하여 초기 다운로드를 간소화하세요. 배경 또는 보조 요소뿐만 아니라 즉시 보이지 않는 모든 이미지나 비디오의 로딩을 연기하세요. 화면 밖 미디어에 loading="lazy"를 사용하는 것은 좋은 시작점이며, 필수적이지 않은 다른 스크립트와 자산을 추가로 지연시키면 대역폭을 확보하고 중요한 리소스와의 경쟁을 줄여 페이지의 기본 콘텐츠를 빠르게 로드하고 표시할 수 있습니다. LCP 이미지에는 절대 loading="lazy"를 적용하지 마세요. 이는 점수에 악영향을 미치는 중대한 안티 패턴입니다.

4. Speculation Rules 설정

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

다음 단계: LCP 최적화 계속하기

Resource Load Duration은 네 가지 LCP 단계 중 하나일 뿐입니다. 다운로드 시간을 최적화한 후 다른 LCP 단계를 계속 진행하세요:

LCP 문제 수정 및 식별: 필드 데이터 및 실험실 도구를 사용하여 모든 LCP 문제를 찾고 수정하기 위한 완벽한 진단 방법론입니다.
LCP 이미지 최적화: 이미지 포맷 선택, 반응형 이미지, preloading 및 일반적인 이미지 최적화 실수입니다.
Resource Load Delay: 브라우저가 가능한 한 일찍 LCP 리소스를 발견하도록 하세요. 이는 종종 로드 기간 자체보다 더 큰 병목 현상입니다.
Element Render Delay: 리소스가 다운로드된 후, 메인 스레드를 비워 브라우저가 즉시 페인트할 수 있도록 하세요.