같은 사진을, 절반 무게로.

한 클라이언트 사이트가 “사진이 무거워서 느리다”고 했습니다. 사진을 줄이자는 말이 나왔죠. 그런데 사진은 그 페이지의 얼굴이었습니다. 줄이면 안 됐습니다. 제가 한 건 화질을 거의 그대로 둔 채 포맷을 AVIF로 바꾸고, 화면 크기별로 잘라 내보내고, 로딩 순서만 손본 것이었습니다. 같은 사진이 보기엔 똑같은데 무게는 절반 아래로 떨어졌습니다. 이미지 최적화는 ‘사진을 포기하는 일’이 아니라 ‘같은 사진을 더 똑똑하게 전달하는 일’입니다.

먼저, 직접 느껴보세요

좋은 이미지 로딩은 ‘텅 빈 화면에서 갑자기 쿵’이 아니라 ‘흐릿하게 먼저, 또렷하게 나중에’입니다. 아래에서 ‘다시 불러오기’를 눌러보세요. 저용량 미리보기가 먼저 깔리고 원본이 채워지는 흐름입니다.

왜 AVIF를, 그것도 picture로 쓰나요?

AVIF는 같은 화질에서 jpg·png보다, 보통은 webp보다도 더 작습니다. 라이브로 확인한 지원 현황은 이렇습니다. Chrome 85+, Firefox 93+, Safari 16.4+가 동작하고, caniuse 기준 전 세계 약 94% 브라우저가 AVIF를 읽습니다(2026 초 기준, ‘Baseline 2024’). 남는 몇 %는 iOS 15 이하나 일부 인앱·사내 락다운 브라우저입니다. 그래서 단독으로 쓰지 않고 picture로 폴백 사다리를 만듭니다. 브라우저가 읽을 수 있는 첫 줄을 자동으로 고릅니다.

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="..." width="1200" height="800">
</picture>

이러면 최신 브라우저는 가장 가벼운 AVIF를, 구형은 webp나 jpg를 받습니다. ‘가장 가벼움’과 ‘가장 넓은 호환성’을 동시에 챙기는 방법입니다.

한 장을 모두에게 보내지 마세요 — srcset·sizes

1920px 사진을 360px 휴대폰에 그대로 보내는 건 낭비입니다. 같은 사진을 여러 크기로 준비해두고, 화면에 맞는 것만 내려보냅니다. 이때 너비(w) 서술자를 쓰면 sizes가 사실상 필수입니다. 화면에서 이미지가 차지할 너비를 알려줘야 브라우저가 옳게 고릅니다. 실무에서 자주 쓰는 후보 너비는 640·768·1024·1280·1920px 정도, 최대 2560px이면 레티나까지 충분합니다.

<img
  src="photo-1024.jpg"
  srcset="photo-640.jpg 640w, photo-1024.jpg 1024w, photo-1920.jpg 1920w"
  sizes="(max-width: 768px) 100vw, 768px"
  width="1920" height="1280" alt="...">

한 가지 주의. srcset에 적은 너비(예: 1024w)는 실제 파일의 가로 픽셀과 일치해야 합니다. 어긋나면 브라우저가 잘못된 후보를 고릅니다. 그리고 구형 대비 기본 src는 항상 넣습니다.

히어로엔 fetchpriority=high, 나머진 lazy

브라우저는 처음엔 화면 안 이미지조차 ‘낮은 우선순위’로 봅니다. 레이아웃이 끝나야 ‘아, 이게 화면에 있네’ 하고 뒤늦게 우선순위를 올립니다. 그 사이 히어로 이미지(LCP가 될 그 한 장)가 늦게 뜹니다. 그래서 마크업에서 미리 fetchpriority="high"로 ‘이건 최우선’이라고 알려줍니다.

<!-- 첫 화면 히어로: 단 한 장에만 -->
<img src="hero-1024.avif" fetchpriority="high"
     width="1200" height="800" alt="...">

<!-- 화면 밖 이미지: 나중에 -->
<img src="card.avif" loading="lazy"
     width="600" height="400" alt="...">

라이브로 확인한 지원은 Chrome 102+, Safari 17.2+, Firefox 132+입니다. 미지원 브라우저는 속성을 그냥 무시하므로 위험이 전혀 없는 ‘점진적 향상’입니다. 핵심 규칙 둘. ① high는 첫 화면 한 장에만(전부 high면 우선순위가 사라집니다). ② 히어로엔 lazy를 쓰지 않습니다(첫 화면을 일부러 늦추는 셈이 됩니다). 화면 밖 카드·갤러리 이미지에만 lazy를 붙입니다.

가장 흔한 함정 — 덜컹거리는 레이아웃(CLS)

이미지가 뜨는 순간 아래 글이 밀려 내려간 경험, 있죠. img에 width·height(또는 CSS aspect-ratio)를 안 줘서 브라우저가 자리를 못 비워둔 탓입니다. 크기를 명시하면 이미지가 오기 전에 자리를 잡아둬 CLS가 0에 가깝게 떨어집니다. 위 블러업 데모에서 미리보기와 원본이 ‘같은 자리’를 차지하는 것도 같은 이유입니다.

제가 히어로 이미지 하나에 실제로 붙이는 마크업은 이렇게 한 덩어리입니다. 포맷 폴백·반응형 후보·우선 로딩·자리 확보를 한 번에 챙깁니다.

<picture>
  <source type="image/avif"
          srcset="hero-640.avif 640w, hero-1280.avif 1280w, hero-1920.avif 1920w"
          sizes="(max-width: 768px) 100vw, 1200px">
  <source type="image/webp"
          srcset="hero-640.webp 640w, hero-1280.webp 1280w"
          sizes="(max-width: 768px) 100vw, 1200px">
  <img src="hero-1280.jpg" alt="단지 전경"
       width="1200" height="800"
       fetchpriority="high" decoding="async">
</picture>

이 한 덩어리면 최신 브라우저는 가장 가벼운 AVIF를, 구형은 webp나 jpg를 받고, 첫 화면은 빨리 뜨면서 레이아웃은 흔들리지 않습니다.

이미지 하나를 이렇게 보는 사람이, 사이트 전체를 만듭니다

이미지는 대부분의 페이지에서 가장 무거운 자원입니다. 그 한 장의 포맷·크기·순서를 진지하게 다루는 사람이라면 폼도, 카피도, 속도도 같은 태도로 다룹니다. Findable에서는 이런 디테일이 기본값입니다. 당신의 사이트, 사진을 포기하지 않고 더 빠르게 만들어 드릴까요?