Caching und Komprimierung: die kostenlose Geschwindigkeit, die niemand abholt

Cache-Control, das wirklich cacht, warum ein Hash im Dateinamen alles ändert, und die Komprimierungseinstellung, die auf der Hälfte der Websites noch fehlt.

Infrastruktur · Veröffentlicht: 30. August 2026 · 3 Min. Lesezeit · Анна Ковалёва

Die meiste Performance-Arbeit ist teuer: Komponenten umschreiben, Skripte verzögern, über ein Framework streiten. Zwei Einstellungen sind es nicht. Sie stehen in einer Konfigurationsdatei, kosten einen Nachmittag — und sind auf einem erheblichen Teil der Produktivsysteme immer noch falsch.

Zuerst die Komprimierung

Text komprimiert sich um siebzig bis achtzig Prozent. HTML, CSS, JavaScript, JSON, SVG — alles Text. Fehlt der Response ein Content-Encoding, liefern Sie das Vierfache an Bytes für nichts.

Brotli schlägt gzip bei gleichem Inhalt um rund fünfzehn Prozent und wird überall unterstützt, wo es zählt; gzip bleibt der Fallback. Zwei Fehler sind häufig: Bilder zu komprimieren (JPEG und PNG sind bereits komprimiert — Sie verbrennen CPU für nichts) und zu vergessen, dass die Einstellung pro MIME-Typ gilt, sodass eine Subdomain, die JSON aus einer anderen Konfiguration ausliefert, es still und leise roh sendet.

Cache-Control, ehrlich

Der Header beantwortet zwei Fragen: Darf das gespeichert werden, und wie lange. Nützliche Muster gibt es wenige.

Assets mit Hash — /app.4f2a91.js:

Cache-Control: public, max-age=31536000, immutable

Ein Jahr, ohne Revalidierung. Sicher genau deshalb, weil sich der Dateiname mit dem Inhalt ändert. Das ist der größte verfügbare Gewinn — und er funktioniert nur, wenn Ihr Build die Namen tatsächlich hasht.

HTML:

Cache-Control: no-cache

Entgegen dem Namen heißt das nicht "nicht cachen". Es heißt "speichern, aber vor der Nutzung rückfragen". Der Browser schickt ein If-None-Match und bekommt meist eine 304 ohne Body — schnell und nie veraltet.

Personalisierte Antworten:

Cache-Control: private, no-store

Für alles, was ein geteilter Cache niemals behalten darf: Kontoseiten, Warenkörbe, alles hinter dem Login.

Die teuersten Fehler

Kurzes max-age auf gehashten Dateien. max-age=600 auf einem Namen mit Content-Hash wirft den gesamten Vorteil weg.

Langes max-age auf ungehashten Dateien. /logo.png ein Jahr lang gecacht heißt: Das Redesign erreicht niemanden, der vorher da war.

Fehlendes ETag oder Last-Modified auf HTML. Ohne Validator kann der Browser nicht fragen "hat sich das geändert" — er lädt das ganze Dokument erneut.

Falsch gesetztes Vary. Vary: User-Agent zersplittert einen CDN-Cache in Tausende nahezu identischer Einträge und ist fast nie gemeint.

Beweisen statt annehmen

Konfiguration ist das eine, was tatsächlich im Browser ankommt das andere: Ein CDN, ein Proxy oder ein Hosting-Panel kann Header auf dem Weg umschreiben. Die Prüfung läuft pro Response über die ganze Website:

für jede response:
  content-encoding auf text/* vorhanden?
  passt cache-control zur asset-klasse?
  etag oder last-modified auf dokumenten?

Nach jedem Deploy ausführen. Diese Regressionsklasse ist lautlos — nichts geht kaputt, die Website wird nur langsamer und die Traffic-Rechnung höher — und genau deshalb überlebt sie Jahre, solange niemand hinsieht.