Core Web Vitals를 위한 이미지 최적화
"이미지가 Core Web Vitals에 미치는 영향과 최적화 방법을 알아보세요
이미지가 Core Web Vitals에 미치는 영향
2025 Web Almanac에 따르면, 이미지는 데스크톱 페이지의 85%, 모바일 페이지의 76%에서 Largest Contentful Paint를 차지합니다. 따라서 이미지 최적화는 Core Web Vitals를 위해 할 수 있는 가장 영향력 있는 작업입니다. 하지만 이미지는 로딩 속도에만 영향을 미치는 것이 아닙니다. 레이아웃 변동(layout shift)을 일으킬 수 있으며, 이미지가 많은 페이지에서는 상호작용성(interactivity)을 저하시킬 수도 있습니다. 이 가이드에서는 HTML 속성과 프리로딩(preloading)부터 반응형 이미지, 최신 포맷, 페이지의 각 이미지에 적용해야 할 전략까지 모든 측면을 다룹니다.
2026년 2월에 Arjen Karel이 마지막으로 검토함
Table of Contents!
- 이미지가 Core Web Vitals에 미치는 영향
- Core Web Vitals 이해하기
- 이미지는 어떤 Core Web Vitals에 영향을 미칠 수 있나요?
- 단계 1: 속도를 위해 HTML 이미지 요소 최적화하기
- 단계 2: 이미지가 최대한 빨리 다운로드 대기열에 추가되도록 보장하기
- 단계 3: 이미지가 최대한 빨리 다운로드되도록 보장하기
- 단계 4: 레이아웃 변동(layout shift) 제거하기!
- 단계 5: 메인 스레드 보호하기
- 단계 6: 각 이미지에 적합한 전략 선택하기!
- Real User Monitoring으로 영향력 모니터링하기
Core Web Vitals 이해하기
Core Web Vitals는 Google이 랭킹 신호로 사용하는 사용자 중심의 세 가지 지표입니다. Largest Contentful Paint (LCP)는 로딩 속도를 측정하고, Interaction to Next Paint (INP)는 상호작용성을 측정하며, Cumulative Layout Shift (CLS)는 시각적 안정성을 측정합니다. 이미지는 이 세 가지 모두에 영향을 미칠 수 있습니다.
이미지는 어떤 Core Web Vitals에 영향을 미칠 수 있나요?
이미지가 모든 Core Web Vitals에 영향을 미칠 수 있다는 사실에 놀라실 수도 있습니다. 렌더링 중 늦게 다운로드 대기열에 추가되거나 단순히 너무 큰 이미지는 대개 높은 LCP 점수를 초래합니다. 이미지 크기가 설정되지 않거나 로딩 단계에서 변경되면 이미지는 CLS 점수에도 영향을 미칠 수 있습니다. 마지막으로, 이미지 디코딩이 너무 많은 메인 스레드 작업을 차지하면 INP에도 영향을 미칠 수 있습니다. 더 자세히 살펴보겠습니다:
Largest Contentful Paint
Largest Contentful Paint (LCP)는 페이지에서 가장 큰 요소(이미지나 동영상 등)가 사용자에게 표시되는 데 걸리는 시간을 측정합니다. 2025 Web Almanac에 따르면 데스크톱 페이지의 85%, 모바일 페이지의 76%에서 이미지가 LCP 요소입니다. 이미지가 너무 늦게 대기열에 추가되거나 로드하는 데 너무 오래 걸리면 페이지의 LCP 점수가 크게 느려질 수 있습니다.
Cumulative Layout Shift
Cumulative Layout Shift (CLS)는 페이지가 로드될 때 콘텐츠가 얼마나 많이 이동하는지를 측정합니다. 이미지가 적절한 크기로 지정되지 않았거나 페이지가 이미 로드된 후에 삽입되어 다른 요소가 이동하게 되면 레이아웃 변동이 발생할 수 있습니다. 2025 Web Almanac에 따르면 데스크톱 페이지의 65%에는 여전히 명시적 크기가 없는 이미지가 하나 이상 있습니다.
Interaction to Next Paint (INP)
이미지는 사용자가 상호 작용한 후 페이지가 시각적으로 응답하는 데 걸리는 시간을 측정하는 Interaction to Next Paint (INP)에도 영향을 미칠 수 있습니다. 디코딩해야 할 큰 이미지가 너무 많으면 페이지가 사용자 상호작용에 응답하는 데 더 오랜 시간이 걸려 INP 점수가 낮아질 수 있습니다. 이는 수백 개의 이미지가 리소스를 놓고 경쟁하는 제품 목록 페이지에서 가장 흔하게 발생합니다.
단계 1: 속도를 위해 HTML 이미지 요소 최적화하기
Src 속성
이미지의 URL을 지정합니다. 브라우저에 이미지를 찾을 위치를 알려주므로 이 속성은 필수적입니다.
Width 및 height 속성
이미지의 너비와 높이를 픽셀 단위로 지정합니다. 이 속성은 이미지 컨테이너의 크기와 이미지가 그 안에 어떻게 맞는지 정의하므로 페이지에 이미지를 올바르게 렌더링하는 데 중요합니다. 레이아웃 변동을 방지하려면 항상 width와 height를 모두 설정하세요.
Alt 속성
이미지를 표시할 수 없는 경우 대체 텍스트를 지정합니다. 시각 장애가 있는 사용자가 이미지가 무엇인지 이해하는 데 도움을 주므로 접근성 측면에서 중요합니다. 또한 검색 엔진이 alt 텍스트를 사용하여 이미지 콘텐츠를 이해하므로 검색 엔진 최적화(SEO)에도 중요합니다.
Loading 속성 (지연 로딩)
브라우저가 이미지를 로드하는 방식(lazy, eager 또는 auto)을 지정합니다. 이미지를 비동기적으로, 필요할 때만 로드할 수 있게 해주므로 페이지 성능 향상에 중요한 속성입니다. LCP 이미지에는 절대로 loading="lazy"를 설정하지 마세요. 2025 Web Almanac에 따르면, 16%의 페이지가 여전히 LCP 이미지를 지연 로드하며, 이는 웹에서 가장 흔한 성능 실수 중 하나입니다.
Srcset 속성
Sizes 속성
Decoding 속성
Fetchpriority 속성
fetchpriority 속성은 페이지의 다른 리소스에 비해 리소스 가져오기(fetch) 우선순위를 지정합니다. 이 속성은 "high", "low", "auto" 세 가지 값 중 하나를 가질 수 있습니다. 우선순위가 높은 리소스는 우선순위가 낮은 리소스보다 먼저 로드됩니다. 2026년 현재 fetchpriority는 모든 최신 브라우저(Chrome 102+, Safari 17.2+, Firefox 132+, Edge 102+)에서 지원되며 프로덕션 환경에서 사용해도 안전합니다. 단 17%의 페이지만이 LCP 이미지에 이를 사용하고 있는데, 이는 대다수의 사이트가 쉽게 얻을 수 있는 이점을 놓치고 있음을 의미합니다.
단계 2: 이미지가 최대한 빨리 다운로드 대기열에 추가되도록 보장하기
HTML을 최적화한 후 두 번째로 해야 할 일은 이미지 스케줄링을 살펴보는 것입니다. 많은 경우, 이미지가 LCP 지표에 미치는 가장 큰 병목 현상은 지연된 스케줄링입니다. 렌더링 과정에서 브라우저가 초기에 LCP 요소를 다운로드할 기회가 있다면, 브라우저는 최대한 빨리 이미지를 사용할 수 있게 되며 렌더링 과정 초기에 해당 요소의 페인팅을 시작할 수 있습니다.
간단하게 들리죠? 그럼 어떻게 이미지가 최대한 빨리 다운로드 대기열에 추가되도록 할 수 있을까요?
LCP 요소 프리로드하기
빠른 다운로드를 보장하는 가장 효과적인 방법은 이미지를 프리로드(preload)하는 것입니다. 이미지 프리로딩은 <head> 요소 시작 부분에 간단한 태그를 추가하여 수행됩니다. 예를 들어:
<link rel="preload" as="image" href="image.jpg">
이 간단한 태그는 곧 "image.jpg"가 필요할 것임을 브라우저에 알리며, 브라우저는 즉시 이 파일의 다운로드를 시작합니다.
CoreDash가 모니터링한 사이트 전반에서, 프리로드된 LCP 이미지가 있는 페이지 로드의 83%가 LCP에서 '우수(good)' 점수를 받은 반면, 프리로딩이 없는 경우는 65%에 불과했습니다.
LCP 요소 즉시 로드(Eager load)하기
높은 fetchpriority 사용하기
어떤 이유로 LCP 요소를 프리로드할 수 없다면 적어도 요소의 fetchpriority 속성을 high로 설정하세요. 이렇게 하면 이미지가 페이지에서 중요하다는 힌트를 브라우저에 제공하고 브라우저는 높은 우선순위로 다운로드합니다. fetchpriority="high"를 사용하는 것은 대개 이미지를 프리로드하는 것만큼 효율적이지 않다는 점을 명심하세요!
단계 3: 이미지가 최대한 빨리 다운로드되도록 보장하기
세 번째로 해야 할 일은 필요 이상으로 큰 이미지에 귀중한 네트워크 리소스를 낭비하지 않는 것입니다. 반응형 이미지, 압축, 그리고 새롭고 더 빠른 이미지 포맷을 사용하여 이를 수행할 수 있습니다.
반응형 이미지
다음은 srcset과 sizes를 사용한 반응형 이미지입니다:
<img src="hero-800.jpg" srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, 800px" width="800" height="450" alt="Descriptive alt text">
브라우저는 뷰포트 너비를 기준으로 가장 적절한 이미지를 선택합니다. 지연 로드되는 스크롤 아래(below-the-fold) 이미지의 경우 sizes="auto"(Chrome 126+ 및 Edge 126+에서 지원)를 사용할 수도 있으며, 이를 통해 브라우저가 이미지의 CSS 레이아웃에 따라 올바른 크기를 자동으로 계산할 수 있습니다.
이미지 압축
새롭고 더 빠른 이미지 포맷
이미지는 종종 웹페이지에서 가장 큰 리소스 중 하나이며, 최적화되지 않은 경우 페이지 로딩 속도를 크게 늦출 수 있습니다. WebP 및 AVIF와 같은 최신 이미지 포맷은 동일한 시각적 품질을 유지하면서 JPEG보다 훨씬 더 나은 압축을 제공합니다.
WebP는 거의 모든 브라우저(전 세계적으로 약 99% 지원)에서 지원되며 일반적으로 JPEG에 비해 파일 크기를 25-35% 줄여줍니다. AVIF는 이보다 한 단계 더 나아가 JPEG 대비 50% 이상의 용량 절감을 제공하며, 현재 94.7%의 브라우저 지원(Chrome 85+, Firefox 93+, Safari 16.4+)을 확보하고 있습니다. 그럼에도 불구하고 2025 Web Almanac에 따르면 AVIF는 LCP 이미지의 0.7%에서만 사용되는 반면, JPEG는 57%로 여전히 지배적인 위치를 차지하고 있습니다. 이는 엄청난 기회입니다.
<picture> 요소를 사용하여 각 브라우저가 지원하는 최상의 포맷을 제공하세요:
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" width="800" height="450" alt="Descriptive alt text"> </picture>
브라우저는 먼저 AVIF를 시도하고, WebP로 대체(fallback)하며, 최후의 수단으로 JPEG를 사용합니다. 미래가 궁금하다면 JPEG XL 및 현재 브라우저 지원 상태에 대해 읽어보세요.
단계 4: 레이아웃 변동(layout shift) 제거하기!
로드 중에 크기가 변경되는 이미지는 레이아웃 변동을 유발합니다. 아주 간단한 원리입니다. 이 섹션에서는 가장 흔한 3가지 이유를 다룹니다. 동영상, iframe, 아트 디렉션, 반응형 이미지 불일치 및 지연 로딩을 포함한 모든 이미지 및 미디어 CLS 원인에 대한 전체 가이드는 이미지 및 미디어가 레이아웃 변동을 유발하는 방법을 참조하세요.
1. 누락된 이미지 크기
2. 스타일링 문제
보통 이미지는 간단한 CSS 요령으로 뷰포트보다 커지는 것을 방지합니다:
img{
max-width:100%;
height:auto;
}
이것은 훌륭한 요령이며 여러분도 이를 사용해야 합니다. 안타깝게도 레이아웃 변동을 유발하는 이 요령의 변형을 자주 보게 됩니다. 예를 들어 width:auto를 추가하는 경우입니다:
img{
max-width:100%;
height:auto;
width:auto;
}
이렇게 하면 모든 이미지가 auto width와 height로 렌더링됩니다. 이는 보통 브라우저가 이미지를 다운로드하기 전에 0x0px로 이미지를 렌더링함을 의미합니다.
3. 플레이스홀더
일부 JavaScript 기반 지연 로딩 스크립트는 플레이스홀더를 사용합니다. 위에서 언급한 max-width:100% 및 height:auto와 같은 일종의 CSS 요령을 사용하면, 정사각형 플레이스홀더의 auto height가 이미지의 height 속성과 일치하지 않게 됩니다. 기본적으로 이미지는 먼저 720x720의 정사각형 플레이스홀더로 렌더링되고, 최종 이미지가 다운로드되면 720x180으로 렌더링됩니다:
<img src="1x1placeholder.png" data-src="hero.png" width="720" height="180" style="height:auto;max-width:100%" >
단계 5: 메인 스레드 보호하기
다음으로 확인해야 할 것은 메인 스레드에서 한 번에 너무 많은 이미지가 디코드되지 않도록 하는 것입니다. 대개는 문제가 되지 않지만, 제품 목록 페이지(때로는 500개에 달하는 이미지가 리소스를 놓고 경쟁하는 곳)에서 이런 현상이 발생하는 것을 여러 번 보았습니다.
모든 이미지에 decoding="async"를 추가하여 이러한 이미지가 별도의 스레드에서 디코드될 수 있도록 하는 것이 요령입니다. 또한 모든 스크롤 아래 이미지 및 숨겨진 이미지에 loading="lazy"를 추가하여 이렇게 많은 이미지가 한 번에 디코드되는 것을 피하세요.
단계 6: 각 이미지에 적합한 전략 선택하기!
LCP 요소를 위한 이미지 전략
LCP 요소는 일반적으로 가장 중요한 시각적 요소입니다. 따라서 이에 대한 우선순위를 확실히 높여야 합니다.
- 다음 코드를 사용하여 페이지 헤드의 초기에 이미지를 프리로드합니다:
<link rel="preload" as="image" href="path-to-img.png"> loading="eager"를 설정하거나 loading 속성을 생략하여 이 이미지가 지연 로드되지 않아야 함을 브라우저에 알립니다.fetchpriority="high"를 사용하여 이 이미지가 높은 우선순위로 다운로드되어야 함을 브라우저에 힌트로 제공합니다(이미지를 프리로드하는 경우 이 부분은 생략 가능).- 이 요소는 매우 중요하여 메인 스레드에서 디코드하기를 원하므로
decoding="sync"를 설정합니다.
다음은 프리로딩이 포함된 최적화된 반응형 LCP 이미지의 완전한 예입니다:
<!-- In <head> --> <link rel="preload" as="image" href="hero-800.jpg" imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" imagesizes="(max-width: 600px) 100vw, 800px"> <!-- In <body> --> <img src="hero-800.jpg" srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, 800px" width="800" height="450" alt="Descriptive alt text" fetchpriority="high" decoding="sync">
로고 및 기타 표시되는 (비 LCP) 이미지를 위한 이미지 전략
표시되는 이미지는 페이지 로드 중에 꽤 일찍 로드되어야 하지만 가급적 LCP 요소 이후에 로드되는 것이 좋습니다. LCP 요소를 프리로드함으로써 이를 달성할 수 있습니다. 그렇게 하면 이러한 표시되는 이미지에 자연스럽고 올바른 다운로드 순서가 부여됩니다.
loading="eager"를 설정하거나 loading 속성을 생략하여 이 이미지가 지연 로드되지 않아야 함을 브라우저에 알립니다.- 이 요소는 메인 스레드 외부에서 안전하게 디코드될 수 있으므로
decoding="async"를 설정합니다!
스크롤 아래(below-the-fold) 이미지를 위한 이미지 전략
모든 스크롤 아래 이미지는 지연 로드되어야 합니다. 아주 간단합니다! 예외는 없습니다!
loading="lazy"를 설정하여 이 이미지가 지연 로드되어야 함을 브라우저에 알립니다.- 이 요소는 메인 스레드 외부에서 안전하게 디코드될 수 있으므로
decoding="async"를 설정합니다!
배경 이미지 피하기
배경 이미지를 사용하고 있다면 재고해야 합니다. 배경 이미지는 지연 로드할 수 없으며 decoding 속성을 제어할 수 없고 fetchpriority를 설정할 수도 없습니다. 배경 이미지는 보통 반응형이 아니므로 많은 대역폭을 소비하게 될 것입니다. 하지만 가장 중요한 점은 배경 이미지가 브라우저가 CSS 파일을 다운로드한 후에 발견되는 경우가 많다는 것입니다. 이는 이미지 다운로드를 트리거하기에 결코 적절한 타이밍이 아닙니다! 배경 이미지가 좋지 않은 이유와 어쩔 수 없는 경우 배경 이미지를 지연시키는 방법을 읽어보세요.
일반 이미지 태그를 CSS object-fit:cover와 함께 사용하여 일반 이미지가 배경 이미지처럼 작동하게 만들 수 있습니다!
Real User Monitoring으로 영향력 모니터링하기
이러한 최적화를 적용한 후, 실제 사용자에게도 성능을 실제로 향상시키는지 확인하세요. Lighthouse와 같은 랩 도구(Lab tools)는 변경 사항이 올바른지 확인할 수 있지만, 오직 Real User Monitoring만이 방문자에게 미치는 실제 영향을 보여줍니다. 시간이 지남에 따라 LCP, CLS, INP를 추적하여 이미지 최적화가 예상대로 작동하는지 확인하세요.
