LCP 리소스 로드 시간을 최적화하세요.

이 가이드는 Core Web Vitals 리소스 센터의 Largest Contentful Paint (LCP) 섹션 일부입니다. 리소스 로드 시간(Resource Load Duration)은 4가지 연속된 LCP 단계 중 세 번째 단계로, 네트워크를 통해 LCP 리소스를 다운로드하는 데 걸리는 시간을 측정합니다. 보통 리소스 로드 지연(Resource Load Delay)이 LCP 시간의 더 큰 비중을 차지하지만, 좋은 LCP 점수를 얻으려면 다운로드 시간 최적화는 필수적입니다.

LCP 리소스 로드 시간 최적화

Largest Contentful Paint (LCP)는 온라인 사용자 경험을 측정하는 세 가지 Core Web Vitals 성능 지표 중 하나입니다. LCP는 가장 큰 콘텐츠 요소(이미지, 비디오 또는 텍스트 블록)가 viewport에 표시되는 데 걸리는 시간을 기록합니다. 리소스 로드 시간(Resource Load Duration)은 LCP 요소의 네트워크 리소스를 가져오는 데 소비한 시간을 나타내는 LCP의 하위 단계입니다.

LCP에서 리소스 로드 시간이란 무엇인가?

종종 로드 시간으로 불리는 리소스 로드 시간은 브라우저가 최종적으로 LCP 요소가 될 네트워크 리소스(예: 이미지)를 다운로드하는 데 필요한 시간을 말합니다. 이미지와 비디오의 경우 이 시간은 이미지 다운로드가 시작된 시점부터 브라우저가 다운로드를 완료한 시점까지입니다. 텍스트 기반 LCP 요소의 로드 시간은 보통 0입니다. 구글의 LCP 최적화 가이드는 LCP를 4개의 순차적인 하위 단계로 나누며, 리소스 로드 시간은 실제로 리소스 바이트를 다운로드하는 데 소비한 시간입니다.

리소스 로드 시간은 브라우저가 LCP 리소스 다운로드를 시작한 순간부터 다운로드를 완료할 때까지 측정됩니다. 리소스 로드 시간을 결정하는 4가지 주요 요인은 다음과 같습니다.

• 파일 크기: 파일이 크면 다운로드 시간이 길어집니다.
• 네트워크 속도: 연결 속도가 느리면 당연히 로드 시간이 늘어납니다.
• 서버 응답성: 서버 응답이 지연되면 리소스를 가져오는 속도가 느려집니다.
• 동시 다운로드: 동시에 다운로드되는 리소스는 대역폭을 두고 경쟁하므로 로드 시간이 늘어날 수 있습니다.

리소스 로드 시간 측정 방법

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

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

전문가 팁: 큰 요청 행(large request rows)을 활성화하면 LCP 지연, 전송된 크기, 실제 크기 등 추가 세부 정보를 볼 수 있습니다.

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

RUM 도구는 종종 LCP 기여(attribution) 데이터를 기록합니다. Largest Contentful Paint의 기여 데이터에는 리소스 로드 시간 정보가 포함됩니다. 이 데이터를 통해 시간 경과 또는 페이지별 로드 시간 추세를 차트로 만들고, 속도를 저하시키는 페이지나 요소를 파악할 수 있습니다.

단계별 가이드: 정밀한 lab 측정을 원한다면 Performance 패널에서 트레이스를 기록하세요. LCP 세부 분석 인사이트에 다른 세 개의 하위 단계와 함께 리소스 로드 시간이 표시됩니다. 전체 단계: Chrome DevTools Performance 패널로 LCP 진단하기.

LCP 로드 시간 개선 방법

리소스가 너무 크거나 비효율적인 네트워크 경로로 전송될 때 리소스 로드 시간 문제가 발생합니다. 이 문제를 해결하는 두 가지 주요 접근 방식은 데이터 크기 줄이기와 데이터 전송 최적화입니다.

1. 파일 크기 최적화

파일 크기를 최적화하면 네트워크로 전송할 바이트 수가 줄어듭니다. 데이터가 적으면 다운로드 시간이 짧아집니다. 이미지 최적화에 대한 전체 가이드는 이미지 최적화 방법을 참조하세요.

최신 이미지 포맷 사용

AVIF와 WebP는 이미지 압축에 가장 좋은 옵션입니다. AVIF는 눈에 띄는 화질 저하 없이 복잡한 사진에서 WebP보다 최대 50% 더 작게 압축됩니다. WebP는 브라우저 지원이 더 폭넓고 단순한 이미지에 잘 작동합니다. 2025 Web Almanac에 따르면 현재 이미지 요청의 40% 이상에서 WebP가 사용되며, AVIF 채택률은 전년 대비 두 배로 증가했지만 여전히 10% 미만에 머물고 있습니다.

올바른 품질 설정 선택

WebP 및 AVIF 같은 최신 이미지 포맷은 시각적 품질 저하가 눈에 띄기 전까지 품질을 크게 낮출 수 있습니다. 일반적으로 WebP는 75~85, AVIF는 60~75의 품질 설정이면 일반적인 보기 거리에서 원본과 동일하게 보이면서 파일 크기는 극히 일부에 불과합니다. 최적의 품질은 콘텐츠 유형(사진, 일러스트, 텍스트가 많은 이미지)에 따라 다르므로 항상 실제 이미지로 테스트하세요.

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

빌드 타임 이미지 최적화를 위한 sharp 라이브러리는 Node.js 생태계에서 가장 빠르고 널리 쓰이는 도구 중 하나입니다. 다음 예시는 최적화된 품질 설정으로 이미지를 WebP와 AVIF 포맷으로 변환하고 압축하는 방법을 보여줍니다.

const sharp = require('sharp');

// 최적화된 품질로 WebP 변환
await sharp('input.jpg')
  .resize(1200)  // 필요한 최대 너비로 크기 조절
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// 최적화된 품질로 AVIF 변환
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// 반응형 이미지를 위한 여러 크기 생성
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> 요소에 필요한 모든 변형을 생성합니다. 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% 이상 줄여줍니다.
• 폰트 변형 제한: 각 굵기와 스타일(regular, bold, italic)은 별도의 파일 다운로드입니다. 디자인에 실제로 사용하는 굵기만 포함하세요.

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)의 경우 서버 측 압축이 필수적입니다. 구글이 개발한 Brotli는 비슷한 압축 해제 속도를 유지하면서도 압축률에서 지속적으로 Gzip을 능가합니다. 다음 비교표에서 차이를 확인하세요.

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

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

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

• HTTP/2는 멀티플렉싱을 도입하여 단일 TCP 연결에서 여러 요청과 응답을 동시에 보낼 수 있게 해줍니다. 이로써 느린 리소스 하나가 다른 모든 리소스를 지연시키는 HTTP/1.1의 head-of-line blocking 문제를 해결합니다. 또한 HTTP/2는 헤더 압축(HPACK)과 서버 푸시를 지원합니다.
• 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'라고 표시됩니다.

콘텐츠 전송 네트워크(CDN)

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

지리적 근접성 외에도 최신 CDN은 로드 시간을 줄여주는 몇 가지 성능상 이점을 제공합니다.

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

특화된 이미지 CDN은 포맷 변환, 크기 조절, 압축과 같은 자동 실시간 최적화를 제공하여 이를 한 단계 더 발전시킵니다.

리소스 직접 호스팅(Self-Hosting)

중요하고 초기에 로드되는 네트워크 리소스는 항상 원본 서버에서 직접 호스팅해야 합니다. 직접 호스팅하면 서드파티 서버에 연결할 필요가 없어지므로 추가 DNS 조회, SSL 협상 및 연결 설정에 따른 상당한 지연을 피할 수 있습니다. 직접 호스팅은 이미 열려 있는 단일 연결 재사용을 보장하며 별도의 연결 설정 오버헤드를 줄여줍니다. 또한 리소스를 직접 호스팅하면 압축 및 캐시 정책을 완벽하게 제어할 수 있습니다.

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

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

중요한 리소스 우선순위 지정

히어로 이미지나 above-the-fold(스크롤 전 보이는 영역) CSS 같은 필수 리소스에 fetchpriority="high" 플래그를 지정하세요. 이렇게 하면 브라우저에 이 에셋을 먼저 다운로드하라는 신호를 주어, 즉시 로드할 필요 없는 스크립트, 위젯, 서드파티 요소에 밀려 다운로드가 지연되는 것을 막습니다. 이러한 중요 리소스의 우선순위를 높이면 사용자가 가장 중요하게 여기는 콘텐츠의 로드 시간이 줄어듭니다. (지연 발견 문제를 해결하기 위한) preload와 (네트워크 경합을 해결하기 위한) fetchpriority="high" 조합은 LCP 리소스를 가장 빠르고 신속하게 가져오는 가장 강력한 기법입니다.

<!-- 초기 HTML에 보이는 LCP 이미지의 경우 -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- 발견(discovery) 속도를 높이려면  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

네트워크 경합 줄이기

비필수 에셋을 연기하거나 lazy loading하여 초기 다운로드를 간소화하세요. 당장 보이지 않는 이미지와 비디오는 물론 백그라운드나 보조 요소의 로드를 미루세요. 화면 밖에 있는 미디어에 loading="lazy"를 사용하는 것이 좋은 출발점입니다. 기타 불필요한 스크립트와 에셋을 추가로 연기하면 대역폭이 확보되고 중요 리소스와의 경쟁이 줄어들어 페이지의 메인 콘텐츠를 빠르고 신속하게 표시할 수 있습니다. LCP 이미지에는 절대 loading="lazy"를 적용하지 마세요. 점수를 떨어뜨리는 치명적인 안티패턴(anti-pattern)입니다.

4. Speculation Rules 설정

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

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

리소스 로드 시간은 4개의 LCP 단계 중 하나일 뿐입니다. 다운로드 시간을 최적화한 후 다른 LCP 단계를 계속 진행하세요.

• LCP 문제 식별 및 수정: field data와 lab 도구를 사용하여 모든 LCP 문제를 찾고 수정하는 완벽한 진단 방법론입니다.
• LCP 이미지 최적화: 이미지 포맷 선택, 반응형 이미지, preloading, 그리고 흔한 이미지 최적화 실수들입니다.
• 리소스 로드 지연(Resource Load Delay): 브라우저가 가능한 한 빨리 LCP 리소스를 발견하도록 하세요. 이는 보통 로드 시간 자체보다 더 큰 병목 구간입니다.
• 요소 렌더링 지연(Element Render Delay): 리소스 다운로드 후 main thread를 비워 브라우저가 즉시 페인트할 수 있도록 하세요.