이미지로 전송량과 LCP 잡기: WebP·AVIF와 반응형 이미지 기법
🤖 AI Summary
이미지는 웹 페이지 전송량의 큰 축이자, 화면에서 가장 큰 콘텐츠인 만큼 LCP와 CLS를 크게 좌우합니다. 줄이는 길은 세 갈래예요. 첫째 포맷입니다. 스피디 CDN 백서 기준 WebP는 JPEG 대비 25~34%, AVIF는 50% 이상 용량이 줄죠. 둘째 크기입니다. MDN 기준 srcset과 sizes로 화면 폭에 맞는 해상도를 골라 보내면, 모바일에 데스크톱용 큰 이미지를 내려받는 대역폭 낭비를 막습니다. 셋째 안정성입니다. img에 width와 height를 명시하면 브라우저가 미리 종횡비로 공간을 잡아 레이아웃 이동(CLS)을 줄여요. 여기에 loading으로 지연 로딩을, fetchpriority로 중요한 이미지 우선순위를 더하면 됩니다. 근거는 MDN과 스피디 CDN 백서입니다.
블로그 목차
이미지가 전송량과 속도를 좌우하는 이유
웹 페이지에서 가장 무거운 자원은 대개 이미지입니다. 그리고 화면에서 가장 큰 요소도 보통 이미지죠. 이 두 가지 사실이 겹치면서 이미지는 전송량과 사용자 체감 속도를 동시에 좌우합니다. 스피디 CDN 백서가 인용한 Core Web Vitals 기준으로, 페이지의 주요 콘텐츠가 그려지는 시간인 LCP는 2.5초 이내가 Good이고, 로딩 중 예기치 않은 레이아웃 이동을 재는 CLS는 0.1 이하가 Good입니다. 히어로 이미지나 대표 배너가 이 두 지표를 직접 흔들어요.
대역폭 관점도 있습니다. MDN은 반응형 이미지를 설명하며 "모바일 사용자는 작은 이미지면 충분한데도 데스크톱용 큰 이미지를 내려받아 대역폭을 낭비하고 싶어 하지 않는다"고 짚습니다. 같은 이미지를 640픽셀은 93KB, 320픽셀은 39KB로 예시하며 이 기법으로 모바일 대역폭을 크게 아낄 수 있다고 하죠. 이 글은 포맷, 크기, 안정성 세 축으로 이미지를 다루는 표준 기법을 정리합니다.
첫째, 포맷: WebP와 AVIF로 용량 줄이기
가장 먼저 손댈 곳은 포맷입니다. 스피디 CDN 백서는 "WebP는 JPEG 대비 25~34% 용량 절감, AVIF는 50% 이상 절감이 가능하다"고 밝혀요. 같은 이미지를 더 가벼운 포맷으로 바꾸는 것만으로 전송량이 눈에 띄게 줄어드는 셈이죠. 다만 브라우저마다 지원 범위가 다르니, CDN은 클라이언트가 어떤 포맷을 지원하는지에 따라 원본 JPEG·PNG를 WebP나 AVIF로 변환해 내보내기도 합니다.
이미지가 아닌 텍스트 자원도 압축으로 줄일 수 있습니다. 백서 기준 CSS와 JS 파일은 Brotli 압축 시 Gzip 대비 15~20% 추가 절감이 가능해요. 이미지 포맷 최적화와 텍스트 압축을 함께 걸면 전체 전송량이 더 내려갑니다. 압축 방식 자체는 웹 압축 Brotli·Zstandard 글에서 더 다뤘습니다.
둘째, 크기: srcset·sizes로 화면에 맞게 보내기
포맷을 바꿔도 데스크톱용 큰 이미지를 모바일에 그대로 내려보내면 낭비는 남습니다. 그래서 화면 폭에 맞는 해상도를 고르는 것이 반응형 이미지입니다. MDN은 srcset을 두고 "브라우저가 고를 수 있는 이미지 세트와 각 이미지의 크기를 정의한다"고 설명해요. 파일명 뒤에 그 이미지의 실제 가로 픽셀을 480w처럼 적는데, MDN은 이 w가 예상과 달리 px이 아니라 이미지의 고유 너비를 뜻한다고 짚습니다.
짝을 이루는 것이 sizes입니다. MDN 기준 sizes는 "미디어 조건과, 그 조건이 참일 때 이미지가 채울 슬롯의 크기를 정의"합니다. 예를 들어 "뷰포트 폭이 600픽셀 이하일 때는 480픽셀 슬롯"처럼 적으면, 브라우저가 srcset의 후보 중 그 상황에 가장 알맞은 이미지를 골라 받습니다. 화면 크기에 따라 같은 그림을 크거나 작게만 바꾸는 것을 해상도 전환이라 하고, 화면에 따라 아예 다른 구도의 이미지를 보여 주려면 picture 요소와 media 조건을 쓰는데, MDN은 이를 아트 디렉션이라 부르죠.
셋째, 안정성: width·height로 레이아웃 이동 막기
용량과 크기를 잡았다면 남는 것은 CLS죠. 이미지가 늦게 도착하면서 뒤늦게 자리를 차지하면 그 아래 콘텐츠가 밀려 내려가는데, 이 이동이 CLS를 악화시켜요. 해법은 단순합니다. MDN은 img에 "height와 width를 함께 넣으면 이미지가 로드되기 전에 브라우저가 종횡비를 계산할 수 있고, 이 종횡비로 이미지가 차지할 공간을 미리 예약해 레이아웃 이동을 줄이거나 방지한다"고 설명합니다. 스피디 CDN 백서도 CLS 개선으로 이미지의 width와 height를 사전에 제공하는 방법을 같은 취지로 다룹니다.
로딩 방식도 성능에 영향을 줍니다. MDN 기준 loading="lazy"는 이미지가 뷰포트에서 일정 거리 안에 들어올 때까지 로딩을 미뤄, 당장 필요하지 않은 이미지의 대역폭을 아껴요. 반대로 첫 화면의 핵심 이미지는 빨리 그려져야 하죠. 이때 fetchpriority가 쓰입니다. MDN은 이 속성이 이미지를 가져올 때 상대적 우선순위 힌트를 주며 high·low·auto 값을 가진다고 설명해요. LCP를 좌우하는 히어로 이미지에 fetchpriority="high"를 주고, 화면 아래 이미지에 loading="lazy"를 주는 식으로 조합합니다. 이 지표들을 전반적으로 점검하려면 Core Web Vitals 자가진단 글을 함께 보시면 좋습니다.
이것만 기억하세요
이미지는 전송량과 LCP·CLS를 동시에 좌우합니다. 포맷은 WebP·AVIF로(백서 기준 JPEG 대비 25~50% 이상 절감), 크기는 srcset·sizes로 화면에 맞게 보내면 대역폭을 아껴요. img에 width·height를 명시하면 종횡비 예약으로 CLS를 막고, 히어로 이미지엔 fetchpriority=high, 화면 아래엔 loading=lazy를 씁니다. 근거는 MDN과 스피디 CDN 백서입니다.
자주 묻는 질문 (FAQ)
Q. WebP와 AVIF는 얼마나 용량이 줄어드나요?
스피디 CDN 백서 기준으로 WebP는 JPEG 대비 25~34%, AVIF는 50% 이상 용량이 줄어듭니다. 같은 이미지를 더 가벼운 포맷으로 바꾸는 것만으로 전송량이 크게 감소합니다. 브라우저 지원 범위가 다르므로, CDN은 클라이언트가 지원하는 포맷에 맞춰 원본을 변환해 내보내기도 합니다.
Q. srcset과 sizes는 무엇이 다른가요?
srcset은 브라우저가 고를 수 있는 이미지 후보들과 각 이미지의 실제 픽셀 너비(예: 480w)를 정의합니다. sizes는 미디어 조건과, 그 조건이 참일 때 이미지가 채울 슬롯의 크기를 정의합니다. 둘을 함께 쓰면 브라우저가 현재 화면 상황에 가장 알맞은 이미지를 골라 받습니다. MDN 기준 설명입니다.
Q. width와 height는 왜 넣어야 하나요?
레이아웃 이동(CLS)을 막기 위해서입니다. MDN에 따르면 img에 width와 height를 함께 넣으면 브라우저가 이미지 로드 전에 종횡비를 계산해 필요한 공간을 미리 예약합니다. 그러면 이미지가 늦게 도착해도 아래 콘텐츠가 밀리지 않아 레이아웃 이동이 줄거나 방지됩니다.
Q. lazy loading은 모든 이미지에 쓰면 되나요?
아닙니다. loading="lazy"는 뷰포트에서 떨어진 이미지의 로딩을 미뤄 대역폭을 아끼므로, 화면 아래쪽 이미지에 적합합니다. 반대로 첫 화면의 핵심 이미지, 특히 LCP를 좌우하는 히어로 이미지는 빨리 그려져야 하므로 lazy를 피하고 fetchpriority="high"로 우선순위를 높이는 편이 좋습니다.
Q. fetchpriority는 어떤 값을 쓰나요?
MDN 기준 fetchpriority는 이미지를 가져올 때의 상대적 우선순위 힌트로 high, low, auto 값을 가집니다. auto가 기본값이고, 첫 화면에서 가장 중요한 이미지에 high를 주면 브라우저가 그 이미지를 다른 이미지보다 먼저 가져옵니다. 반대로 덜 중요한 이미지에는 low를 줄 수 있습니다.
