2026-07-27

웹사이트가 느린 진짜 이유는 대개 이미지입니다 — 무엇을 하면 될까요

사이트가 느리게 느껴진다면 제일 먼저 의심해야 할 건 호스팅 플랜이나 자바스크립트 번들이 아니라 대개 이미지입니다. 평균적인 웹페이지에서 가장 큰 용량을 차지하는 건 이미지이고, 구글은 이제 페이지 속도를 사이트 평가 항목에 직접 반영합니다. 실제로 무엇을 측정하는지, 왜 이미지가 거의 항상 가장 큰 지렛대인지, 그리고 무엇을 하면 되는지 정리했습니다.

대부분의 웹페이지에서 가장 무거운 건 이미지다

수백만 개의 실제 웹페이지를 크롤링하는 HTTP Archive의 2025년 Web Almanac에 따르면, 데스크톱 홈페이지의 중앙값 총 용량은 2,862KB이고, 그중 이미지만 1,058KB를 차지합니다 — 다른 어떤 리소스 유형보다도 큰 비중이며, 자바스크립트(697KB)는 물론 폰트(139KB)와 CSS(82KB)를 다 합친 것보다도 많습니다. 일반적인 페이지에서 이미지는 로딩 시간에 "영향을 주는 요소 중 하나"가 아니라, 압도적인 차이로 가장 큰 단일 요인입니다.

데스크톱 페이지 용량 중앙값 기준, 이미지는 자바스크립트·폰트·CSS·HTML을 다 합친 것보다도 무겁습니다. 출처: HTTP Archive, 2025 Web Almanac.

구글이 실제로 측정하는 것: Largest Contentful Paint

"느리게 느껴진다"는 예전엔 주관적인 이야기였지만 이제는 아닙니다. 구글의 Core Web Vitals에는 Largest Contentful Paint(LCP)라는 지표가 있습니다 — 페이지를 열었을 때 화면에서 가장 큰 요소가 렌더링을 끝내기까지 걸리는 시간입니다. 구글의 공식 가이드는 구체적입니다: 실제 방문의 75번째 백분위수 기준으로 LCP가 2.5초 이하여야 "양호(good)"로 분류됩니다. 아주 많은 페이지에서 그 "가장 큰 요소"는 사진이나 제품 이미지, 히어로 배너입니다 — <img> 태그, CSS 배경 이미지, 동영상의 포스터 이미지 모두 구글이 명시적으로 LCP 후보로 계산하는 대상입니다. 그 파일 하나가 필요 이상으로 크면, 그것만으로 페이지가 "양호" 기준을 벗어날 수 있습니다.

이게 실제로 검색 순위에 영향을 줄까

영향을 주긴 하지만, 정직하게 짚어야 할 단서가 있습니다. 구글 자체 Search Central 문서는 Core Web Vitals가 페이지 경험(page experience)의 일부로서 "우리 핵심 랭킹 시스템이 보상하고자 하는 것과 일치한다"고 명시하고 있고, 검색 성과를 위해 "양호한" Core Web Vitals 점수를 달성하라고 사이트 운영자들에게 명시적으로 권고합니다. 콘텐츠가 약해도 순위를 뒤집어주는 마법의 지렛대는 아닙니다 — 구글도 콘텐츠 관련성이 여전히 우선한다고 분명히 밝히고 있습니다. 하지만 콘텐츠 수준이 비슷한 두 페이지 사이에서는 더 빠른 쪽이 실제로, 그리고 구글이 인정하는 이점을 가집니다. 그리고 비대해진 이미지 하나가, 페이지가 애초에 이 기준을 못 넘는 가장 흔하고 가장 고치기 쉬운 이유 중 하나입니다.

실제로 효과가 있는 세 가지

개발자도, 사이트 재구축도 필요 없습니다. 이미지가 페이지에 올라가기 전에 이미지 자체를 정리하면 됩니다:

업로드 전에 압축하세요. 스마트폰이나 카메라에서 바로 나온 사진은 대개 웹페이지에 필요한 것보다 훨씬 큽니다. NearIMG의 압축(Compress) 도구는 품질 값을 조절하면서 결과 파일 크기를 확정 전에 바로 확인할 수 있게 해줍니다 — 일반적인 사진이라면 품질 80~90% 구간이 원본과 육안으로 구분하기 어려우면서도 용량은 훨씬 작습니다.
실제로 표시되는 크기로 리사이즈하세요. 폭 600px짜리 본문 칼럼에 4000px 너비의 사진을 그대로 넣는 건 순수한 낭비입니다 — 그 여분의 픽셀도 브라우저가 버리기 전에 일단 전부 다운로드해야 합니다. NearIMG의 리사이즈(Resize) 도구는 내보내기 전에 정확한 목표 너비·높이(또는 퍼센트)를 지정할 수 있어서, 파일이 실제로 표시될 크기에 맞춰집니다.
가능하면 WebP로 변환하세요. 구글 자체 압축 연구에 따르면 WebP는 동일한 시각적 품질에서 JPEG보다 25~34% 더 작은 파일을 만듭니다. NearIMG의 WebP 변환 도구는 이 변환을 기존 JPG/PNG 변환기와 마찬가지로 브라우저 안에서 완전히 처리하므로, 포맷을 바꾸려고 어딘가에 다시 업로드할 필요가 없습니다.

이미지 최적화로 고칠 수 없는 것

한계도 솔직하게 짚어야 합니다. 이미지는 Web Almanac 그래프에서 가장 큰 단일 항목이지만 유일한 항목은 아닙니다. 자바스크립트만 해도 데스크톱 페이지 중앙값 기준 697KB이고, 느린 서버, 최적화되지 않은 폰트 전략, 렌더링을 막는 스크립트는 이미지와 무관하게 Core Web Vitals를 악화시킬 수 있습니다. 사진 용량을 줄인다고 느린 백엔드나 비대한 자바스크립트 번들이 고쳐지지는 않습니다. 다만 이미지 최적화가 확실히 고쳐주는 건, 오늘날 웹에서 가장 크고 가장 흔하고 가장 기계적으로 처리 가능한 페이지 용량의 원인입니다 — 코드를 전혀 건드리지 않고도 대개 가장 먼저 손댈 수 있는 부분이라는 뜻이기도 합니다.

발행 전 빠른 체크리스트

이 이미지가 실제로 표시되는 크기에 맞춰져 있나요, 아니면 카메라 원본 해상도 그대로인가요?
압축 품질이 보기 좋을 만큼 충분히 높으면서도, 굳이 100%로 남아있진 않나요?
눈에 띄는 품질 손실 없이 WebP로 바꾸면 용량을 의미 있게 줄일 수 있나요?
이 이미지가 페이지의 LCP 요소(히어로 이미지, 배너, 또는 접히지 않는 영역의 첫 번째 큰 사진)가 될 가능성이 높나요? 그렇다면 30초를 더 들여서라도 제대로 처리할 가치가 있습니다.