왜 이미지 최적화가 검색에 영향을 주나
Google은 LCP(최대 콘텐츠 렌더링)를 Core Web Vitals의 하나로 씁니다. 그리고 LCP를 결정하는 요소는 화면 상단의 큰 이미지인 경우가 대부분입니다. LCP가 느리면 순위에 직접 영향을 받습니다.
사용자 쪽도 마찬가지입니다. 로딩이 100ms 늦어질 때마다 전환율이 약 1% 떨어진다는 관찰이 반복적으로 보고됩니다. 이미지는 그중 가장 크고 가장 손대기 쉬운 부분입니다.
1단계: 포맷을 제대로 고르기
| 포맷 | 적합한 용도 | 손실 압축 | 투명도 |
|---|---|---|---|
| WebP | 사진, UI 이미지 | 둘 다 지원 | 있음 |
| AVIF | 사진 (최신 환경) | 둘 다 지원 | 있음 |
| PNG | 스크린샷, 무손실 | 무손실만 | 있음 |
| JPG | 구형 호환용 | 손실만 | 없음 |
| SVG | 아이콘, 로고, 일러스트 | 해당 없음 | 있음 |
WebP를 기본값으로. 같은 시각적 품질에서 JPEG나 PNG보다 25~35% 작고, 브라우저 지원은 97%를 넘어 실무적으로 보편적입니다.
AVIF는 한 단계 더. WebP보다 다시 20~30% 작습니다. 지원율이 약 94%이므로 <picture>로 대체를 두고 쓰세요.
PNG는 무손실이 꼭 필요할 때만. 글자가 있는 스크린샷, 가장자리가 선명해야 하는 로고입니다. 사진에는 절대 쓰지 마세요.
SVG는 도형으로 그릴 수 있는 모든 것. 무한히 확대되고 CSS로 제어됩니다. 다만 Figma나 Illustrator가 내보낸 원본에는 불필요한 마크업이 가득하니 반드시 최적화를 거치세요.
2단계: 과감하게 압축하기
JPEG와 WebP의 적정 구간은 품질 75~85%입니다. 그보다 낮추면 아티팩트가 보이기 시작하고, 높여도 용량만 늘 뿐 눈에 띄는 개선이 없습니다. 대부분의 사진은 80%에서 100%와 육안으로 구분되지 않습니다.
어디에서 먼저 티가 나는지 알아두면 판단이 쉽습니다. 하늘, 그라데이션, 단색 벽처럼 넓고 부드러운 면이 가장 먼저 무너집니다. 그런 이미지라면 한 단계 높게 잡으세요.
3단계: 표시 크기로 리사이즈하기
400px 폭의 칸에 4000×3000 이미지를 넣지 마세요. 브라우저는 화면에 4분의 1만 보여주더라도 모든 픽셀을 내려받고 디코딩해야 합니다.
기준은 간단합니다. CSS 픽셀 크기의 2배로 내보내면 고밀도 화면에서도 선명하고 용량은 합리적입니다. 800px 자리라면 1600px입니다.
순서도 중요합니다. 압축보다 리사이즈를 먼저 하세요. 크기를 줄이는 것만으로 압축보다 훨씬 큰 절약이 나오는 경우가 많습니다.
4단계: 지연 로딩 쓰기
화면 아래에 있는 이미지에는 loading="lazy"를 붙이세요. 브라우저 기본 기능이라 자바스크립트가 필요 없습니다. 사용자가 그 위치까지 스크롤하기 전에는 내려받지 않습니다.
<img
src="hero.webp"
width="800"
height="450"
alt="대시보드 화면"
loading="lazy"
decoding="async"
/>예외가 하나 있습니다. 히어로 이미지나 첫 화면에 보이는 이미지에는 절대 쓰지 마세요. 오히려 LCP가 나빠집니다.
5단계: width와 height를 반드시 넣기
<img>에 width와 height를 명시하면 브라우저가 이미지가 도착하기 전에 자리를 잡아 둡니다. 이것 하나로 CLS(누적 레이아웃 이동) 문제 대부분이 사라집니다.
CSS로 크기를 조절하더라도 속성은 넣어야 합니다. 브라우저는 두 숫자에서 종횡비를 계산해 공간을 예약합니다.
6단계: 히어로 이미지는 미리 불러오기
LCP를 결정하는 이미지는 지연 로딩의 반대가 필요합니다.
<link rel="preload" as="image" href="hero.webp"
fetchpriority="high">이렇게 하면 브라우저가 HTML을 다 훑기 전에 그 이미지를 먼저 요청합니다. 히어로 하나에만 쓰세요. 여러 개에 붙이면 서로 경쟁해서 효과가 사라집니다.
7단계: 반응형 이미지로 기기별 크기 주기
<img
src="photo-800.webp"
srcset="photo-400.webp 400w,
photo-800.webp 800w,
photo-1600.webp 1600w"
sizes="(max-width: 600px) 100vw, 800px"
width="800" height="450"
alt="설명">모바일 사용자가 데스크톱용 이미지를 내려받지 않게 됩니다. 트래픽의 상당수가 모바일이라면 이 한 가지가 가장 큰 절약일 수 있습니다.
흔한 실수
- 사진을 PNG로 저장 — 가장 흔하고 가장 비싼 실수입니다. 용량이 몇 배가 됩니다.
- 히어로에 지연 로딩 — LCP를 개선하려다 악화시킵니다.
- 측정 없이 최적화 — 병목은 대개 예상과 다릅니다. PageSpeed Insights로 먼저 확인하세요.
- WebP로 바꾼 뒤 다시 PNG로 편집 — 손실 변환을 반복하면 품질이 계속 떨어집니다. 원본을 보관하고 WebP는 배포용으로만 쓰세요.
자주 묻는 질문
- 어느 단계부터 하는 게 효과가 큰가요?
- 보통 3단계(리사이즈)와 5단계(width/height)입니다. 리사이즈는 용량을 가장 크게 줄이고, 크기 명시는 CLS를 거의 공짜로 해결합니다.
- 이미지를 브라우저에서 처리하면 화질이 떨어지나요?
- 아닙니다. 브라우저 도구도 서버와 동일한 코덱을 WebAssembly로 실행합니다. 같은 설정이면 결과물도 같습니다.
- CDN을 쓰면 최적화가 필요 없나요?
- CDN은 전달 거리를 줄일 뿐 파일 자체를 작게 만들지는 않습니다. 실시간 변환 기능이 있는 CDN이 아니라면 최적화는 여전히 필요합니다.
- alt 텍스트도 성능에 영향이 있나요?
- 성능에는 없지만 접근성과 이미지 검색에는 큽니다. 장식용 이미지는
alt=""로 비우고, 의미 있는 이미지는 내용을 설명하세요.