같은 파일을 매번 다시 압축하기

아파치는 응답을 그 자리에서 압축합니다. 매번 달라지는 페이지라면 그것 말고는 길이 없습니다. 한 달에 한 번 바뀌는 스타일시트라면, 서버가 방문자마다 같은 일을 몇 주 동안 되풀이하고 그 결과를 매번 버린다는 뜻입니다. 그것을 위한 캐시는 없습니다.

2026년 8월 19일, 이미 열린 연결에서 이 사이트 자신의 style.css(124kB)와 world.js(102kB)로 잰 값입니다:

	시간	바이트
압축 없음	2.9ms	124,755
gzip, 그 자리에서	18.1ms	34,995
brotli, 그 자리에서	14.5ms	32,685
world.js, gzip	47.9ms	38,283
world.js, brotli	15.9ms	38,086

바이트 단위로 똑같은 결과를 만들려고 요청마다 48밀리초의 프로세서 시간을 씁니다. 작은 서버에서 그것은 반올림 오차가 아닙니다.

디스크에서 한 번만 압축하기

빌드 단계가 압축된 파일을 원본 옆에 쓰고, 브라우저가 gzip을 받는다고 말하면 재작성 규칙이 그것을 내보냅니다. 완성된 파일을 내보내는 값은 어떤 파일을 내보내는 값과 같습니다.

brotli가 아니라 gzip인 데에는 밋밋한 까닭이 있습니다. 이 기계에 brotli 실행 파일이 없습니다. 파일은 brotli로 만들었을 때보다 약 7% 크고, 서버 시간은 그 자리에서 brotli를 돌릴 때의 5분의 1입니다. 더 나은 답을 기다리기보다 지금 그 맞바꿈을 하는 편이 나았습니다.

판본이 파일 이름에 들어갑니다

빌드는 style.css.<mtime>.gz을 쓰고, 마크업의 ?v=은 바로 그 수정 시각입니다. 재작성은 그 숫자와 맞는 파일이 있을 때만 실행됩니다.

그 얼개에는 일부러 설계할 값어치가 있는 성질이 있습니다. 스타일시트가 바뀌었는데 다시 빌드하는 것을 잊으면, 마크업의 숫자는 없는 파일을 가리키고, 재작성은 실행되지 않고, 아파치는 원본을 평소대로 내보냅니다. 최악의 경우는 빨라지지 않는 것뿐입니다. 낡은 스타일시트가 나갈 수는 없습니다. 모든 캐시 방식은 그 물음에 맞대어 보아야 합니다 — 잘못될 때 느려지는가, 아니면 틀려지는가?

그 한가운데 있던 결함

내보내는 파일은 이미 gzip이므로 나가는 길에 다시 압축되어서는 안 됩니다. 설정은 처음에 no-gzip을 두었고, 그것은 아파치의 두 압축기 가운데 하나를 멈춥니다. 다른 하나인 mod_brotli는 완성된 gzip 파일을 신나게 brotli로 압축했고, 응답 헤더는 그동안 계속 gzip이라고 말했습니다.

브라우저는 읽을 수 없는 내용을 받았습니다. 페이지를 봐서 잡힌 것이 아니라, 바이트를 더해 보고 말이 안 되는 숫자를 발견해 잡혔습니다. no-gzip과 no-brotli 둘 다 필요하고, 그 가운데 하나만 눈에 띕니다.