이미지는 보통 페이지에서 가장 무거운 요소여서, 여러분이 통제하는 가장 큰 속도 지렛대입니다. 치수 와 파일 용량 을 제대로 맞추면 페이지가 즉각적으로 느껴집니다. 잘못 맞추면 코드가 아무리 깔끔해도 Core Web Vitals에 실패합니다. 목표치와 그것을 맞추는 작업 흐름을 소개합니다.
치수 목표
이미지의 픽셀 크기를 실제로 나타나는 위치에 맞추세요. 대략적인 안내입니다.
- 전체 폭 히어로: 1600–2000 px 폭이면 대부분의 데스크톱 레이아웃을 커버합니다. 더 넓게 가는 것은 거의 도움이 안 되고 많은 바이트를 잡아먹습니다.
- 본문 사진: 콘텐츠 열의 폭, 흔히 800–1200 px.
- 썸네일 / 카드 이미지: 300–500 px.
- 아바타 / 아이콘: 표시되는 크기 그대로 48–200 px.
800px 슬롯에 4000px 이미지를 넣는다는 것은, 브라우저가 표시할 픽셀의 25배를 다운로드하고 디코딩한다는 뜻입니다. 순수한 낭비이며 — 큰 이미지를 디코딩하는 일은 메인 스레드도 버벅이게 합니다.
용량 목표
치수가 상한을 정하고, 압축이 실제 용량을 정합니다. 이 정도를 목표로 하세요.
- 히어로 이미지: 200 KB 미만 (이상적으로는 100–150 KB).
- 본문 사진: 80–150 KB.
- 썸네일: 10–30 KB.
- 페이지당 전체 이미지: 페이지 전체를 약 1 MB 아래로 유지하려 노력하세요.
이미지 하나가 약 300 KB를 넘으면 조사할 버그로 취급하세요.
이것이 Core Web Vitals를 좌우하는 이유
Google의 Largest Contentful Paint (LCP) 는 화면에서 가장 큰 요소가 렌더링되기까지 얼마나 걸리는지를 측정하는데 — 대부분의 페이지에서 그 가장 큰 요소가 바로 이미지(보통 히어로)입니다. 무겁고 과대한 히어로는 LCP를 직접 부풀립니다. 좋은 LCP는 2.5초 미만 이며, 비대한 히어로 하나만으로도 모바일 연결에서 그것을 훌쩍 넘길 수 있습니다.
이미지 관련 이점 두 가지 더 있습니다.
- 너비와 높이 속성을 설정 하면 브라우저가 공간을 예약합니다 — 이것이 Cumulative Layout Shift (CLS) 점수를 보호합니다.
- 히어로를 우선하고(LCP 이미지는 지연 로딩하지 말고), 접힌 선 아래의 모든 것은 지연 로딩하세요.
두 단계 작업 흐름
1단계 — 실제 표시 폭으로 크기 조정. 이미지 리사이저로 각 이미지를 나타나는 크기로 줄이세요. 비율 잠금 켜고, 고품질 축소로요. 이것만으로도 용량이 80–90% 줄어드는 경우가 많습니다.
2단계 — 압축. 크기 조정한 파일을 이미지 압축기에 넣으세요. 사진은 화질 75–85(시각적으로 무손실), PNG는 256색 양자화로요. 원본보다 큰 파일을 절대 출력하지 않고, 일괄 처리를 지원하며, 선택적 폭 제한이 있어 두 단계를 사실상 한 번에 할 수 있습니다. 현대 브라우저용으로 사진을 WebP로 변환하면 25–35%를 더 짜냅니다.
짐작하지 말고 측정하세요
이미지를 최적화한 뒤, 페이지가 실제로 빨라졌는지 확인하세요. IMG.DIY의 Page QA는 라이브 URL을 Google PageSpeed Insights로 점검하고 페이지의 이미지 용량을 보고해, 여전히 너무 무거운 파일을 찾아낼 수 있게 해 줍니다. 한 가지 유의점: Page QA는 인터넷 연결이 필요합니다 — 이미지 도구와 달리 Google의 PageSpeed API를 호출하므로 오프라인에서 실행할 수 없습니다. 배포 후에 사용해 실제 LCP와 이미지 예산을 확인하세요.
기본값이 비공개
리사이즈, 압축, 변환 도구는 Canvas와 WebAssembly로 전적으로 여러분의 브라우저에서 실행됩니다 — 아무것도 업로드되지 않고, 첫 방문 이후 캐시되어 오프라인에서 작동합니다. 연결 없이 사이트 전체 분량의 이미지를 준비한 뒤, 페이지가 라이브가 되면 온라인으로 Page QA를 실행할 수 있습니다.
빠른 요약: 치수를 알맞게 잡고, 용량 목표치로 압축하고, LCP를 위해 히어로를 우선하고, Page QA로 검증하세요.