페이지 용량 분석
페이지의 HTML 크기와 참조 리소스 수·종류를 분석합니다.
페이지 용량 분석은 입력한 URL의 HTML 문서 크기(바이트)와 그 안에서 참조하는 외부 리소스의 개수를 한 번에 보여 주는 도구입니다. 스크립트·스타일시트·이미지 태그 수를 종류별로 집계해, 페이지가 얼마나 무거운 구조인지 빠르게 가늠할 수 있습니다.
이 도구는 HTML 문서 자체만 서버에서 안전하게 내려받아 분석하며, 스크립트·이미지 같은 개별 리소스를 실제로 다운로드하지는 않습니다. 따라서 결과의 KB 수치는 HTML 문서 크기이고, 리소스 개수는 문서에 선언된 참조 수 기준입니다. 전체 전송량까지 정밀하게 보려면 브라우저 개발자도구의 네트워크 탭을 함께 사용하세요.
페이지 용량과 요청 수가 성능에 미치는 영향
웹 페이지가 느려지는 주요 원인은 크게 두 가지입니다. 하나는 내려받아야 할 총 바이트가 많은 것이고, 다른 하나는 받아야 할 파일(요청)의 수가 많은 것입니다. HTML 문서가 크면 첫 화면이 그려지기까지 더 오래 걸리고, 참조하는 스크립트·스타일시트·이미지가 많을수록 브라우저가 처리해야 할 추가 요청이 늘어나 렌더링이 지연됩니다.
- HTML 크기: 본문 길이가 길수록 파싱·전송 시간이 늘어납니다. 인라인 스타일·스크립트가 과도하면 문서가 비대해집니다.
- 스크립트 수: 외부 자바스크립트가 많으면 다운로드·파싱·실행 부담이 커지고, 렌더 차단 가능성이 높아집니다.
- 스타일시트 수: CSS 파일이 분산되어 있으면 렌더링 시작이 늦어집니다. 번들·병합을 검토하세요.
- 이미지 수: 이미지 태그가 많으면 요청과 전송량이 함께 늘어납니다. 지연 로딩과 적절한 포맷을 고려하세요.
측정값을 어떻게 해석할까
이 도구가 보여 주는 리소스 개수는 HTML에 선언된 참조 수일 뿐, 실제 전송된 용량은 아닙니다. 같은 스크립트를 여러 번 참조하거나, 조건부로만 로드되는 리소스도 모두 정적 태그로 세어집니다. 그렇기에 숫자가 크다고 곧바로 문제는 아니지만, 한 페이지에 스크립트나 이미지 참조가 수십 개씩 쌓여 있다면 번들링·지연 로딩·캐싱 전략을 점검할 신호로 볼 수 있습니다.
- 정확한 전송량·로딩 시간은 브라우저 네트워크 탭이나 실측형 성능 도구로 확인하세요.
- HTML이 비정상적으로 크다면 서버 사이드 렌더링 결과에 과도한 인라인 데이터가 포함됐는지 살펴보세요.
- 텍스트 자원의 전송량을 줄이려면 압축 확인으로 gzip·brotli 적용 여부를, 이미지가 많다면 이미지 포맷 추천으로 최적 포맷을 점검하세요.
성능 예산 기준선
업계에서 흔히 쓰는 페이지 용량·요청 수 가이드라인입니다. 모바일 3G/4G 환경에서도 쾌적한 로딩을 목표로 한 보수적 기준이니, 자사 페이지를 아래 표와 비교해 어느 항목이 예산을 초과하는지 점검하세요. (아래 전체 전송량은 HTML+모든 리소스 합계이며, 이 도구가 보여 주는 HTML 단독 크기와는 다릅니다.)
| 항목 | 권장(양호) | 주의 | 위험 |
|---|---|---|---|
| HTML 문서 크기 | ≤ 100 KB | 100–250 KB | > 250 KB |
| 전체 전송량(HTML+리소스) | ≤ 1 MB | 1–3 MB | > 3 MB |
| 총 요청 수 | ≤ 50 | 50–100 | > 100 |
| 외부 스크립트 수 | ≤ 10 | 10–25 | > 25 |
해석 예시: 한 페이지를 읽어 보면
예를 들어 분석 결과가 HTML 312 KB, 스크립트 41, 스타일시트 9,이미지 60으로 나왔다고 합시다. 위 기준표와 대조하면 다음과 같이 읽힙니다.
- HTML 312 KB(위험): 250 KB를 넘었습니다. SSR 프레임워크가
__NEXT_DATA__같은 초기 상태(JSON)를 통째로 인라인하거나, 본문에 base64 인라인 이미지가 박혀 있을 가능성이 큽니다. 우선 인라인 데이터부터 줄이세요. - 스크립트 41개(위험): 광고·태그매니저·A/B테스트·챗봇 같은 서드파티 태그가 누적된 전형적 패턴입니다. 번들 1~2개로 합치고, 마케팅 태그는
async/지연 로딩하세요. - 이미지 60개: 첫 화면 밖 이미지에
loading="lazy"를 적용하면 초기 요청을 크게 줄일 수 있습니다.
흔한 실수 / 함정
가장 잦은 오해는 이 도구의 KB 수치를 “페이지 전체 용량”으로 착각하는 것입니다. 이 값은 HTML 문서 하나의 크기일 뿐이고, 실제로 사용자가 내려받는 자바스크립트 번들·이미지·폰트 용량은 여기에 포함되지 않습니다. HTML이 30 KB로 작아도 그 안에서 5 MB짜리 스크립트를 참조하면 페이지는 무겁습니다. 반대로 전체 전송량 판단은 반드시 브라우저 네트워크 탭의 “Transferred”(전송) 합계로 확인하세요.
자주 묻는 질문
리소스 용량(KB)도 알 수 있나요?
참조 수가 실제 요청 수와 다른 이유는?
내 입력 URL은 어디로 전송되나요?
큰 페이지는 전부 분석되나요?
관련 가이드
- Core Web Vitals(LCP·CLS·INP) 개선 체크리스트LCP·CLS·INP가 무엇이고 무엇을 측정하는지, 점수를 올리는 실전 체크리스트.
- 사이트가 느릴 때: TTFB 원인 진단과 개선 순서첫 바이트까지의 시간(TTFB)이 늘어지는 원인 — DNS·TLS·서버·DB — 을 구간별로 진단하고 줄이는 법.
- gzip·brotli 압축 적용: 전송량 70% 줄이기텍스트 리소스 압축이 주는 효과와 nginx·Apache 설정법, 적용 확인과 흔한 실수.