웹사이트가 느릴 때 이미지부터 점검하기: 크기·포맷·지연 로딩 실전 가이드

👤 인스피

조회 수 1

1. 화면에서 작게 보인다고 작은 파일은 아니다

가로 4,000픽셀 사진을 본문에서 800픽셀 너비로 표시한다고 가정해 보겠습니다. CSS로 표시 크기만 줄이면 브라우저는 여전히 원래 파일을 내려받습니다. 화면에 차지하는 면적과 전송되는 파일 용량은 서로 다른 값입니다.

먼저 이미지가 어디에 쓰이는지 구분하세요. 게시판 목록의 썸네일은 작은 미리보기이고, 본문 이미지는 내용을 설명하는 자료입니다. 같은 원본을 양쪽에서 그대로 쓰기보다 용도에 맞는 파일을 준비하는 편이 합리적입니다. 다만 고밀도 화면에서는 CSS 표시 너비보다 더 많은 이미지 픽셀이 필요할 수 있으므로, 표시 너비만 보고 무조건 같은 픽셀 수로 잘라내지는 마세요.[9]

사용 위치	먼저 확인할 점	조정 방향
게시판 목록	작은 썸네일에 원본을 내려받는가?	별도 썸네일과 일정한 비율 준비
본문 사진	본문 너비에 비해 원본이 지나치게 큰가?	실제 표시 크기와 화면 밀도를 고려해 축소
코드·설정 화면 캡처	작은 글씨를 확대해서 읽어야 하는가?	글자 가독성을 기준으로 크기와 압축 결정
첫 화면의 대표 이미지	이 이미지 때문에 주요 내용이 늦게 보이는가?	용량과 요청 시점을 우선 확인

운영 중에는 먼저 자주 읽히는 글 몇 개를 대상으로 점검해도 좋습니다. 모든 이미지를 한꺼번에 변환하면 어느 변경이 도움이 되었는지 구분하기 어렵습니다. 대표 이미지, 목록 썸네일, 본문 아래 이미지 순서로 대상을 나누면 비교 결과를 기록하기도 쉽습니다.

2. Chrome 개발자 도구로 실제 전송을 확인하기

이미지 파일이 크다고 해서 페이지 지연의 원인이 항상 이미지인 것은 아닙니다. 서버가 HTML을 늦게 보내거나, 다른 리소스 요청이 먼저 지연될 수도 있습니다. 따라서 추측으로 파일을 바꾸기 전에 브라우저의 요청 기록을 확인하세요.

Chrome에서 점검할 페이지를 열고 F12로 개발자 도구를 엽니다.
Network 탭에서 Disable cache를 켜고 페이지를 새로고침합니다. 이 설정은 개발자 도구가 열려 있을 때 적용됩니다.
이미지 필터를 선택해 어떤 파일을 요청했는지 확인합니다.
Size와 Time, 요청 상세의 Timing을 함께 봅니다.
같은 조건에서 파일을 교체한 뒤 다시 측정합니다.

Network에서는 전송량과 리소스 크기를 구분할 수 있고, 캐시에서 가져온 경우도 확인할 수 있습니다. 캐시된 상태의 결과를 처음 방문한 사용자의 결과와 바로 비교하지 마세요. 시간에는 전송뿐 아니라 대기와 연결 등 여러 단계가 영향을 줍니다.[2]

운영 기록에는 페이지 주소, 확인 날짜, 화면 크기, 캐시 사용 여부, 변경한 파일 이름을 적어두세요. 예를 들어 “이미지를 WebP로 바꿨더니 빨라졌다”보다 “같은 테스트 조건에서 대표 이미지의 전송량이 줄었다”가 검증 가능한 표현입니다. 실제 페이지의 표시 속도까지 개선되었는지는 별도 측정으로 확인해야 합니다.

3. PNG, JPEG, WebP, AVIF 중 무엇을 선택할까?

포맷은 그림의 용도에 맞춰 선택해야 합니다. JPEG는 사진에 흔히 쓰이는 손실 압축 형식이고, PNG는 무손실 표현이나 투명 배경이 필요한 이미지에 쓰입니다. WebP는 손실·무손실 압축을 지원하며, AVIF도 사진과 투명 이미지 등의 대안이 될 수 있습니다.[3]

하지만 “최신 형식이니까 모든 이미지에서 가장 작다”라고 단정할 수는 없습니다. 사진, 단색 도표, 작은 글씨가 많은 화면 캡처는 압축 결과가 다르게 나타납니다. 인코더 설정까지 달라지므로 확장자와 품질 숫자만 비교해서 최종 판단을 내리면 안 됩니다.

그림의 특징	비교해 볼 형식	확인할 부분
일반 사진	JPEG, 손실 WebP, AVIF	피부·그라데이션·미세한 질감
작은 글씨가 많은 캡처	PNG, 무손실 WebP	글자 테두리와 얇은 선
투명 배경 이미지	PNG, WebP, AVIF	투명 영역과 가장자리

이 표는 비교의 출발점입니다. 같은 파일을 실제로 저장해 용량을 확인하고, 독자가 읽을 크기에서 그림을 살펴보세요. 서버가 특정 형식으로 자동 변환한다면 업로드 전 파일과 게시 후 제공되는 파일도 구분해야 합니다. 변환을 반복하면 기대했던 결과와 달라질 수 있습니다.

4. 직접 만든 도표로 확인한 압축 결과

아래 이미지는 저작권 문제가 있는 웹사이트 화면을 가져온 것이 아니라, 텍스트·단색 배경·얇은 선으로 직접 구성한 실험용 가상 대시보드입니다. 실제 운영 시스템의 화면이나 성능 기록을 나타내지는 않습니다.

실험에 사용한 도표의 1,200 × 675픽셀 버전. 이 문서에는 무손실 WebP로 내장했습니다.

원본은 RGB 모드의 2,400 × 1,350픽셀입니다. PNG는 optimize=True, 손실 WebP는 quality=80, method=6으로 저장했습니다. 축소본은 LANCZOS로 가로·세로를 각각 절반으로 줄였습니다. 무손실 WebP에는 lossless=True, method=6을 적용했습니다.

저장 조건	해상도	실제 바이트	용량
원본 PNG	2,400 × 1,350	163,983	160.1 KiB
원본 손실 WebP, quality 80	2,400 × 1,350	220,426	215.3 KiB
축소 PNG	1,200 × 675	153,431	149.8 KiB
축소 무손실 WebP	1,200 × 675	20,812	20.3 KiB
축소 손실 WebP, quality 80	1,200 × 675	91,666	89.5 KiB

용량은 파일 바이트를 1,024로 나눈 KiB이며 소수점 한 자리로 표시했습니다. quality=80은 인코더의 설정값이지 원본 화질을 80% 유지한다는 뜻이 아닙니다.[4]

이 그림에서는 원본을 손실 WebP로 바꾼 파일이 PNG보다 컸습니다. 축소 PNG도 픽셀 수가 크게 줄어든 만큼 용량이 줄지는 않았습니다. 반면 축소 무손실 WebP는 축소 PNG보다 약 86.4% 작았습니다. 두 축소 파일은 저장 후 다시 열어 RGB 픽셀 값이 같은지도 확인했습니다.

이 결과를 사진이나 모든 웹사이트에 그대로 적용할 수는 없습니다. 이 실험은 단색과 반복되는 글자가 많은 그림 한 장의 결과입니다. 또한 파일 크기만 비교했으므로 인코딩 시간, 브라우저 디코딩 시간, 실제 LCP 개선율을 측정한 것은 아닙니다. 실무에서 얻을 수 있는 교훈은 작게 만든 뒤에도 저장 형식을 여러 개 비교해야 한다는 점입니다.

5. 원본을 보존하면서 축소본 만들기

반복 작업에는 간단한 변환 스크립트가 도움이 됩니다. 다음 예제는 Pillow가 설치된 Python 환경에서 PNG 한 장을 열어, 최대 1,200 × 1,200픽셀 안에 들어가는 무손실 WebP를 만듭니다. 원본을 덮어쓰지 않으며, 작은 이미지를 억지로 확대하지 않습니다.

from pathlib import Path
from PIL import Image, ImageOps

source = Path("input.png")
destination = Path("input-1200.webp")

with Image.open(source) as original:
    image = ImageOps.exif_transpose(original)
    image.thumbnail((1200, 1200), Image.Resampling.LANCZOS)
    image.save(destination, "WEBP", lossless=True, method=6)

print("saved:", destination)
print("bytes:", destination.stat().st_size)

thumbnail()은 종횡비를 유지하면서 지정한 상자 안으로 크기를 줄입니다. 가로가 긴 이미지와 세로가 긴 이미지의 최종 크기는 다르게 나옵니다.[5] 사진에 적용할 때는 손실 압축도 비교하고, 화면 캡처에 적용할 때는 작은 글씨가 읽히는지 확인하세요.

이 예제는 정지 이미지 한 장을 처리하는 기본형입니다. 애니메이션 프레임, 색상 프로필, 메타데이터 보존 정책까지 다루는 일괄 변환 도구는 아닙니다. 원본을 별도로 보관하고, 변환본을 사용하기 전에 직접 열어보는 절차를 유지하세요.

6. width와 height로 이미지 공간을 미리 확보하기

이미지가 늦게 도착할 때 본문이 아래로 밀린다면 이미지 공간을 미리 잡아두었는지 확인하세요. HTML에 올바른 width와 height를 넣으면 브라우저가 이미지의 비율을 계산하는 데 도움이 됩니다. 이미지가 로드되면서 생기는 레이아웃 이동을 줄이는 기본 방법입니다.[6]

<img
  src="/static/uploads/example-1200.webp"
  alt="이미지 크기와 압축 조건을 비교한 결과"
  width="1200"
  height="675"
  style="max-width:100%;height:auto;"
>

가로·세로 값은 파일의 실제 비율과 맞춰야 합니다. 세로 이미지에 가로 이미지의 수치를 복사하면 예상과 다른 공간이 잡힐 수 있습니다. CSS의 max-width:100%는 본문 너비를 넘지 않게 하고, height:auto는 표시 비율을 유지하는 데 사용합니다.

이미지 치수 지정으로 모든 레이아웃 이동이 해결되지는 않습니다. 광고 영역, 늦게 삽입되는 콘텐츠, 글꼴 변화 등도 따로 점검해야 합니다. 이미지는 해당 문제의 한 가지 원인으로 확인하는 편이 정확합니다.

7. 모든 이미지에 lazy를 붙이지 않기

긴 글 아래쪽 이미지를 처음부터 전부 내려받을 필요는 없습니다. 화면에 가까워졌을 때 불러오는 loading="lazy"를 사용할 수 있습니다. 다만 브라우저가 판단하는 거리와 시점에 따라 동작하므로, 이미지가 보이는 정확한 순간에만 요청된다고 이해하면 안 됩니다.[7]

<!-- 스크롤 아래쪽의 본문 이미지 예제 -->
<img
  src="/static/uploads/example-detail.webp"
  alt="세부 설정을 설명하는 화면"
  width="1200"
  height="800"
  loading="lazy"
  style="max-width:100%;height:auto;"
>

반대로 첫 화면에서 가장 크게 보이는 대표 이미지에 지연 로딩을 걸면 주요 콘텐츠 표시를 늦출 수 있습니다. LCP 후보 이미지는 지연 로딩을 피하는 것이 기본 방향입니다. LCP는 첫 화면의 주요 콘텐츠가 나타나는 시점을 살펴보는 성능 지표입니다.[7]

게시판을 운영한다면 목록과 본문을 구분해서 결정하세요. 목록 상단에서 바로 보이는 이미지, 긴 글 중간 이후의 이미지, 화면 밖 썸네일은 같은 조건이 아닙니다. 전역 규칙으로 모든 이미지에 lazy를 붙이기보다 위치를 기준으로 확인해야 합니다.

8. 모바일과 데스크톱에 다른 크기 제공하기

파일 여러 개를 준비할 수 있다면 srcset과 sizes로 이미지 후보와 예상 표시 너비를 알려줄 수 있습니다. 브라우저는 화면 밀도와 레이아웃 등을 고려해 후보를 선택합니다. 아래는 본문이 최대 800픽셀이고, 좁은 화면에서는 양쪽에 16픽셀 여백이 있는 경우의 예시입니다.[1]

<img
  src="/static/uploads/photo-800.webp"
  srcset="/static/uploads/photo-480.webp 480w,
          /static/uploads/photo-800.webp 800w,
          /static/uploads/photo-1600.webp 1600w"
  sizes="(max-width: 832px) calc(100vw - 32px), 800px"
  width="1600"
  height="900"
  alt="서로 다른 화면 너비에 맞춰 제공하는 본문 사진"
  style="max-width:100%;height:auto;"
>

코드에 파일 이름을 적는 것만으로 변환본이 생성되지는 않습니다. 세 파일을 같은 비율로 실제 준비해야 하고, sizes도 사이트의 본문 폭에 맞춰야 합니다. 위 경로는 구현 설명용이며 그대로 복사하기 전에 실제 파일 주소로 바꾸세요.

에디터나 서버의 HTML 정리 기능이 속성을 제거할 수도 있습니다. 저장한 뒤 실제 페이지의 요소 검사에서 srcset, sizes, loading이 유지되는지 확인하세요. 원고에 코드 예제를 넣는 일과 웹사이트 전체에 최적화를 적용하는 일은 별개의 작업입니다.

9. 운영자가 기록해둘 점검표

실제 운영에서는 한 번의 점수보다 변경 전후 기록이 유용합니다. 아래 항목을 글 한 편에 적용하고, 문제가 없는지 확인한 뒤 다른 글로 확대해 보세요.

대표 이미지와 목록 썸네일의 실제 파일 용량을 확인했는가?
본문에서 작은 글씨와 얇은 선이 충분히 읽히는가?
원본 파일과 변환본을 분리해 보관했는가?
캐시·화면 크기 등 같은 조건으로 변경 전후를 비교했는가?
이미지의 가로·세로 비율이 맞는가?
첫 화면의 주요 이미지를 불필요하게 지연 로딩하지 않았는가?
등록 후 실제 이미지 요청이 성공하고 모바일에서 제대로 표시되는가?

예를 들어 한 글의 대표 이미지만 바꾸었다면 대표 이미지의 파일 전송량과 첫 화면 표시를 기록합니다. 목록 썸네일까지 동시에 바꾸었다면 목록 페이지도 따로 확인해야 합니다. 측정 대상을 구체적으로 잡으면 개선이 없을 때 되돌리거나 다음 원인을 찾기 쉽습니다.

자주 묻는 질문

Q. 이미지 용량은 무조건 100KB 이하로 맞춰야 하나요?

모든 이미지에 적용할 단일 기준으로 보기 어렵습니다. 작은 썸네일과 글씨가 많은 설명 자료는 필요한 정보량이 다릅니다. 일정 숫자를 맞추려고 가독성을 훼손하기보다 용도에 맞는 크기와 압축을 비교하세요.

Q. PNG를 WebP로 바꾸면 반드시 작아지나요?

그렇지 않습니다. 위 실험에서도 원본 손실 WebP가 원본 PNG보다 컸습니다. 같은 그림의 축소 무손실 WebP는 훨씬 작았습니다. 그림의 특성과 인코딩 방식에 따라 달라지므로 실제 파일을 비교해야 합니다.

Q. 이미지가 이미 WebP라면 더 할 일이 없나요?

해상도, 압축 설정, 썸네일 분리, 첫 화면 요청 시점이 남아 있습니다. 작은 카드에 큰 원본을 내려받는다면 WebP라도 낭비가 발생할 수 있습니다.

Q. 파일 용량이 줄었는데 사이트는 여전히 느립니다.

이미지 외의 지연이 있을 수 있습니다. HTML 응답, 스크립트, 글꼴, 외부 리소스 요청을 함께 확인하세요. 파일 크기 감소를 페이지 전체의 속도 개선과 같은 의미로 기록하지 않는 것이 좋습니다.

Q. HTML에 내장한 이미지도 그대로 게시해도 되나요?

파일 하나로 문서를 전달할 때는 편리합니다. 게시판이 내장 이미지를 별도 파일로 저장하는 불러오기 기능을 제공한다면 그 기능을 이용하세요. 등록 후 본문의 이미지 주소가 실제 파일 URL로 바뀌었는지 확인하면 됩니다.

Q. 이 작업을 하면 애드센스 승인이 되나요?

이미지 최적화만으로 승인을 보장할 수는 없습니다. 독자가 글을 편하게 읽도록 돕는 개선이며, 콘텐츠의 독창성·정책 준수·탐색 구조 등 사이트 전체의 상태는 별도로 점검해야 합니다.[8]

다음 글에 이미지를 올릴 때는 파일 형식부터 결정하기보다, 방문자가 어디에서 어떤 정보를 읽어야 하는지 먼저 확인하세요. 그다음 필요한 크기로 준비하고, 여러 저장 조건을 비교한 뒤, 실제 게시 페이지에서 요청과 표시를 확인하면 됩니다.

참고 자료와 실험 조건

공식 문서 확인일: 2026년 10월 1일. 파일 크기 실험은 Linux 환경의 Pillow 12.3.0에서 직접 만든 정적 도표 한 장으로 수행했습니다. 원본과 축소본의 해상도·인코딩 조건은 본문에 명시했습니다. 결과는 해당 예제의 측정값이며 일반적인 절감률이나 특정 사이트의 성능을 보장하지 않습니다.