웹 이미지 최적화 — WebP·AVIF·srcset·올바른 압축

웹 페이지에서 가장 무거운 요소는 거의 항상 이미지다. 잘 최적화된 사이트 는 LCP (Largest Contentful Paint) 가 1.5 초, 안 된 사이트는 5 초+ 차이. 이 가이드는 2026 년 기준으로 어떤 포맷을 언제 쓰는지, srcset 으로 디바이스별 적정 크기를 어떻게 보내는지, lazy loading 과 priority hint 의 정답을 정리한다.

포맷 — JPEG / PNG / WebP / AVIF

2026 기준 권장:

• 로고·아이콘: SVG.
• 사진 (블로그, 히어로): AVIF + WebP fallback + JPEG fallback.
• UI 일러스트, 투명 그래픽: WebP 또는 PNG.

quality 와 파일 크기의 관계

JPEG/WebP/AVIF 의 quality 슬라이더는 percent 가 아니다 — 같은 80 이 포맷마다 다른 의미. 일반 권장:

• JPEG quality 80 — 시각적 차이 거의 없음. 50 까지 떨어 뜨려도 모바일에서는 인지하기 어려움.
• WebP quality 75-80 — JPEG 80 과 동급 품질.
• AVIF quality 50-60 — JPEG 80 과 동급 품질 (압축률 더 높음).

sites 마다 다른 sweet spot. 이미지 리사이즈·압축 에서 quality 슬라이더 + 압축률 표시를 보면서 시각적 임계점 빠르게 찾기 가능.

해상도 — 디바이스에 맞는 크기

가장 큰 낭비: 모바일 (360 px 폭) 에게 1920 px 폭 이미지 전달. 사용자는 보지도 못하는 픽셀에 trafic 소모. retina (2x) 까지 감안해 도 720 px 이상이 필요 없음.

srcset 으로 디바이스 폭별 후보 제공, 브라우저가 자동 선택:

<img
  src="hero-1280.jpg"
  srcset="hero-640.jpg 640w, hero-1280.jpg 1280w, hero-1920.jpg 1920w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="..."
  loading="lazy"
  width="1280"
  height="720"
/>

• srcset — 후보 + 폭 (w) 정보.
• sizes — 레이아웃에서 이미지가 차지하는 폭. 브라우저가 이걸 보고 srcset 후보 중 적정 선택.
• width·height 속성 — 비율 박힘 → CLS 방지. (CSS 로 폭 override 해도 비율 유지.)

여러 포맷 fallback — picture

AVIF/WebP 우선, 못 받는 브라우저에는 JPEG.

<picture>
  <source type="image/avif" srcset="hero.avif" />
  <source type="image/webp" srcset="hero.webp" />
  <img src="hero.jpg" alt="..." loading="lazy" />
</picture>

브라우저가 위에서부터 보고 지원하는 첫 번째 source 선택. 모든 fallback 안 되면 마지막 img. srcset 도 source 안에 박을 수 있음.

Lazy loading

Above-the-fold 가 아닌 이미지는 처음에 안 받음.

<img src="..." loading="lazy" alt="..." />

Chrome 76+, FF 75+, Safari 15.4+. 첫 화면에 보이는 (LCP 후보) 이미지에 는 loading="eager" + fetchpriority="high" 권장.

<img
  src="hero.jpg"
  loading="eager"
  fetchpriority="high"
  alt="..."
/>

fetchpriority 는 2024 년 표준화. 같은 페이지의 여러 이미지 중 어떤 게 LCP 후보인지 브라우저에 힌트.

Inline Base64 vs 외부 파일

작은 아이콘 (~1 KB 이하) 은 base64 data URI 로 inline 하면 HTTP 요청 절약. 단:

• base64 인코딩이 raw 대비 ~33% 큼. 큰 이미지에 inline 하면 오히려 손해.
• 캐시 안 됨 — 같은 이미지를 다른 페이지에 다시 박으면 매번 전송.
• CSS 안 background-image: url(data:...) 으로 가장 흔히 사용.

이미지 → Base64 (Data URI) 에 이미지를 넣으면 즉시 data URI 생성. inline 여부는 결과 크기 보고 결정.

SVG 최적화

• 편집 도구 (Illustrator, Figma) export 결과는 군더더기 많음 — svgo 또는 SVGOMG (브라우저) 로 압축. 50-80% 감소 흔함.
• viewBox 유지 + width/height 제거 → CSS 로 크기 자유.
• XSS 위험 — 사용자 제공 SVG 를 inline 시 DOMPurify 로 sanitize. 외부 <img> 는 안전.

CDN + 동적 리사이즈

Cloudflare Images, imgix, Cloudinary 같은 서비스는 URL 파라미터로 동적 리사이즈·포맷 변환·quality 조정. img.example.com/hero.jpg?w=640&fm=avif 식.

• 장점: 한 원본 → 디바이스별 자동 최적화. 새 디바이스/포맷 추가도 자동.
• 단점: 비용. 작은 사이트는 빌드 타임 정적 리사이즈로 충분.

정적 사이트 (Next.js, Astro, Hugo) 는 빌드 시점 리사이즈 — next/image 가 srcset/picture 자동 생성.

흔한 함정

1. 원본 크기로 노출

카메라 RAW 또는 4000 px 사진을 그대로 <img> 에 박음. CSS 로 200 px 표시해도 4000 px 다운로드. 빌드 타임 또는 CDN 으로 적정 크기.

2. width/height 누락

브라우저가 비율 모름 → 이미지 로드 후 페이지 layout shift (CLS). Core Web Vitals 페널티. 속성으로 박거나 CSS aspect-ratio.

3. PNG 로 사진

PNG 는 그래픽·아이콘용. 사진은 JPEG/WebP/AVIF — 같은 시각 품질에 1/3 크기.

4. Lazy 모든 이미지

First viewport 이미지에 loading="lazy" 박으면 LCP 늦어짐. Above-the-fold 는 eager + high priority.

5. CSS background 만 사용

SEO·접근성에서는 <img alt> 가 우월. background-image 는 장식적 요소만.

6. Alt text 비움 또는 "image"

alt 는 SR·검색엔진·이미지 실패 시 노출. 의미 있는 텍스트. 단, 순수 장식이면 alt="" (빈 문자열) 로 명시.

Core Web Vitals 영향

• LCP(Largest Contentful Paint) — 첫 화면의 큰 이미지 가 보통 LCP element. AVIF + priority + 적정 크기 = LCP < 2.5 s 가능.
• CLS (Cumulative Layout Shift) — width/height 속성으로 예방.
• INP — 이미지 디코딩이 메인 스레드 막을 수 있음. decoding="async" 박으면 별도 스레드.

요약

• 포맷 우선순위: AVIF > WebP > JPEG (사진), SVG (로고/아이콘), PNG (투명 그래픽).
• <picture> + srcset + sizes 로 디바이스별 적정 이미지.
• width·height 속성 필수 — CLS 방지.
• LCP 후보 = eager + fetchpriority high. 나머지 = lazy.
• 작은 아이콘은 inline base64. 큰 이미지는 외부 파일 + 캐시.
• 빠른 quality 튜닝은 이미지 리사이즈·압축 에서 슬라이더 + 압축률 표시 확인.