AVIF나 WebP로 바꾸면 이미지가 항상 빨라질까?

항상 그렇지는 않습니다. 포맷은 전송 바이트를 줄일 수 있지만, 결과는 이미지 종류와 인코딩 설정, 표시 크기, 기기에서의 디코딩, 캐시 적중 여부에 달려 있습니다. 먼저 같은 이미지를 같은 표시 크기로 인코딩해 실제 파일 크기와 눈에 띄는 손상을 비교하고, 그 뒤 대체 형식과 캐시 경로를 점검하세요. web.dev 이미지 성능 안내

포맷 이름보다 콘텐츠와 품질을 비교하기

AVIF는 AV1 이미지 데이터를 HEIF 기반 파일 형식에 담는 규격입니다. HDR·넓은 색역·투명도와 여러 비트 심도를 다룰 수 있지만, 파일 확장자만으로 인코더 설정이나 브라우저별 처리 비용을 알 수는 없습니다. AOMedia AVIF 규격 v1.2.0 WebP는 손실·무손실 압축과 투명도를 지원합니다. Google WebP 설명

사진은 손실 압축을 비교하기 좋지만, 글자나 가는 선이 있는 화면 캡처·도표는 같은 설정에서 번짐이나 색 테두리가 더 잘 보일 수 있습니다. 작은 썸네일과 큰 대표 이미지를 각각 실제 표시 크기로 확인하세요. 형식 하나를 일괄 적용하기보다 시각 품질과 전송 크기를 함께 보고 선택합니다. web.dev 압축 및 포맷 안내

예: 상품 대표 이미지 하나를 안전하게 바꾸기

800픽셀 폭으로 표시되는 상품 사진을 예로 들겠습니다. 원본 JPEG와 AVIF·WebP 후보를 동일한 크기로 준비하고, 사진의 질감뿐 아니라 가격 글자와 가장자리도 확대해 확인합니다. 파일 바이트, 실제 모바일 전송 크기, 대표 이미지의 LCP, 지원 기기에서의 디코딩을 측정합니다. AVIF가 더 작아도 첫 요청의 변환 지연이나 기기 부담이 결과를 상쇄한다면 WebP 또는 기존 JPEG가 더 나을 수 있습니다. 이는 측정할 항목이지 특정 포맷이 언제나 이긴다는 규칙은 아닙니다.

브라우저별 폴백은 <picture>에 AVIF와 WebP 후보를 두고 안쪽 <img>에 JPEG 같은 대체 파일을 지정하는 방식으로 제공할 수 있습니다. 대체 이미지의 alt, width, height는 <img>에 둡니다. 표시 폭이 달라진다면 srcset과 sizes도 함께 설정해 모바일에 지나치게 큰 원본을 보내지 않도록 합니다. web.dev의 picture 및 반응형 이미지 예

같은 URL에서 Accept 협상을 쓸 때 캐시 확인

서버가 요청의 Accept에 따라 같은 경로에서 AVIF·WebP·JPEG를 선택한다면, 공유 캐시가 서로 다른 응답을 구분해야 합니다. 일반적인 HTTP 구성에서는 Vary: Accept를 올바르게 내보내고 실제 캐시가 그 변형을 키에 반영하는지 확인합니다. web.dev의 Accept 협상 안내

Cloudflare의 이미지 변형 기능은 Accept를 해석해 포맷별 캐시를 분리하지만, 현재 문서상 Pro·Business·Enterprise 요금제에서 이용할 수 있고 원본이 Vary: Accept와 설정된 변형을 실제로 제공해야 합니다. 설정한 형식이 오리진에서 나오지 않으면 캐시되지 않고 BYPASS가 될 수 있습니다. 이는 Cloudflare 기능의 조건이며 다른 CDN에도 그대로 적용된다고 가정하지 마세요. Cloudflare Vary for Images 문서

출시 전 확인 순서

  • 1. 대표 사진, 글자·선이 있는 이미지, 투명 이미지 등 실제 자산을 골라 후보 형식을 같은 크기와 목적 품질로 비교합니다.
  • 2. HTML 대체 경로와 반응형 크기를 확인하고, 이미지의 Content-Type이 실제 파일과 맞는지 시험합니다.
  • 3. Accept 헤더가 다른 브라우저 두 종류 이상으로 요청해 응답 본문 형식, Vary, 캐시 상태를 확인합니다. 첫 요청과 반복 요청을 나누어 측정합니다.
  • 4. 변형 수를 필요한 만큼으로 제한합니다. 크기와 포맷 조합이 늘면 별도 캐시 항목과 오리진 재요청도 늘 수 있습니다.

성능은 압축률만이 아니라 적절한 픽셀 크기, 네트워크 전송량, 캐시 효율을 함께 측정해야 합니다. 작은 파일이 LCP나 사용자 체감 개선을 보장하지는 않습니다. web.dev 이미지 성능 안내

출처