이미지 용량 최적화 가이드: LCP·반응형 전송·화질로 예산 정하기
대표 이미지와 본문·썸네일을 구분해 적절한 픽셀 크기와 포맷을 제공하고 최적화 전후의 전송량·화질·Core Web Vitals를 검증하는 실무 가이드입니다.
웹 이미지에 “본문은 100KB, 대표 이미지는 300KB” 같은 보편적인 정답은 없습니다. 필요한 시각 품질, 실제 표시 크기, 사용자의 네트워크, 캐시와 이미지가 LCP 요소인지에 따라 허용 전송량이 달라집니다. 고정 KB 목표는 출발점일 수 있지만 최종 판단은 실제 페이지 성능으로 해야 합니다.
이미지 예산을 정하는 다섯 요소
| 요소 | 질문 |
|---|---|
| 표시 크기 | CSS에서 실제 몇 픽셀로 보이는가 |
| 해상도 | 고밀도 화면에 필요한 후보는 무엇인가 |
| 내용 | 사진·도표·로고·스크린샷 중 무엇인가 |
| 우선순위 | 첫 화면 LCP 후보인가, 아래쪽 이미지인가 |
| 화질 | 압축 뒤 텍스트·제품 세부가 유지되는가 |
픽셀 크기를 먼저 줄입니다
본문에서 최대 800px로 보이는 사진에 4000px 원본 하나만 보내면 브라우저가 축소하더라도 전송 비용은 그대로입니다. 표시 폭에 맞춘 여러 크기를 만들고 srcset과 sizes로 선택하게 합니다.
<img
src="guide-800.webp"
srcset="guide-480.webp 480w, guide-800.webp 800w, guide-1200.webp 1200w"
sizes="(max-width: 720px) 100vw, 800px"
width="800"
height="450"
alt="이미지 최적화 전후 전송량 비교 표">콘텐츠 유형에 맞는 포맷을 선택합니다
| 유형 | 후보 | 주의점 |
|---|---|---|
| 사진 | AVIF·WebP·JPEG | 인코딩 비용·브라우저 폴백 |
| 투명 이미지 | WebP·PNG·AVIF | 반투명 가장자리 품질 |
| 로고·아이콘 | SVG | 신뢰할 수 없는 SVG 보안 |
| 텍스트 스크린샷 | WebP·PNG | 글자 흐림·색 번짐 |
새 포맷이 항상 더 작거나 더 좋은 것은 아닙니다. 같은 시각 품질에서 후보를 비교하고 원본 포맷보다 커지면 사용하지 않습니다.
LCP 이미지는 지연 로딩하지 않습니다
첫 화면의 가장 큰 대표 이미지가 LCP 후보라면 무조건 loading="lazy"를 적용하지 않습니다. 필요한 경우 우선순위를 높이고 HTML에서 일찍 발견되도록 합니다. 아래쪽 이미지는 지연 로딩으로 초기 전송을 줄일 수 있습니다.
width·height로 레이아웃 공간을 예약합니다
파일 용량만 줄여도 이미지가 로드될 때 공간이 없으면 CLS가 발생할 수 있습니다. 이미지 고유 비율을 알려 주는 width·height 또는 CSS aspect-ratio를 지정합니다.
전송량과 디코딩 비용을 함께 봅니다
- HTML·CSS·JS와 이미지가 경쟁하는 초기 요청 수
- CDN 캐시 적중률과 지역별 응답 시간
- 모바일 저속 네트워크에서 이미지 다운로드 시간
- 대형 이미지의 메모리·디코딩 시간
- 실제 사용자 LCP 75퍼센타일과 실험실 진단
최적화 전후 검증 절차
- 가장 큰 전송 이미지와 LCP 요소를 찾습니다.
- 픽셀 크기·포맷·압축 중 하나를 먼저 바꿉니다.
- 화질을 원본과 확대 비교합니다.
- PageSpeed와 브라우저 네트워크 패널을 확인합니다.
- 충분한 실제 사용자 데이터가 쌓인 뒤 LCP·CLS 변화를 봅니다.
검색 순위 변화를 이미지 한 항목의 직접 효과로 단정하지 않습니다. 이미지 최적화의 우선 목적은 사용자 경험과 전송 비용 개선입니다.
이미지 예산을 페이지 전체 예산 안에서 봅니다
이미지만 줄였지만 JavaScript·폰트·광고가 초기 네트워크를 점유하면 LCP가 크게 좋아지지 않을 수 있습니다. 대표 페이지별 전체 전송량과 요청 우선순위를 확인하고 가장 큰 병목부터 수정합니다. 이미지 하나의 목표 KB를 달성하는 데 집착하지 마세요.
CMS 자동 생성본을 정기 점검합니다
워드프레스와 이미지 CDN은 여러 크기·포맷을 자동 생성할 수 있지만 테마의 sizes가 실제 레이아웃과 맞지 않으면 큰 후보가 선택될 수 있습니다. 업로드 원본, 생성된 변형, HTML 속성과 실제 네트워크 요청을 표본 페이지에서 확인합니다.
품질 저하 허용 범위를 콘텐츠 소유자가 승인합니다
자동 압축률 하나를 모든 이미지에 적용하면 제품 사진·작품·텍스트 스크린샷에서 중요한 정보가 사라질 수 있습니다. 이미지 유형별 품질 기준과 확대 검사 방법을 정하고, 원본을 보관한 상태에서 파생본만 교체합니다. 성능 개선 때문에 독자가 내용을 오해하면 최적화에 실패한 것입니다.
이미지 용량이 작아져도 LCP가 느린 경우
대표 이미지를 압축했는데 화면의 큰 이미지가 늦게 나타난다면 파일 크기만 원인은 아닐 수 있습니다. HTML에서 이미지를 늦게 발견하거나, 초기 응답이 느리거나, 필요한 이미지를 지연 로딩하고 있을 수 있습니다. 화면의 주된 LCP 이미지와 아래쪽 본문 이미지를 같은 방식으로 처리해서는 안 됩니다.
Google의 이미지 최적화 권장사항은 품질과 속도를 함께 고려하고 srcset과 sizes를 통한 반응형 전달을 설명합니다. 작은 모바일 화면에 데스크톱용 초대형 이미지를 매번 보내는 상황이라면 포맷 변경보다 표시 크기와 전송 대상부터 점검해야 합니다.
가장 용량이 적은 파일이 언제나 가장 좋은 파일은 아닙니다. 글자가 깨지거나 정보가 읽히지 않으면 사용자에게 필요한 콘텐츠가 사라집니다. 실제 페이지에서 시각적 품질과 성능을 함께 검증하세요.
공식 확인 자료
이미지 예산은 파일 하나의 KB 목표가 아니라 페이지의 실제 표시 크기, 시각 품질과 LCP·CLS 결과를 함께 만족하도록 정해야 합니다.