도구

웹사이트를 더 빠르게:이미지 파일 크기를 줄이는 방법

무거운 이미지는 사이트가 느리다고 느껴지는 가장 큰 이유입니다. 일반적인 상품 페이지나 마케팅 페이지는 2 MB가 넘는 무게를 내보내고, 그 절반쯤이 이미지입니다 — 그것도 원본 해상도, 원본 품질, 잘못된 포맷 그대로. 파일이 커지면 Largest Contentful Paint가 2.5초 목표를 넘기고, 이탈률은 올라가고, 전환은 조용히 새어나갑니다 — 히어로 이미지에 100 KB가 더 붙을 때마다 모바일과 데스크탑 양쪽에서 측정이 가능한 만큼의 참여도가 깎입니다. 이번 분기에 성능 점검을 딱 한 번만 한다면, 이미지에 하세요.

무거운 이미지가 페이지를 망치는 이유

Google의 Core Web Vitals는 페이지에서 가장 큰 이미지를 Largest Contentful Paint 요소로 다룹니다. 현재의 「Good」 임계치는 실사용자 75 백분위에서2.5초 미만입니다. HTTP Archive는 데스크탑 페이지의 중앙 값을 약 2.5 MB, 모바일은 약 2.2 MB이라 고 보고하고, 이미지가 그 무게의 거의 50%를 꾸준히 차지 합니다. 따라서 1.2 MB짜리 히어로 사진 한 장이, 당신의 LCP 점수가 초록·노랑·빨강 어느 쪽인지 — 정성 들여 짠 JavaScript가 돌아가기 전에 — 정해버릴 수 있습니다.

비즈니스 측면도 분명합니다. Google 자체의 연구는 모바일 로딩 시간 1초 개선을 소매·여행·리드젠 사이트 전반에서 전환율 상승에 연결합니다. 불안정한 4G 환경에서 600 KB 이미지와 60 KB 이미지는 거의 다른 제품처럼 느껴집니다 — 전자는 끊기듯 스크롤인되고, 후자는 즉시 그려집니다. 이미지 파일 크기를 줄이는 건 지금 가장 싼 성능 개선 수단입니다 — 서버 측 재작성도, 아키텍처 변경도 필요 없고, 단지 처음부터 굳이 보내지 않아도 됐던 바이트를 덜 보내면 됩니다.

4단계 축소 파이프라인

이미지 최적화 서비스나 빌드 파이프라인이 꼭 필요한 건 아닙니다. 모든 현대 이미지 CDN이 안에서 돌리는 바로 그 단계를 브라우저에서 한 장씩, 1분 안에 돌릴 수 있습니다. 각 단계가 앞 단계에 의존하니 이 순서대로 따라 주세요.

단계	동작	일반적인 절감
1. 표시 크기로 리사이즈	비트맵을 레이아웃이 실제로 렌더링하는 최대 크기로 축소합니다. 4000×3000 사진을 1200×600 슬롯에 넣으면 픽셀의 90% 이상이 낭비입니다.	60–80%
2. 품질을 75–80 정도로	인코더의 품질 슬라이더를 사진이라면 75–80 부근으로 내립니다. 일반 시청 거리에서 화질 차이는 거의 보이지 않으면서 바이트는 크게 줄어듭니다.	30–50%
3. WebP로 변환	리사이즈·재양자화된 비트맵을 WebP로 다시 부호화합니다. 같은 크기, 같은 품질에서 보통 원본 JPG/PNG의 3분의 1 바이트.	25–35%
4. 메타데이터 제거	EXIF, IPTC, XMP, 컬러 프로파일, 작성자 주석을 제거합니다. 폰 사진 한 장은 브라우저가 그리지 않는 메타데이터를 50–100 KB 데리고 다닙니다.	2–10%

네 단계를 겹치면 1.2 MB 원본을 150 KB 아래로 줄이는 것이 일반적입니다. 일반적인 웹 시청 크기에서 보이는 화질 손실은 없습니다.

포맷별 가이드

시각적 작업이 다르면 필요한 포맷도 다릅니다. 습관이 아니라 내용으로 고르세요.

사진.JPG 품질 75–80, 또는 같은 품질의 WebP. AVIF가 더 줄여 주지만 인코딩 시간이 길고 구형 기기 일부에서 지원되지 않습니다 — 호환성이 중요하면 WebP로 fallback.
로고, 아이콘, UI 그래픽.투명도는 PNG로 유지하거나, 더 좋은 선택으로 알파 채널이 있는 WebP를 쓰세요. 원본이 벡터라면 SVG가 더 작고 래스터 아티팩트 없이 무한히 확대할 수 있습니다.
일러스트와 플랫 아트.WebP 또는 PNG. WebP는 바이트 수에서, PNG는 폭넓은 호환성에서 이깁니다. 둘 다 필요하면 picture 요소로 WebP를 내고 PNG를 폴백으로 두세요.

폴더째 묶인 오래된 자산을 다른 포맷으로 옮기고 싶다면?이미지 변환기는 JPG·PNG·WebP·AVIF로의 일괄 재부호화를 한 번에 처리하고, 미리 보기를 나란히 보여 주므로 확정하기 전에 화질 트레이드오프를 확인할 수 있습니다.

예산 세우기

예산 없는 최적화는 그저 조금 더 작은 이미지를 만들어 냅니다. 페이지의 각 카테고리에 단단한 바이트 상한을 정하고, CI에서 강제하면, 페이지 평균 무게가 무너지는 걸 보게 됩니다. 콘텐츠 중심의 사이트에 쓸 만한 출발 예산:

히어로 이미지:100 KB 이하.당신의 LCP 요소입니다. 더 무겁다면 Core Web Vitals에 값을 치르는 셈입니다.
갤러리 썸네일:각 50 KB 이하.첫 화면의 썸네일 개수를 곱하면, 방어 가능한 예산이 됩니다.
Open Graph 이미지:200 KB 이하.크롤러와 SNS 미리보기는 이것을 반복해서 다시 가져옵니다. 빡빡한 상한이 링크 언펄을 깔끔하게 유지합니다.
첫 화면 전체 이미지:300 KB 이하.이걸 넘으면 아무리 code-splitting해도 LCP 점수를 살리지 못합니다.

4단계 파이프라인을 한 번 돌리고, 출력물을 위의 예산에 붙여 넣고, 출시 하세요. 더 빠른 페이지, 더 나은 Core Web Vitals, 더 기분 좋은 방문자 — 그리고 잘라 낸 1바이트는 보내는 데 비용을 내지 않는 1바이트입니다.