웹사이트 이미지 최적화 실전 가이드

이미지는 페이지 전송의 큰 부분인 경우가 많고 발견, 디코딩, 레이아웃, Largest Contentful Paint에도 영향을 줍니다. 최적화는 의미 있는 개선을 만들지만 고정 절감량이나 순위 결과가 모든 페이지에 적용되지는 않습니다. 단계마다 측정할 수 있는 흐름입니다.

이미지 최적화가 그 어느 때보다 중요한 이유

HTTP Archive 페이지 무게 보고서는 중앙값이 변해도 많은 페이지에서 이미지가 중요함을 보여 줍니다. Largest Contentful Paint (LCP)는 뷰포트에서 가장 큰 대상 요소가 렌더되는 때를 재며, 흔히 이미지지만 항상 그런 것은 아닙니다.

Google의 LCP 기준은 방문 75백분위에서 2.5초 이하를 좋음, 4초 초과를 나쁨으로 봅니다. LCP 자원이 병목이면 이미지 작업으로 기준 사이를 이동할 수 있지만 그것만으로 Core Web Vitals 통과나 검색 위치를 보장하지 않습니다.

1단계: 올바른 포맷 선택

형식 선택은 크기와 기능에 큰 영향을 줍니다. 다음 비교는 정성적이며 결과는 원본, 인코더, 설정, 품질 목표에 달려 있습니다.

WebP는 유용한 기본 후보이지 만능 답은 아닙니다. 흐름과 사용자가 AVIF를 지원하면 WebP나 JPEG 대체 형식과 함께 앞선 <source>로 시험하세요. Vizua에서 JPG를 WebP로 또는 AVIF로 바꿀 수 있고 파일은 브라우저에서 처리되어 서버로 전송되지 않습니다.

자세한 내용은 WebP와 AVIF 비교 및 손실·무손실 압축을 참고하세요.

2단계: 실제 표시 크기에 맞게 리사이즈

4000 × 3000픽셀 사진을 800 × 600으로 표시하면 슬롯보다 훨씬 많은 원본 픽셀이 있습니다. 고밀도 반응형 화면은 더 큰 후보가 필요할 수 있지만 카메라 원본 전송은 보통 불필요한 전송과 디코딩을 늘립니다.

원칙은 렌더 크기와 밀도에 가까운 후보를 제공하는 것입니다. srcset과 sizes로 브라우저가 고르게 하고 고정 “Retina” 배수 대신 레이아웃 폭, 기기 밀도, 품질, 확대, 아트 디렉션을 고려하세요.

레이아웃에 맞출 시작 크기 예시:

• 전체 폭 히어로: 가장 큰 렌더 슬롯에서 시작해 관련 밀도와 브레이크포인트 후보 생성
• 본문 이미지: 콘텐츠 열과 더 넓은 반응형 상태에 맞춤
• 썸네일: 히어로를 재사용하지 말고 각 카드 크기에 가까운 후보 생성
• 아바타: 표시 원·사각형, 기기 밀도, 상세 프로필 고려

압축 전 Vizua 이미지 크기 조정으로 적절한 후보를 만드세요. 절감량은 원본과 목표 픽셀 수에 달려 있으므로 파일을 측정합니다.

3단계: 적절한 품질로 압축

형식과 크기를 정한 뒤 인코더를 조정합니다. 품질 척도는 비선형이고 인코더나 형식 간 표준이 아닙니다. 손실 인코더에서 낮은 값은 보통 더 많은 정보를 덜어 바이트를 줄이지만 크기와 시각 변화는 실제 출력에서 측정합니다.

권장 품질 설정:

• JPEG: 75–85는 사진의 보수적 시작 범위입니다. 척도가 다르므로 출력을 확인하세요.
• WebP: 75–80은 시작 범위이며 JPEG 값과 같다고 보장되지 않습니다.
• AVIF: 일부 도구에서 60–75로 시작할 수 있으나 척도와 인코더가 다릅니다.
• PNG: 먼저 더 강한 무손실 압축을 시험하세요. 팔레트를 최대 256항목으로 줄이면 더 절약될 수 있지만 손실 색상 감소이므로 확인합니다.

Vizua JPEG 압축기는 품질 조정과 출력 검토를 지원합니다. 자세한 방법은 화질을 잃지 않는 압축을 보세요.

4단계: 이미지를 효율적으로 전달하기

좋은 압축은 절반에 불과합니다. 이미지를 브라우저에 어떻게 전달하느냐가 성능에 똑같이 중요합니다.

명시적 치수 설정

각 <img>에 정확한 고유 width와 height를 주거나 레이아웃 규칙으로 슬롯을 예약하세요. 브라우저가 비율을 일찍 정해 이미지 이동을 줄입니다. 글꼴, 삽입 콘텐츠, 애니메이션, 잘못된 스타일도 Cumulative Layout Shift (CLS)에 영향을 줍니다.

스크롤 아래 이미지에 지연 로딩 적용

초기 뷰포트에서 충분히 먼 이미지는 loading="lazy"를 고려하세요. LCP 후보나 즉시 필요한 콘텐츠에 자동 적용하지 마세요. 브라우저 휴리스틱, 캐러셀, 인쇄, 빠른 스크롤, 숨은 레이아웃은 시험이 필요합니다.

히어로 이미지 우선순위 지정

LCP 후보를 지연하지 마세요. 실제로 초기 대역폭을 받을 가치가 있으면 fetchpriority="high"를 고려하고 초기 HTML에서 발견되게 합니다. 광범위하게 높이지 말고 trace와 현장 데이터로 확인하세요.

반응형 이미지 사용

srcset과 sizes는 후보와 예상 슬롯을 제공합니다. 브라우저는 뷰포트, 밀도, 캐시, 구현을 고려합니다. sizes를 실제 레이아웃과 맞춰 과대·과소 후보를 피하세요.

5단계: 정기적으로 감사하고 측정하기

최적화는 한 번으로 끝나는 작업이 아닙니다. 새 이미지를 추가할 때마다 성능이 퇴보할 수 있습니다.

• PageSpeed Insights: 대표 페이지에서 PageSpeed Insights를 실행하세요. 현장과 실험실 LCP를 나누고 바뀔 수 있는 라벨 대신 현재 진단을 봅니다.
• DevTools Network: 요청을 크기순으로 보고 큰 이미지를 맥락에서 확인합니다. 일률 KB 한계 대신 크기, 형식, 압축, 캐시, 우선순위가 역할과 맞는지 봅니다.
• 자동화: 빌드 흐름에 최적화를 넣어 게시 전 과대 이미지를 발견

빠른 체크리스트

• 적절한 JPEG, WebP, AVIF, PNG 또는 SVG 변형을 생성하고 비교
• 실제 표시 크기로 조정하고 필요한 폭을 넘기지 않기
• 보수적 설정에서 시작해 바이트와 모양을 비교하고 형식 간 품질 값을 같게 보지 않기
• 각 <img>에 보통 고유 width와 height로 정확한 슬롯 예약
• LCP 후보에 fetchpriority="high"를 고려하고 측정
• 적합한 화면 밖 이미지를 지연하고 스크롤과 레이아웃 시험
• 반응형 전달을 위해 srcset/sizes 사용
• 페이지, 사용자, 현장 데이터에서 성능 예산 설정
• 불필요한 개인 메타데이터를 지우고 필요한 색상 프로필 등은 보존 — EXIF와 개인정보
• PageSpeed Insights로 정기 점검

자주 묻는 질문