웹용 이미지 압축하는 방법
이미지 용량의 대부분은 인코더가 동작하기 훨씬 전에 이미 낭비됩니다. 실제로 바이트를 줄여 주는 작업 순서와, 신경 쓸 만한 설정을 정리했습니다.
이미지 용량이 중요한 이유
대부분의 사이트에서 이미지는 페이지 용량의 가장 큰 단일 원인입니다. 스크립트, 스타일, 폰트를 모두 합친 것보다 큰 경우도 흔합니다. 여기에는 두 가지 결과가 따릅니다. 첫째, 모바일 데이터로 접속한 방문자는 더 오래 기다리고 그 대가를 요금으로 치릅니다. 둘째, 이미지 용량은 Largest Contentful Paint에 그대로 반영됩니다. 페이지에서 가장 큰 요소가 보통 대표 이미지이기 때문에, 성능 점수가 나쁠 때 가장 자주 원인으로 지목되는 Core Web Vital입니다.
좋은 소식은 이미지 용량이 가장 고치기 쉬운 부분이라는 점입니다. 여기 있는 어떤 것도 빌드 파이프라인을 새로 짤 필요가 없습니다.
영향이 큰 순서대로 진행하기
압축 도구는 품질 슬라이더부터 잡게 만듭니다. 하지만 그건 세 가지 지렛대 중 가장 작은 것입니다. 순서는 이래야 합니다:
- 크기 조정 — 압도적으로 가장 큰 효과.
- 포맷 선택 — 크지만 한 번뿐인 효과.
- 품질 설정 — 세밀 조정, 효과는 실제로 있지만 한계가 있습니다.
1. 먼저 크기를 줄이세요
4000픽셀 폭 사진을 800픽셀 폭 자리에 넣으면, 보여줄 수 있는 양의 약 25배에 달하는 픽셀을 나르게 됩니다. 어떤 코덱도 그 차이를 메우지 못합니다. 과대한 이미지를 내보낸 뒤 세게 압축하는 것이 전형적인 실수입니다. 비용은 두 번 치르고, 실제로 보이는 결과는 처음부터 제대로 크기를 줄인 것보다 나쁩니다.
실제 표시 크기에 맞춰 줄이고, 중요한 이미지라면 고밀도 화면을 위해 두 배로 잡으세요. 경험상 전체 폭 대표 이미지는 2000픽셀 폭을 넘길 일이 거의 없고, 본문 안의 이미지는 1200을 넘길 일이 거의 없습니다.
2. 포맷을 고르세요
사진은 AVIF나 WebP로 보내야 합니다. 날카로운 경계, 텍스트, 투명도가 있는 그래픽은 PNG나 무손실 WebP로 남겨야 합니다. 포맷 가이드에 그 절충이 자세히 나와 있습니다. 짧게 말하면 포맷 선택은 이미지 종류별 결정이지, 전체 일괄 결정이 아닙니다.
3. 품질을 설정하세요
손실 포맷에서 품질은 충실도와 용량을 맞바꾸는 0–100 다이얼입니다. 선형이 아닙니다. 90에서 80으로 내리면 눈에 띄는 차이 없이 파일의 3분의 1이 줄어드는 경우가 많지만, 50에서 40으로 내리면 대개 보이는 아티팩트만 늘어납니다.
합리적인 출발점은 다음과 같습니다:
| 내용 | 대략적인 목표 | 설명 |
|---|---|---|
| 웹용 사진 | JPEG/WebP 품질 ~75 | 일반적인 최적점이며, AVIF는 더 낮은 값에서 비슷한 품질에 도달합니다 |
| 썸네일, 아바타 | 품질 60–70 | 표시 크기가 작으면 생각보다 많은 결함이 가려집니다 |
| 스크린샷, UI, 텍스트 | 무손실(PNG / 무손실 WebP) | 손실 압축은 1픽셀 경계와 글자를 번지게 만듭니다 |
| 보관 / 인쇄 | 품질 90+, 또는 원본 | 원본을 보관하세요. 웹 전달 시나리오가 아닙니다 |
확대해서가 아니라 표시 크기에서 판단하세요. 압축본과 원본을 실제로 나타날 크기로 비교하세요. 400% 확대에서 눈에 확 띄는 차이도 실제 맥락에서는 대개 보이지 않습니다.
확장되는 배치 작업 흐름
- 스크린샷, 사진, 내보낸 파일을 한 폴더에 모으세요.
- 두 그룹으로 나누세요: 사진형과 그래픽형. 포맷과 설정이 서로 다릅니다.
- 각 그룹을 전송 크기에 맞춰 조정하세요.
- 사진형 그룹은 AVIF와 WebP로, 그래픽형 그룹은 무손실로 압축하세요.
- 각 결과를 원본과 비교하세요. 더 커진 것은 버립니다. 그건 실패가 아니라 신호입니다.
- 원본을 보관하세요. 압축 결과물은 빌드 산출물이고, 원본이 아카이브입니다.
tinyimg는 한 번에 최대 30개 파일까지 4단계와 5단계를 처리하고, 한 번의 실행으로 여러 포맷을 출력해 용량을 직접 비교할 수 있습니다. 브라우저에서 일괄 처리한다는 것은 고객이나 개인 사진 폴더가 기기를 떠나지 않는다는 뜻이기도 합니다. 업로드 정책이 고려 사항이라면 충분히 값진 장점입니다.
조용히 바이트를 가장 많이 낭비하는 실수
- 모든 기기에 같은 큰 이미지를 보내기. 2000픽셀 JPEG 한 장은 반응형 전략이 아닙니다.
srcset을 써서 휴대폰이 더 작은 버전을 받게 하세요. - JPEG를 반복 저장하기. 손실 세대가 쌓일수록 손상도 누적됩니다. 항상 원본에서 다시 인코딩하세요.
- 사진에 PNG 쓰기. 같은 내용의 JPEG보다 5–10배 큰 경우가 흔한데, 보이는 이점은 없습니다.
- 쓸모의 한계를 넘어 「최소 용량」을 좇기. 40% 절감은 훌륭합니다. 하늘에 계단 현상이 보이는 45%는 아닙니다.
- 지연 로딩을 잊기. 첫 화면 아래 이미지가 첫 페인트를 막아서는 안 됩니다. 지연 로딩은 속성 하나만 바꾸면 되고 효과는 큽니다.
- 다시 측정하지 않기. 예산을 정하고 확인하세요. 그러지 않으면 자산 하나씩 늘어납니다.
끝났는지 판단하는 법
페이지 예산을 정하고 지키세요. 콘텐츠 페이지라면 전체 이미지 용량을 대략 1메가바이트 아래로 유지하는 것이 합리적인 목표이고, 대표 이미지가 가장 큰 몫을 담당합니다. 페이지가 그 기준을 크게 넘는다면 흔한 원인은 크기를 줄이지 않은 대표 이미지, PNG로 저장한 사진, 또는 SVG나 CSS로 대체할 수 있는 장식용 이미지 몇 장입니다.
화려하진 않지만 짧은 작업입니다. 크기를 조정하고, 포맷을 고르고, 적당한 품질을 정하고, 표시 크기에서 확인하고, 원본을 보관하세요. 이 순서만 지키면 거의 모든 사이트에서 피할 수 있었던 이미지 용량의 대부분이 사라집니다.