Dieselbe Datei jedes Mal neu komprimieren

Apache komprimiert Antworten im Vorbeigehen. Für eine Seite, die jedes Mal anders aussieht, ist das der einzige Weg. Für ein Stilblatt, das sich einmal im Monat ändert, bedeutet es, dass der Server dieselbe Arbeit für jeden Besucher noch einmal macht, wochenlang, und das Ergebnis jedes Mal wegwirft. Einen Zwischenspeicher dafür gibt es nicht.

Gemessen am 19. August 2026 über eine bestehende Verbindung, mit dem eigenen style.css (124 kB) und world.js (102 kB) dieser Seite:

	Zeit	Bytes
ohne Kompression	2,9 ms	124.755
gzip, im Vorbeigehen	18,1 ms	34.995
brotli, im Vorbeigehen	14,5 ms	32.685
world.js, gzip	47,9 ms	38.283
world.js, brotli	15,9 ms	38.086

Achtundvierzig Millisekunden Rechenzeit, je Anfrage, für ein Byte für Byte identisches Ergebnis. Auf einem Raspberry Pi ist das kein Rundungsfehler.

Einmal komprimieren, auf die Platte

Ein Bauschritt legt die komprimierte Datei neben das Original, und eine Umschreiberegel liefert sie aus, wenn der Browser sagt, dass er gzip annimmt. Eine fertige Datei auszuliefern kostet, was das Ausliefern jeder Datei kostet.

gzip statt brotli, aus einem langweiligen Grund: auf dieser Maschine ist kein brotli-Befehl installiert. Die Dateien werden dadurch rund 7 % größer als mit brotli, und die Serverzeit ist ein Fünftel dessen, was brotli im Vorbeigehen kostet. Dieser Tausch war es wert, jetzt gemacht zu werden statt auf die schönere Antwort zu warten.

Die Version steht im Dateinamen

Der Bauschritt schreibt style.css.<mtime>.gz, und das ?v= im Markup ist dieselbe Änderungszeit. Die Umschreiberegel greift nur, wenn eine Datei mit der passenden Zahl existiert.

Diese Anordnung hat eine Eigenschaft, für die es sich zu entwerfen lohnt: wer das Stilblatt ändert und das Neubauen vergisst, hat im Markup eine Zahl, zu der es keine Datei gibt, die Regel greift nicht, und Apache liefert ganz normal das Original aus. Der schlimmste Fall ist, dass die Beschleunigung fehlt. Ein veraltetes Stilblatt kann nicht herauskommen. Jedes Zwischenspeicherverfahren sollte gegen diese Frage geprüft werden — wenn es schiefgeht, wird es dann langsam oder wird es falsch?

Der Fehler mittendrin

Die ausgelieferte Datei ist bereits gzip, sie darf also auf dem Weg nach draußen nicht noch einmal komprimiert werden. In der Konfiguration stand zuerst no-gzip, und das hält einen der beiden Komprimierer von Apache auf. Der andere, mod_brotli, packte die fertige gzip-Datei fröhlich noch einmal in brotli, während der Antwortkopf weiter gzip behauptete.

Browser bekamen unlesbaren Inhalt. Aufgefallen ist es nicht beim Ansehen der Seite — aufgefallen ist es beim Zusammenrechnen der Bytes, wo eine Zahl herauskam, die keinen Sinn ergab. Nötig sind beide, no-gzip und no-brotli, und nur eines von beiden ist das naheliegende.