이미지가 페이지 용량의 70%를 차지한다
평균적인 웹페이지 다운로드 용량의 약 70%는 이미지입니다. 이미지 한 장의 처리 방식이 페이지 속도, 모바일 데이터 사용량, 검색 순위를 모두 결정합니다.
아임웹·카페24는 사용자가 업로드한 원본 이미지를 그대로 사용자에게 전송합니다. 4000×3000px 사진을 올리면 모바일에서도 그대로 4000×3000px 파일이 다운로드됩니다. Next/Image는 정반대로 동작합니다.
Next/Image가 자동으로 처리하는 4가지
1. 포맷 자동 변환: 사용자 브라우저가 AVIF를 지원하면 AVIF로, 그다음 WebP, 마지막 JPG 순으로 가장 가벼운 포맷을 선택합니다. AVIF는 JPG 대비 평균 50% 가볍습니다.
2. 화면 크기별 srcset: 모바일(390px), 태블릿(768px), 데스크톱(1920px)용 이미지를 자동으로 생성하고, 사용자 화면에 맞는 크기만 다운로드합니다.
3. Lazy Loading: 화면에 보이지 않는 이미지는 스크롤이 닿기 직전까지 로드를 미룹니다. 첫 페이지 로딩 시간을 크게 줄입니다.
4. CDN 캐싱: 변환된 이미지는 Vercel·Cloudflare 같은 글로벌 CDN에 저장되어 다음 사용자는 즉시 받습니다.
빌더가 이 작업을 못 하는 이유
1. 서버 권한 부재: 이미지 포맷 변환은 서버에서 처리해야 합니다. 빌더는 사용자에게 서버 영역을 열어주지 않습니다.
2. CDN 분리 불가: 빌더는 모든 트래픽을 자사 인프라로 처리합니다. 외부 CDN을 끼울 수 없어 글로벌 응답 속도가 느립니다.
3. 압축 정책 고정: 빌더가 정한 압축 수준(보통 품질 80%)만 적용 가능. 페이지 성격별로 압축 강도를 다르게 설정할 수 없습니다.
4. 캐시 무효화 어려움: 이미지를 교체해도 캐시가 즉시 갱신되지 않아 잘못된 이미지가 며칠 동안 노출되는 사례가 있습니다.
실제 용량 비교
같은 제품 사진(2400×1600px, 원본 1.8MB)을 양쪽에서 서빙하면 결과가 다릅니다.
| 항목 | 빌더(아임웹) | 풀스택(Next/Image) |
|---|---|---|
| 모바일 다운로드 용량 | 1.8MB | 86KB |
| 포맷 | JPG 원본 | AVIF 자동 |
| 화면 크기별 분기 | 없음 | 3종 srcset |
| Lazy loading | 일부 | 자동 |
| CDN 응답 시간 | 200~400ms | 30~80ms |
같은 페이지의 이미지 12장을 띄울 때 빌더는 약 21MB, 풀스택은 약 1MB를 전송합니다. 20배 차이입니다.
데이터 비용·이탈률·검색 순위가 동시에 움직인다
모바일 사용자가 LTE 환경에서 1MB와 21MB를 받는 차이는 데이터 요금만의 문제가 아닙니다. 21MB는 사용자가 다 받기 전에 페이지를 닫을 확률이 매우 높고, LCP가 4초를 넘기면 구글 검색 순위가 직접 떨어집니다.
치로웹디자인은 모든 이미지를 Next/Image + AVIF + CDN 조합으로 서빙합니다. 빌더 사이트의 이미지 무거움이 매출에 영향을 주고 있다면, 풀스택 전환이 가장 직접적인 해결책입니다. 치로의 홈페이지 제작 서비스에서 적용 사례를 확인할 수 있습니다. 사이트 속도 전반은 사이트 속도 최적화 가이드에서 더 다룹니다.
자주 묻는 질문
아임웹에서 이미지 압축 플러그인을 쓰면 비슷해지나요? 일부 압축은 가능합니다. 다만 AVIF 자동 변환, 화면 크기별 srcset 자동 생성, CDN 글로벌 캐싱은 빌더 구조상 불가능합니다. 한 단계 압축만 적용 가능합니다.
Next/Image를 쓰면 운영자가 이미지를 따로 가공해야 하나요? 아닙니다. 원본 이미지를 업로드하면 변환·축소·포맷 선택을 모두 시스템이 처리합니다. 운영자는 원본만 올리면 됩니다.
기존 빌더 사이트의 이미지를 그대로 풀스택으로 옮길 수 있나요? 가능합니다. 마이그레이션 시 원본 이미지를 모두 가져와 Next/Image에 등록하면 자동으로 모든 최적화가 적용됩니다. 작업 시간은 이미지 수에 따라 다르지만, 사이트 전체 기준 평균 1~2일이 추가됩니다.