Gzip·Brotli 압축 적용 확인｜헤더·캐시·원복 20분 점검

Gzip과 Brotli를 켰다고 모든 파일이 더 빨라지는 것은 아닙니다. HTML·CSS·JavaScript 같은 텍스트는 효과가 크지만 이미 압축된 이미지와 동영상은 이득이 거의 없고 CPU만 사용할 수 있습니다. 또한 CDN과 원본 서버가 함께 압축할 때 캐시 키가 잘못되면 일부 방문자에게 깨진 응답을 보낼 수 있습니다.

요청의 Accept-Encoding, 응답의 Content-Encoding과 Vary, 실제 전송량과 CPU 변화를 확인하는 20분 점검 순서입니다.

10초 요약

• Brotli가 항상 정답은 아니며 파일별 전송량과 압축 CPU를 함께 비교합니다.
• 브라우저가 지원 형식을 Accept-Encoding으로 알리고 서버가 하나를 선택합니다.
• 응답에는 실제 사용한 형식이 Content-Encoding: br 또는 gzip으로 표시됩니다.
• 캐시는 Vary: Accept-Encoding을 기준으로 다른 응답을 구분해야 합니다.
• HTML·CSS·JS·JSON·SVG 등 텍스트부터 적용합니다.
• 문제가 생기면 CDN과 원본 중 한 계층만 남겨 원인을 구분합니다.

Gzip과 Brotli의 실무 차이

비교 항목	Gzip	Brotli
응답 헤더	Content-Encoding: gzip	Content-Encoding: br
압축 품질 범위	서버 구현에 따라 보통 1~9	Apache 기준 0~11
동적 응답	낮은 CPU 비용으로 널리 사용	품질을 높이면 압축 시간이 크게 늘 수 있음
정적 파일	.gz 미리 생성 가능	.br 미리 생성 가능
운영 원칙	호환용 대안으로 유지	지원 클라이언트에 우선 제공 가능

Brotli가 더 작은 파일을 만드는 경우가 많지만 절감률은 코드·품질·파일 크기에 따라 달라집니다. 동적 HTML은 최고 품질보다 응답 시간과 CPU를 우선하고, 정적 파일은 사전 압축을 검토하세요.

1단계: 현재 응답 헤더 세 번 확인

같은 CSS나 JavaScript URL에 Brotli, Gzip, 무압축 요청을 각각 보내세요. 홈페이지 HTML만 확인하면 캐시 플러그인과 로그인 쿠키 때문에 결과가 달라질 수 있으므로 텍스트 정적 파일도 함께 검사합니다.

curl -sI -H "Accept-Encoding: br" https://example.com/style.css
curl -sI -H "Accept-Encoding: gzip" https://example.com/style.css
curl -sI -H "Accept-Encoding: identity" https://example.com/style.css

확인 헤더	정상 신호	이상할 때 볼 곳
Content-Encoding	요청한 형식 중 서버가 선택한 하나	웹서버·CDN 압축 설정
Content-Type	text/css·application/javascript 등	MIME 형식과 압축 대상 목록
Vary	Accept-Encoding 포함	프록시·CDN 캐시 구분
Content-Length	형식별 전송 크기 차이	chunked 응답이면 DevTools 전송량
Cache-Control	리소스 변경 주기에 맞는 정책	브라우저·CDN의 오래된 복사본

Accept-Encoding은 지원 형식을, Content-Encoding은 실제 압축 형식을 뜻합니다. 형식별 응답은 Vary: Accept-Encoding으로 캐시에서 구분합니다.

2단계: 실제 전송량과 시간을 비교

curl -s --compressed -o NUL -w "size=%{size_download} time=%{time_total}\n" https://example.com/app.js

Linux·macOS에서는 NUL을 /dev/null로 바꿉니다. 첫 요청에는 CDN MISS가 포함될 수 있으므로 여러 번 측정해 중간값을 기록하세요.

• 원본 크기와 전송 크기를 구분합니다.
• 캐시 HIT와 MISS 결과를 섞지 않습니다.
• 서버 CPU와 응답시간 p95 증가를 확인합니다.
• HTML·CSS·JS를 각각 측정합니다.

JavaScript 원본이 너무 크면 압축 형식만 바꿔도 실행 비용은 줄지 않습니다. 전송 뒤 파싱·컴파일·실행 비용은 JS 번들 Coverage와 코드 분할 진단으로 별도 점검하세요.

3단계: 압축할 파일과 제외할 파일 분리

• 우선 적용: HTML, CSS, JavaScript, JSON, XML, SVG와 텍스트 폰트 설명 파일
• 측정 후 결정: 작은 파일, 짧은 API 응답, 자주 바뀌는 동적 HTML
• 대체로 제외: JPEG, PNG, WebP, AVIF, MP4, ZIP, PDF처럼 자체 압축된 형식

이미지는 압축 형식보다 표시 크기와 포맷 영향이 큽니다. 이미지 크기·WebP·AVIF 점검으로 원본부터 줄이세요. 작은 응답은 실제 이득을 측정한 뒤 최소 길이를 정합니다.

4단계: 웹서버 설정은 최소 범위부터

Nginx는 gzip_types에 text/html 이외의 MIME 형식을 추가합니다. 다음 예시는 테스트 경로에서 먼저 검증하세요.

gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;

Nginx의 Brotli 지원 방식은 배포판마다 다르므로 호스팅 문서를 확인하세요. Apache mod_brotli는 품질 0~11을 지원합니다. 값을 올리기 전에 CPU와 p95 응답을 비교하세요.

설정 사본과 문법 검사를 준비한 뒤 테스트 경로부터 재로드하세요. 관리자 화면, REST API와 파일 다운로드도 검사합니다.

5단계: CDN과 원본의 역할 구분

CDN은 엣지에서 압축 형식을 다시 선택할 수 있습니다. 방문자 헤더만으로 원본 응답을 단정하지 말고 원본 테스트 주소와 공개 주소를 각각 측정하세요.

• 공개 주소의 CF-Cache-Status와 압축 형식을 기록합니다.
• 원본과 CDN을 각각 한 번씩 우회해 비교합니다.
• 중복 압축과 잘못된 캐시 응답을 확인합니다.
• 캐시는 테스트 파일 URL만 우선 삭제합니다.

Cloudflare 연결과 캐시 계층을 함께 점검하려면 Cloudflare 워드프레스 SSL·캐시 설정을 참고하세요. 페이지 캐시 플러그인까지 있다면 캐시 중복 방지와 원복 순서로 계층을 하나씩 분리합니다.

20분 적용과 원복 순서

1. 0~5분: HTML·CSS·JS의 헤더와 전송 크기를 세 형식으로 기록합니다.
2. 5~10분: CDN·웹서버·플러그인 중 실제 압축 담당 계층을 찾습니다.
3. 10~15분: 텍스트 MIME 형식과 최소 크기부터 한 곳에 적용합니다.
4. 15~18분: 응답 헤더, 전송량, CPU와 로그인·API 기능을 다시 확인합니다.
5. 18~20분: 문제가 있으면 마지막 변경을 끄고 해당 URL 캐시만 삭제합니다.

비밀값을 반영하는 인증 응답은 압축 기반 BREACH 위험을 검토하세요. 공개 정적 파일과 개인 응답을 같은 정책으로 묶지 않습니다.

TIP

‘Brotli가 켜졌다’보다 app.js 전송량, 서버 p95와 CPU 변화를 기록하세요. 전송량이 줄어도 원본 응답이 늦으면 체감 속도는 좋아지지 않을 수 있습니다.

자주 묻는 질문

Brotli를 켜면 Gzip은 꺼야 하나요?

지원 클라이언트에는 Brotli, 그 밖에는 Gzip이나 무압축 응답을 제공할 수 있습니다. 실제 협상 결과는 헤더로 확인하세요.

PageSpeed에서 텍스트 압축 경고가 남는 이유는 무엇인가요?

일부 MIME 형식이 목록에서 빠졌거나 CDN 우회 주소, 외부 도메인 리소스 또는 작은 응답일 수 있습니다. 경고에 표시된 정확한 URL의 Content-Type과 Content-Encoding을 확인하세요.

공식 자료

• Nginx Gzip 모듈
• Apache mod_brotli
• RFC 9110 HTTP 압축 협상
• Cloudflare 콘텐츠 압축

마무리

Gzip과 Brotli는 실제 전송 결과로 판단합니다. 세 응답과 캐시 상태를 비교한 뒤 한 계층에 먼저 적용하세요. 전송량, CPU, p95와 기능을 함께 기록하면 개선 여부를 확인할 수 있습니다.