LCP 리소스 로드 시간 최적화

이 가이드는 Core Web Vitals 리소스 센터의 Largest Contentful Paint (LCP) 섹션에 속한 글입니다. 리소스 로드 시간은 LCP의 순차적인 4개 단계 중 세 번째 단계로, 네트워크를 통해 LCP 리소스를 다운로드하는 데 걸리는 시간을 측정합니다. LCP 시간에서는 리소스 로드 지연이 더 큰 비중을 차지하는 경우가 많지만, 좋은 LCP 점수를 얻으려면 다운로드 시간 최적화 역시 필수적입니다.

LCP 리소스 로드 시간 최적화

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

LCP에서 리소스 로드 시간이란?

흔히 로드 시간(Load Duration)이라고도 부르는 리소스 로드 시간은 브라우저가 향후 LCP 요소가 될 네트워크 리소스(예: 이미지)를 다운로드하는 데 걸리는 시간입니다. 이미지와 동영상의 경우, 이 시간은 다운로드가 시작된 시점부터 브라우저가 다운로드를 완료할 때까지의 구간입니다. 텍스트 기반 LCP 요소의 경우 로드 시간은 일반적으로 0입니다. Google의 LCP 최적화 가이드는 LCP를 4개의 순차적인 하위 단계로 나누며, 리소스 로드 시간은 리소스 바이트를 실제로 다운로드하는 데 소요된 시간을 의미합니다.

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

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

리소스 로드 시간 확인 방법

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

Chrome DevTools 네트워크 검사: Ctrl + Shift + I 단축키로 Chrome 개발자 도구를 연 다음, 'Network' 탭을 선택하고 페이지를 새로고침하십시오. 네트워크 요청 목록에서 LCP 요소를 찾습니다(LCP 요소를 확인하려면 Core Web Vitals Visualizer를 사용하십시오). 네트워크 인스펙터에서 해당 리소스를 다운로드하는 데 걸린 시간을 확인할 수 있습니다.

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

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

RUM 도구는 대개 LCP attribution 데이터를 기록합니다. Largest Contentful Paint의 attribution 데이터에는 리소스 로드 시간에 관한 정보가 포함되어 있습니다. 이 데이터를 활용하면 시간 경과에 따른 로드 시간 추이나 페이지별 추세를 차트로 확인하고, 속도를 저하시키는 페이지나 요소를 찾아낼 수 있습니다.

단계별 가이드: 정밀한 lab 측정을 원한다면 Performance 패널에서 트레이스를 기록하십시오. LCP 세부 분석(breakdown) 인사이트에서 다른 3가지 하위 단계와 함께 리소스 로드 시간을 확인할 수 있습니다. 전체 가이드: 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 파일에 비하면 훨씬 작습니다.
• 폰트 서브셋(Subset) 생성: 사이트에서 라틴 문자만 사용한다면, 사용하지 않는 문자 세트(키릴 자모, 그리스 문자, CJK)를 제거하는 서브셋 작업을 진행하십시오. glyphhanger나 pyftsubset 같은 도구로 자동화할 수 있으며, 폰트 파일 크기를 50% 이상 줄이는 경우가 많습니다.
• 폰트 변형 최소화: 각 두께(weight)와 스타일(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)의 경우 서버 측 압축이 필수적입니다. Google이 개발한 Brotli는 동등한 압축 해제 속도를 유지하면서도 압축률 면에서 일관되게 Gzip을 능가합니다. 두 방식의 차이는 다음과 같습니다:

가장 이상적인 구성은 빌드 과정에서 높은 압축 레벨(예: 레벨 11)의 Brotli로 정적 에셋을 사전 압축하고, Brotli를 지원하지 않는 클라이언트를 위해 Gzip을 fallback으로 사용하는 것입니다. 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을 도입하여 이를 한 단계 더 발전시켰습니다. 단 하나의 패킷 손실로 모든 스트림이 멈추던 TCP 레벨의 head-of-line blocking을 제거하고, 0-RTT(재방문자를 위한 Zero Round Trip Time 재개)를 통해 연결 수립 속도를 높였으며, 패킷 손실을 훨씬 매끄럽게 처리합니다. 이러한 개선 사항은 주로 Time to First Byte를 단축하지만, 리소스 로드 시간 역시 줄여줍니다.

HTTP/3 활성화 여부를 확인하려면 Ctrl + Shift + I 단축키로 네트워크를 점검하십시오. Network 탭을 선택하고 네트워크 컬럼 헤더를 마우스 우클릭한 뒤 'Protocol' 항목이 활성화되어 있는지 확인하십시오. 페이지를 새로고침하고 프로토콜을 확인하면 됩니다. HTTP/3가 적용되어 있다면 프로토콜에 'h3'라고 표시됩니다.

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

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

물리적 거리 단축 외에도 최신 CDN은 로드 시간을 줄여주는 여러 성능상의 이점을 제공합니다:

• 자동 이미지 최적화: 많은 CDN이 실시간으로 이미지를 압축하고, 크기를 조정하며, 포맷을 변환합니다. 예를 들어 Cloudflare Polish, Imgix, Cloudinary는 브라우저의 Accept 헤더를 기반으로 WebP나 AVIF를 자동으로 제공합니다.
• 엣지 캐싱: 정적 리소스가 전 세계 엣지 노드에 캐싱되므로 원본(origin) 서버에서 직접 가져올 필요가 완전히 사라집니다.
• 프로토콜 최적화: CDN은 서버 설정을 직접 변경하지 않고도 HTTP/2, HTTP/3 및 Brotli 압축을 기본적으로 활성화합니다.
• 연결 재사용: CDN이 단일 도메인에서 모든 리소스를 제공하므로 브라우저가 하나의 연결을 재사용합니다. 따라서 여러 차례의 DNS 조회와 TLS 핸드셰이크로 인한 오버헤드가 제거됩니다.

이미지 특화 CDN(Image CDN)은 포맷 변환, 크기 조정, 압축과 같은 실시간 자동 최적화를 제공하여 이러한 이점을 한층 더 극대화합니다.

리소스 자체 호스팅

초기에 로드되어야 하는 중요한 네트워크 리소스는 기본적으로 항상 오리진(origin) 서버에서 직접 호스팅해야 합니다. 자체 호스팅을 하면 서드파티 서버에 연결할 필요가 없으므로 추가 DNS 조회, SSL 협상, 연결 설정으로 인한 심각한 지연을 방지할 수 있습니다. 또한 이미 열려 있는 단일 연결을 재사용할 수 있어 별도 연결을 수립하는 오버헤드가 줄어듭니다. 자체 호스팅 리소스는 압축 및 캐시 정책을 온전히 직접 제어할 수 있다는 장점도 있습니다.

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

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

핵심 리소스 우선순위 지정

히어로 이미지나 above-the-fold CSS와 같은 핵심 리소스에는 fetchpriority="high"를 지정하십시오. 이렇게 하면 브라우저에 해당 에셋을 먼저 다운로드하라는 신호를 보내어 즉시 로드할 필요가 없는 스크립트, 위젯, 서드파티 요소 때문에 다운로드가 밀리는 현상을 방지합니다. 이러한 핵심 리소스의 우선순위를 높이면 사용자에게 가장 중요한 콘텐츠의 로드 시간이 줄어듭니다. preload(발견 지연 해결용)와 fetchpriority="high"(네트워크 경합 해결용)의 조합은 LCP 리소스를 가능한 한 빠르고 신속하게 가져오는 가장 강력한 방법입니다.

<!-- 초기 HTML에 표시되는 LCP 이미지용 -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- 발견 시점 개선용  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

네트워크 경합 줄이기

중요하지 않은 에셋의 로드를 지연하거나 lazy loading하여 초기 다운로드를 간소화하십시오. 즉시 보이지 않는 이미지나 동영상, 배경 요소 및 보조 요소의 로드는 뒤로 미룹니다. 화면 밖(offscreen) 미디어에 loading="lazy"를 적용하는 것부터 시작할 수 있으며, 중요하지 않은 기타 스크립트와 에셋을 추가로 지연시키면 대역폭이 확보되어 핵심 리소스와의 경쟁을 줄일 수 있습니다. 이를 통해 페이지의 주요 콘텐츠를 빠르게 로드하고 화면에 표시할 수 있습니다. LCP 이미지에는 절대로 loading="lazy"를 적용하지 마십시오. 점수를 떨어뜨리는 치명적인 안티패턴입니다.

4. Speculation Rules 설정

Speculation Rules를 사용하면 브라우저가 사용자의 탐색 경로를 예측하여 웹 페이지를 미리 가져오거나(prefetch) 사전 렌더링(prerender)할 수 있습니다. 프리페치는 LCP의 하위 단계인 Time to First Byte를 효과적으로 제거하지만, 리소스 로드 시간 자체에는 영향을 주지 않습니다. 반면 사전 렌더링은 백그라운드 탭에서 다음 페이지를 렌더링하고 페이지의 모든 리소스를 다운로드합니다. 이 사전 렌더링된 페이지의 LCP 세부 분석(breakdown) 예시에서 볼 수 있듯이, 이 방식을 적용하면 LCP 요소의 로드 시간을 대부분 제거할 수 있습니다.

다음 단계: LCP 최적화 이어가기

리소스 로드 시간은 4가지 LCP 단계 중 하나일 뿐입니다. 다운로드 시간을 최적화했다면 다른 LCP 단계도 이어서 최적화하십시오:

• LCP 문제 진단 및 해결: field data와 lab 도구를 활용하여 모든 LCP 문제를 찾고 해결하는 완전한 진단 방법론입니다.
• LCP 이미지 최적화: 이미지 포맷 선택, 반응형 이미지, preloading, 흔히 저지르는 이미지 최적화 실수 등을 다룹니다.
• 리소스 로드 지연: 브라우저가 LCP 리소스를 가능한 한 일찍 발견하도록 합니다. 이는 로드 시간 자체보다 더 큰 병목이 되는 경우가 많습니다.
• 요소 렌더링 지연: 리소스 다운로드가 끝난 후 main thread를 정리하여 브라우저가 즉시 화면을 렌더링할 수 있도록 합니다.