Att komprimera samma fil varje gång

Apache komprimerar svar i realtid. För en sida som är olika varje gång är det enda alternativet. För en formatmall som ändras en gång i månaden innebär det att servern gör samma arbete om igen för varje besökare, i veckor, och kastar bort resultatet varje gång. Det finns ingen cache för det.

Uppmätt den 19 augusti 2026 över en befintlig anslutning, med den här webbplatsens style.css (124 kB) och world.js (102 kB):

	tid	byte
ingen komprimering	2,9 ms	124 755
gzip, i realtid	18,1 ms	34 995
brotli, i realtid	14,5 ms	32 685
world.js, gzip	47,9 ms	38 283
world.js, brotli	15,9 ms	38 086

Fyrtioåtta millisekunder CPU-tid per anrop för att ta fram ett resultat som är identiskt byte för byte. På en liten server är det inget avrundningsfel.

Komprimera en gång, på disk

Ett byggsteg skriver den komprimerade filen bredvid originalet, och en omskrivningsregel levererar den när webbläsaren anger att den accepterar gzip. Att leverera en färdig fil kostar lika mycket som att leverera vilken fil som helst.

gzip snarare än brotli, av ett tråkigt skäl: det finns ingen brotli-binär installerad på den här maskinen. Filerna blir ungefär 7 % större än brotli skulle göra dem, och servertiden är en femtedel av vad brotli i realtid kostar. Den avvägningen var värd att göra nu i stället för att vänta på en snyggare lösning.

Versionen hamnar i filnamnet

Bygget skriver style.css.<mtime>.gz, och ?v= i HTML-koden är samma ändringstid. Omskrivningen sker bara när det finns en fil med motsvarande nummer.

Det upplägget har en egenskap som är värd att designa för medvetet: om formatmallen ändras och ombyggnaden glöms bort pekar numret i koden på en fil som inte finns, omskrivningen sker inte och Apache levererar originalet som vanligt. I värsta fall uteblir snabbningen. En inaktuell formatmall kan aldrig levereras. Varje cachningslösning bör prövas mot den frågan — när något går fel, blir det långsamt eller blir det fel?

Buggen mitt i alltihop

Filen som levereras är redan gzip-komprimerad, så den får inte komprimeras igen på vägen ut. Konfigurationen satte ursprungligen no-gzip, vilket stoppar en av Apaches två komprimerare. Den andra, mod_brotli, brotli-komprimerade glatt den färdiga gzip-filen medan svarshuvudet fortsatte att ange gzip.

Webbläsarna fick oläsligt innehåll. Det upptäcktes inte genom att titta på sidan — det upptäcktes genom att summera antalet byte och hitta ett tal som inte gick ihop. Både no-gzip och no-brotli behövs, och bara den ena är den uppenbara.