압축(gzip/brotli) 확인

압축 확인 도구는 입력한 URL에 서버가 gzip 또는 brotli(br) 등의 콘텐츠 압축을 적용하는지 실시간으로 점검합니다. 브라우저처럼 Accept-Encoding: gzip, br, deflate 헤더를 보낸 뒤, 응답의 Content-Encoding 값을 읽어 어떤 압축이 적용됐는지 보여줍니다.

텍스트 자원(HTML·CSS·JavaScript·JSON 등)은 압축만 켜도 전송 크기가 크게 줄어 페이지 로딩 속도와 코어 웹 바이탈 점수가 개선됩니다. 압축이 빠져 있다면 가장 효과가 큰 무료 최적화 중 하나를 놓치고 있는 셈입니다. URL만 입력하면 압축 적용 여부와 Content-Type, Vary 헤더를 함께 확인할 수 있습니다. 페이지가 얼마나 무거운지는 페이지 용량 분석으로, 서버 응답이 빠른지는 응답 속도 측정으로 함께 점검하세요.

gzip vs brotli

gzip은 거의 모든 서버와 브라우저가 지원하는 표준 압축 방식입니다. brotli(br)는 구글이 만든 더 새로운 알고리즘으로, 같은 텍스트를 보통 gzip보다 15~25% 더 작게 압축합니다. 대부분의 최신 브라우저는 HTTPS에서 brotli를 지원하므로, 가능하면 정적 텍스트 자원에는 brotli를, 동적 응답에는 gzip을 함께 켜두는 구성이 좋습니다.

어떤 자원을 압축해야 하나

• 압축 권장: HTML, CSS, JavaScript, JSON, SVG, XML 등 텍스트 기반 자원
• 압축 불필요: JPEG·PNG·WebP·MP4 등 이미 압축된 바이너리(재압축 효과가 거의 없고 CPU만 소모)
• Vary 헤더: 압축 응답에는 Vary: Accept-Encoding을 두어 캐시·프록시가 압축본과 비압축본을 구분하도록 하는 것이 안전합니다.

프록시·HTTP/2 환경에서의 차이

CDN, 리버스 프록시, 로드밸런서 같은 중간 계층이 압축을 대신 처리하거나 다시 풀었다 압축하는 경우가 있어, 원본 서버 설정과 실제 응답이 다를 수 있습니다. 또한 HTTP/2·HTTP/3에서는 헤더 표기가 도구마다 다르게 보일 수 있습니다. 이 도구는 최종 응답에서 보이는 Content-Encoding을 기준으로 판단하므로, CDN 뒤에 있는 사이트라면 엣지가 반환한 결과를 보여준다는 점을 감안하세요.

Content-Encoding 값 빠른 참조

응답의 Content-Encoding 헤더에 실제로 들어오는 토큰과 의미는 다음과 같습니다. 여러 압축을 겹쳐 쓴 경우 br, gzip처럼 쉼표로 나열되며, 적용된 순서대로 읽습니다.

실제 응답 해석 예시

예를 들어 https://example.com/app.js(원본 320 KB의 JavaScript)를 점검했더니 응답 헤더가 다음과 같았다고 합시다.

• Content-Type: application/javascript — 텍스트 자원이므로 압축 대상이 맞습니다.
• Content-Encoding: br — Brotli가 적용됐습니다. 이 도구는 이 값을 읽어 "압축됨(br)"으로 표시합니다.
• Vary: Accept-Encoding — 캐시가 압축본과 비압축본을 분리 저장하도록 올바르게 설정됨.

이 경우 전송 크기는 보통 70 KB 안팎까지 줄어듭니다(약 78% 절감). 반대로 Content-Encoding이 비어 있고 Content-Type이 application/javascript라면, 압축만 켜도 같은 폭의 절감을 바로 얻을 수 있다는 신호입니다.

흔한 실수 / 함정

• HTML만 보고 압축됐다고 단정하기: 루트 문서는 압축돼도 별도 CDN/스토리지에서 오는 JS·CSS 번들은 압축이 빠진 경우가 많습니다. 가장 무거운 자원의 URL을 직접 넣어 확인하세요.
• 이미 압축된 파일을 다시 압축하려는 시도: .jpg·.png·.woff2에 Content-Encoding이 없다고 문제로 오해하기 쉽지만, 이건 정상입니다. 재압축은 효과 없이 CPU만 씁니다.