웹용 이미지 압축: 실제로 얼마나 절약합니까? (2026)
웹용 이미지 압축: 실제로 얼마나 절약합니까?
귀하 사이트의 Core Web Vitals이 빨간색이고, Lighthouse 점수가 60 위로 올라가지 않고, 감사 도구가 계속 "이미지를 적절하게 크기 조정" 및 "현대 이미지 형식 사용"에 대해 외칩니다. 최악의 위반자를 압축하고, 페이지 무게가 1.2 MB 떨어지고, 갑자기 LCP가 3.4초에서 1.8초로 갑니다. 이미지 압축은 모든 웹사이트에 대해 가장 높은 ROI 성능 향상 중 하나로 남아 있습니다 —— 그러나 각 레버가 실제로 무엇을 하는지 이해하는 경우에만.
이 가이드는 실제 이미지에서 실제 바이트 절약으로 JPG 품질 80, WebP, AVIF 및 적극적인 리사이즈가 각각 무엇을 제공하는지 측정합니다. 또한 "현대" 형식으로 재인코딩이 절약하는 것보다 더 많이 소요되는 때와 **Ai2Done의 Image Compress 도구**로 모두 브라우저 측에서 어떻게 할 수 있는지 다룰 것입니다.
TL;DR
- 압축 전에 리사이즈 —— 800×600으로 표시되는 4000×3000 사진은 형식과 관계없이 바이트의 ~95%를 낭비합니다. 먼저 리사이즈; 둘째 압축.
- JPG 품질 80 → 90은 사진의 스위트 스폿입니다 —— 품질 100보다 50-70% 작고, 시각적으로 동일합니다.
- WebP는 같은 시각적 품질에서 JPG보다 ~25-35% 절약합니다. 2020년 이후 보편적인 브라우저 지원.
- AVIF는 같은 시각적 품질에서 JPG보다 ~50% 절약합니다 그러나 인코딩 시간이 5-10배 추가됩니다. 트래픽이 많은 페이지에 가치가 있습니다.
- 크기 대 품질의 나란히 미리보기로 브라우저 측 압축에 Ai2Done Image Compress 사용.
이것이 보이는 것보다 어려운 이유
"이 이미지를 압축하세요"가 단일 결정이라고 생각할 것입니다. 실제로 이미지 압축은 직관적이지 않게 상호 작용하는 최소 4개의 독립적인 레버입니다:
- 치수(너비 × 높이) —— 일반적으로 가장 영향력이 큰 레버. 4000×3000 사진은 1000×750보다 16배 많은 픽셀을 가집니다.
- 형식(JPG, WebP, AVIF, PNG) —— 인코딩 방법 자체.
- 품질 설정(JPG/WebP의 경우 1-100, AVIF의 경우 약간 다름) —— 인코더가 얼마나 적극적으로 정보를 폐기하는지.
- 색상 깊이 및 메타데이터(24비트 vs 8비트, EXIF 스트리핑, ICC 프로필) —— 일반적으로 작지만 무료 승리.
순진한 "이 이미지를 압축" 도구는 레버 3만 만지고, 가장 큰 절약을 테이블에 남겨둡니다. 현대 도구 —— 우리 것 포함 —— 는 최소한 네 가지 모두를 명시적으로 선택할 수 있게 합니다.
복잡성의 또 다른 소스: 브라우저 지원 및 청중. AVIF는 Chrome, Edge, Firefox 및 Safari 16+에서 놀랍습니다; 오래된 Safari는 JPG 폴백이 필요합니다. WebP는 IE 11(Microsoft가 2022년에 지원을 중단했지만 엔터프라이즈 사이트가 여전히 보는)을 제외한 모든 곳에 있습니다. 2026년 대부분의 공개 사이트에서 WebP는 안전합니다; AVIF에는 JPG 폴백이 있는 <picture> 요소가 필요합니다.
실제 측정: 3 MB 사진, 모든 방식으로 압축
대표적인 테스트 이미지를 가져왔습니다 —— 도시 스카이라인의 4032×3024 iPhone 샷, 카메라의 기본 품질(~92)에서 3.1 MB JPG. 각 레버가 격리되어 무엇을 하는지 다음과 같습니다:
| 작업 | 출력 크기 | 원본의 % | 시각적 차이 |
|---|---|---|---|
| 원본(JPG q92, 4032×3024) | 3.1 MB | 100% | — |
| 1920×1440으로 리사이즈(웹 히어로 크기) | 0.95 MB | 31% | 히어로 크기로 표시될 때 없음 |
| JPG 품질 85(리사이즈 없음) | 1.4 MB | 45% | 대부분의 시청자에게 거의 인식 불가 |
| JPG 품질 80(리사이즈 없음) | 0.92 MB | 30% | 정상 시청 거리에서 인식 불가 |
| JPG 품질 70(리사이즈 없음) | 0.55 MB | 18% | 가까운 검사에서 미묘한 부드러움 |
| WebP 품질 80(리사이즈 없음) | 0.62 MB | 20% | JPG q85와 동일 |
| AVIF 품질 65(리사이즈 없음) | 0.38 MB | 12% | JPG q85와 동일 |
| 1920×1440 리사이즈 + AVIF q65 | 0.14 MB | 4.5% | 웹 사용에 구별 불가 |
| 1920×1440 리사이즈 + WebP q80 | 0.23 MB | 7.5% | 웹 사용에 구별 불가 |
| 1920×1440 리사이즈 + JPG q80 | 0.32 MB | 10.3% | 웹 사용에 구별 불가 |
헤드라인: 리사이즈 + 현대 형식의 조합은 시각적 품질 손실 없이 90-95% 감소를 제공합니다. 어느 한 레버만으로 30-45%에 도달합니다. 이것이 Lighthouse 감사가 "적절하게 크기 조정"과 "현대 이미지 형식 사용" 모두에 대해 잔소리하는 이유입니다 —— 그들은 곱해집니다.
방법 1: Ai2Done Image Compress(브라우저 측, 다중 레버)
**Ai2Done Image Compress 도구**는 브라우저에서 모든 네 레버를 실행합니다:
- 어떤 현대 브라우저에서든 /tools/image_compress를 엽니다.
- 이미지(들)를 드롭 —— JPG, PNG, WebP, AVIF, HEIC 허용. 한 번에 수십 개의 파일까지 배치 업로드가 작동합니다.
- 출력 형식 선택: JPG(보편), WebP(현대, 25% 작음), AVIF(현대, 50% 작음, 느린 인코드), 또는 PNG(무손실, 다이어그램과 스크린샷에만).
- 품질 설정: 80은 사진의 보편적인 스위트 스폿입니다. 썸네일의 경우 70으로 낮추기; 히어로 이미지의 경우 90으로 올리기.
- 선택적 리사이즈: 최대 너비 또는 최대 긴 가장자리를 설정합니다. 종횡비가 자동으로 보존됩니다.
- 압축 클릭 —— 배치 작업의 경우 최적화된 모든 이미지의 ZIP을 받습니다.
사이드 패널은 현재 설정에서 원본 vs 압축의 나란히 미리보기를 보여줍니다, 바이트와 시각적 델타(PSNR, SSIM —— 지각 품질 메트릭) 모두에서 크기와 함께. 품질 슬라이더를 라이브로 조정하고 커밋하기 전에 실시간으로 트레이드오프를 봅니다.
모든 것이 브라우저에서 실행됩니다. 사진은 우리 서버를 포함하여 서버에 업로드되지 않습니다. 인코더는 JPG의 경우 mozjpeg-wasm, WebP의 경우 libwebp-wasm, AVIF의 경우 libavif-wasm입니다 —— 모두 WASM SIMD 가속으로 컴파일된 실제 참조 구현.
방법 2: Squoosh.app(Google의 오픈소스 도구)
매우 정밀한 제어가 필요한 단일 이미지의 경우 Google의 Squoosh.app은 프론트 엔드 커뮤니티에서 가장 사랑받는 도구입니다. 동일한 아키텍처(브라우저의 모든 것), 한 번에 하나의 이미지 UX, 모든 인코더에 대한 매우 세밀한 손잡이. 배치에 더 느립니다(병렬 처리 없음) 그리고 UX는 mozjpeg의 크로마 서브샘플링이 무엇을 하는지 알고 있다고 가정합니다 —— 그러나 드문 "하나의 히어로 이미지를 완벽주의자처럼 조정해야 함"에 대해서는 무적입니다.
방법 3: 빌드 파이프라인의 imagemin
사이트 빌드의 일부로 자동화된 최적화의 경우:
npm install --save-dev imagemin imagemin-mozjpeg imagemin-webp imagemin-avif
# 빌드 스크립트에서
import imagemin from 'imagemin';
import imageminMozjpeg from 'imagemin-mozjpeg';
import imageminWebp from 'imagemin-webp';
await imagemin(['src/images/*.{jpg,png}'], {
destination: 'build/images',
plugins: [
imageminMozjpeg({ quality: 80 }),
imageminWebp({ quality: 80 }),
]
});
이것은 이미지를 자주 업데이트하는 진지한 사이트에 대한 올바른 답입니다 —— 최적화가 모든 빌드를 실행하고, 수동 단계가 없습니다. 일회성 이미지 배치 또는 "사이트에 히어로 이미지 하나를 추가했습니다"의 경우 브라우저 도구가 더 빠릅니다.
방법 4: Next.js / Astro / 프레임워크 내장 이미지 최적화
현대 프레임워크는 "리사이즈 + 폴백이 있는 현대 형식 제공" 파이프라인 전체를 처리하는 내장 이미지 최적화를 제공합니다:
- Next.js:
<Image>컴포넌트가 srcset를 자동 생성하고, JPG 폴백으로 WebP/AVIF를 제공하고, 지연 로드합니다. - Astro:
<Image>컴포넌트가 동일한 작업을 합니다. - Gatsby:
gatsby-plugin-image이 동일한 작업을 합니다. - Cloudflare Images: 변환 URL ——
?width=800&format=auto을 통해 모든 소스 이미지를 제공하고 각 방문자에게 올바른 형식의 올바른 크기를 얻습니다.
새 사이트를 빌드하는 경우 프레임워크의 내장 핸들러를 사용하십시오. 정적 또는 레거시 사이트의 경우 브라우저/CLI 압축이 길입니다.
브라우저 압축기를 어떻게 빌드했는지(기술적 심층 분석)
Ai2Done Image Compress 도구는 세 WebAssembly 인코더 모듈에 빌드되었습니다:
- mozjpeg-wasm(Mozilla의 JPEG 인코더, 같은 품질에서 libjpeg-turbo보다 ~10% 더 나음)
- libwebp-wasm(Google의 참조 WebP 구현)
- libavif-wasm(AV1 이미지 형식 인코더, JPG보다 ~5-10배 느리지만 가장 작은 파일 생성)
디코딩(입력 측)의 경우 JPG, PNG, GIF, WebP, BMP, ICO에 브라우저의 내장 Image 및 createImageBitmap을 사용합니다 —— 추가 종속성 없음. HEIC는 libheif-wasm을 거칩니다(~5 MB 추가 번들, HEIC 업로드가 감지된 경우에만 지연 로드).
흥미로운 디자인 선택: 나란히 라이브 미리보기. 품질 슬라이더를 드래그할 때 두 패널 모두 OffscreenCanvas와 Web Worker의 디바운스된 재인코딩을 사용하여 ~60fps(작은 이미지) 또는 ~10fps(큰 이미지)로 업데이트되므로 UI가 절대 멈추지 않습니다. 이것이 추측-그리고-확인 대신 몇 초 만에 스위트 스폿을 찾을 수 있게 합니다.
배치 작업의 경우 8개 이미지가 8코어 머신에서 병렬로 인코드되도록 navigator.hardwareConcurrency - 1로 크기가 조정된 Web Worker 풀을 사용합니다. AVIF 인코딩은 병목입니다 —— 저사양 기기를 OOM하지 않도록 AVIF의 병렬성을 2로 캡합니다.
FAQ
Q: 항상 모든 것에 AVIF를 사용해야 합니까? A: 항상은 아닙니다. AVIF는 같은 시각적 품질에서 ~50% 더 작은 파일을 제공하지만, 인코딩이 JPG보다 5-10배 더 오래 걸립니다. 정적 트래픽이 많은 페이지의 경우 인코딩 비용은 일회성이고 대역폭 절약은 영원합니다 —— 가치가 있습니다. 동적으로 생성된 이미지(사용자별 콘텐츠, 실시간 미리보기)의 경우 인코딩 비용이 더 중요하고 WebP가 더 나은 거래입니다.
Q: WebP / AVIF가 모든 브라우저에서 작동합니까?
A: WebP는 2020년 이후 출시된 모든 브라우저에서 작동합니다 —— Chrome, Edge, Firefox, Safari 14+, Opera. AVIF는 Chrome, Edge, Firefox 및 Safari 16+에서 작동합니다. Safari <16 방문자(2026년 트래픽의 ~3%)의 경우 <picture><source srcset="hero.avif" type="image/avif"><img src="hero.jpg"></picture>를 통해 JPG 폴백을 제공합니다.
Q: 압축이 EXIF / GPS / 카메라 데이터를 제거합니까? A: 기본적으로 도구는 모든 메타데이터를 제거합니다(더 작은 파일, GPS 누출 없음). 카메라 설정이나 방향 태그를 유지하려면 "Preserve EXIF"를 토글하십시오. 공개적으로 공유할 이미지의 경우 기본 제거가 올바른 선택입니다 —— 소셜로 공유된 사진의 GPS 메타데이터는 실제 프라이버시 사건을 일으켰습니다.
Q: JPG 품질 80과 JPG 품질 90의 차이점은 무엇입니까? A: 품질 90에서는 파일이 대부분의 사진에서 시각적으로 동일한 출력에 대해 품질 80보다 ~50% 더 큽니다. 품질 80은 보편적인 "4배 확대하지 않으면 차이를 볼 수 없는" 스위트 스폿입니다. 다운스트림에서 다시 편집될 이미지에만 90+를 사용하십시오(각 편집 패스가 품질 손실을 추가합니다; 품질 90에서 시작하면 더 많은 여유 공간이 제공됩니다).
Q: 사진을 JPG 품질 80으로 압축하면 내 SEO에 해가 됩니까? A: 반대입니다 —— 더 빠른 페이지 로드가 SEO를 개선합니다. Google의 Core Web Vitals(특히 LCP)이 순위에 영향을 미칩니다. 이미지 무게는 일반적으로 느린 LCP의 #1 원인입니다. 50% 더 작은 히어로 이미지는 종종 0.5초 더 빠른 LCP를 의미하며, Google이 보상합니다.
Q: 전자 상거래 사이트에 대한 1000개의 제품 사진이 있습니다. 모두 배치할 수 있습니까?
A: 예, 그러나 브라우저 메모리 압력을 피하기 위해 50-100의 배치로 나누십시오. 100개의 이미지를 드롭하고, ZIP을 받고, 반복하십시오. 자동화된 파이프라인의 경우 빌드에서 imagemin을 설정하십시오(방법 3 참조).
지금 시도
나란히 미리보기로 몇 초 만에 웹용 이미지를 압축하십시오:
이미지를 드롭하고, 형식을 선택하고, 품질 슬라이더를 드래그하고, 바이트가 떨어지는 것을 지켜보십시오. 업로드 없음, 가입 없음.
관련 읽기
- HEIC를 JPG로 변환: 모든 기기에서 올바른 방법 —— 압축 전에 형식 변환이 필요한 iPhone 사진용
- 브라우저 측 AI로 이미지를 4배 업스케일(가입 없음) —— 더 적은 픽셀이 아니라 더 많은 픽셀이 필요할 때
- 이미지 OCR: 100+ 언어로 모든 사진에서 텍스트 추출
- 메인 사이트에서 모든 이미지 도구 둘러보기
최종 업데이트 2026-06-14. Image Compress 도구는 브라우저에서 100% 실행됩니다 —— 사진은 기기를 떠나지 않습니다. 처리하는 파일을 절대 수집, 로깅 또는 분석하지 않습니다.