웹사이트 이미지, 그냥 올리면 속도 망합니다

실무에서 성능 이슈를 잡을 때 저는 먼저 이미지를 봅니다. 이유는 단순합니다. 많은 페이지에서 이미지가 전체 전송 용량의 큰 비중을 차지하고, 이 구간이 느리면 첫 화면 렌더링도 함께 늦어지기 쉽기 때문입니다. 그런데 이미지 최적화를 “압축 툴 한 번 돌리기”로 끝내면 체감 개선이 제한적입니다. 포맷, 해상도, 로딩 우선순위, 레이아웃 안정성까지 같이 설계해야 결과가 오래 갑니다.

1. 왜 이미지부터 점검해야 할까

사용자 입장에서 느린 페이지는 결국 “첫 화면이 늦게 보이고, 보인 뒤에도 화면이 흔들리는” 경험으로 남습니다. 이 둘에 이미지는 거의 항상 관여합니다. 용량이 큰 이미지가 네트워크를 오래 점유하면 본문 텍스트, 폰트, 스크립트 도착도 뒤로 밀립니다.

그래서 시작은 간단합니다. 첫 화면에 실제로 보이는 이미지가 무엇인지, 그 파일이 얼마나 큰지, 화면 크기 대비 과도한 해상도는 아닌지를 먼저 확인합니다. 이 단계만 해도 어디를 손대야 체감이 좋아질지 우선순위가 잡힙니다.

2. 포맷 선택: WebP/AVIF를 기본으로, 예외를 명확히

최근에는 WebP와 AVIF가 기본 선택지입니다. 같은 시각 품질 기준에서 전송 용량을 줄이기 유리한 경우가 많기 때문입니다. 다만 무조건 하나로 통일하기보다, 이미지 성격과 운영 환경을 같이 봐야 합니다.

• 사진형 콘텐츠: WebP 또는 AVIF를 우선 검토합니다.
• 투명 배경/그래픽: PNG 유지가 더 안전한 경우가 있습니다.
• 호환성/운영 복잡도: 포맷별 파생 파일 생성·캐시 정책까지 감당 가능한지 확인합니다.

실무에서는 “한 포맷 올인”보다 “기본 포맷 + 예외 규칙”이 유지보수에 유리했습니다. 예를 들어 기본은 WebP, 특정 자산군만 AVIF 추가처럼 팀 규칙을 짧게 문서화하면 편집자와 개발자 모두 실수를 줄일 수 있습니다.

3. 해상도 전략: 원본 크기가 아니라 표시 크기에 맞춘다

고해상도 원본을 그대로 내보내면 품질은 좋아 보여도 다운로드 비용이 커집니다. 반대로 너무 작게 내보내면 선명도가 떨어집니다. 핵심은 “실제 표시 크기 기준”입니다. 같은 이미지라도 모바일 카드, 데스크톱 히어로, 썸네일은 필요한 픽셀이 다릅니다.

1. 컴포넌트별 최대 표시 크기를 먼저 정의합니다.
2. 그 크기에 맞춘 파생 해상도를 준비합니다.
3. srcset/sizes로 기기 폭에 맞는 파일이 선택되게 합니다.

이 과정을 거치면 “같은 이미지를 모든 기기에 동일 파일로 제공”하는 비효율이 줄어듭니다. 체감상 네트워크가 가벼워지고, 특히 모바일 환경에서 첫 화면 진입이 더 안정적으로 빨라집니다.

4. CLS 방지: width/height 지정은 필수

이미지 로딩 후 본문이 아래로 밀리는 현상은 사용자 피로가 큽니다. 이 문제를 줄이는 가장 기본적인 방법이 이미지 태그에 width와 height를 명시해 레이아웃 공간을 미리 확보하는 것입니다. 상황에 따라 CSS aspect-ratio를 함께 쓰면 컴포넌트 재사용성도 좋아집니다.

핵심은 “레이아웃을 먼저 예약하고, 이미지 데이터는 나중에 채운다”는 순서입니다. 작은 설정 같지만 페이지 전체 신뢰감을 크게 좌우합니다. 특히 목록형 페이지에서 카드가 연속으로 흔들리면 이탈률 체감이 빠르게 올라갑니다.

5. LCP 히어로 이미지는 압축보다 우선순위 설계가 먼저

첫 화면의 대표 이미지(히어로)는 LCP 후보가 되기 쉽습니다. 이때 “용량만 줄이면 된다”는 접근은 절반만 맞습니다. 압축은 필요하지만, 어떤 리소스를 먼저 받게 할지 설계하지 않으면 개선 폭이 작습니다.

실무 기준으로는 다음 순서를 권장합니다.

1. 히어로 이미지를 명확히 1개로 정의합니다.
2. 해당 이미지는 lazy loading에서 제외합니다.
3. 필요 시 fetchpriority="high" 또는 preload를 검토합니다.
4. 동시에 크기 정보(width/height)를 명시해 레이아웃 이동을 막습니다.

즉, LCP 이미지는 “가볍게”와 “먼저”를 같이 만족시켜야 합니다. 둘 중 하나만 맞추면 지표와 체감이 엇갈릴 수 있습니다.

6. 지연 로딩(lazy loading)은 전부가 아니라 위치별 적용

lazy loading은 분명 효과적이지만, 모든 이미지에 기계적으로 적용하면 역효과가 납니다. 첫 화면에서 바로 보여야 할 요소까지 지연되면 사용자는 빈 영역을 먼저 보게 됩니다.

• 첫 화면 밖 이미지: 기본적으로 lazy 적용
• 첫 화면 핵심 이미지: eager 또는 기본 로딩 유지
• 캐러셀/탭 내부 이미지: 실제 노출 시점 기준으로 조건부 로딩

중요한 건 “화면 위치 + 사용자 맥락”입니다. 스크롤 후 소비되는 콘텐츠와 즉시 확인되는 콘텐츠를 분리해 생각하면 적용 기준이 명확해집니다.

7. 배포 전 바로 쓰는 체크리스트

아래 항목은 새 페이지를 배포하기 전 제가 최소로 확인하는 리스트입니다. 항목 수를 늘리기보다, 빠르게 반복 가능한 기준으로 유지하는 것이 좋습니다.

1. 첫 화면 이미지의 포맷이 최신 포맷(WebP/AVIF 등) 또는 합리적 예외인지 확인
2. 컴포넌트별 표시 크기에 맞는 해상도 파일이 준비되었는지 확인
3. srcset/sizes가 의도대로 동작하는지 모바일/데스크톱에서 확인
4. 모든 주요 이미지에 width/height가 선언되어 있는지 확인
5. 히어로 이미지가 lazy로 밀리지 않았는지 확인
6. 히어로 이미지 우선순위(fetch priority/preload) 설정이 과하지 않은지 확인
7. 스크롤 구간 이미지에 lazy loading이 적용되어 초기 요청 수가 줄었는지 확인
8. 배포 후 실제 네트워크 로그에서 요청 순서와 전송 크기를 재확인

8. 팀 의사결정 기준: “품질 유지 + 전송량 절감 + 운영 가능성”

이미지 최적화는 기술 선택보다 운영 선택에 가깝습니다. 포맷이 좋아도 생성 파이프라인이 복잡하면 누락이 생기고, 해상도 정책이 정교해도 편집 프로세스와 맞지 않으면 금방 무너집니다. 그래서 최종 기준은 세 가지로 단순화하는 게 좋습니다.

• 사용자 품질: 텍스트/제품 정보가 흐려지지 않는가
• 성능 효과: 초기 전송량과 렌더링 지연이 줄어드는가
• 운영 지속성: 편집자·개발자가 같은 규칙으로 반복 가능한가

이 세 기준을 문서 한 장으로 정리해 두면 신규 페이지 제작 속도도 빨라지고, 담당자가 바뀌어도 결과 편차가 줄어듭니다. 이미지 최적화의 목적은 “한 번의 개선”이 아니라 “계속 빠른 페이지를 만드는 체계”라는 점을 잊지 않는 것이 핵심입니다.

정리하면, 웹 이미지 최적화의 실전 포인트는 명확합니다. 최신 포맷을 검토하고, 표시 크기 중심으로 해상도를 나누고, 지연 로딩을 위치별로 적용하고, width/height로 레이아웃을 고정하고, LCP 히어로 이미지는 우선순위 로딩까지 설계합니다. 이 다섯 가지를 함께 적용하면 과장 없이도 체감 속도와 안정성이 확실히 좋아집니다.