Caching & Kompression: Statische Assets richtig ausliefern

Was ist das Problem#

Statische Dateien wie CSS, JavaScript, Schriften und Bilder ändern sich zwischen zwei Veröffentlichungen in der Regel nicht. Trotzdem lädt der Browser sie bei jedem erneuten Besuch komplett neu, wenn der Server keine oder eine zu kurze Cache-Gültigkeit angibt. EverAudit prüft dafür zwei zusammenhängende, aber unterschiedliche Ursachen: fehlende oder wirkungslose Cache-Header auf statischen Assets (uses-long-cache-ttl für die Lighthouse-Labormessung, static-asset-uncached für tatsächlich beobachtete Header ohne wirksame Kontrolle) sowie fehlende Textkompression (uses-text-compression) für HTML, CSS, JavaScript, JSON und SVG. Der zusammenfassende Befund cache-insight bündelt das Einsparpotenzial aus der Caching-Konfiguration.

Warum EverAudit das prüft#

Caching und Kompression sind zwei der wenigen Performance-Maßnahmen, die sich fast ausschließlich serverseitig bzw. über die CDN-Konfiguration einrichten lassen — einmal korrekt konfiguriert, wirken sie dauerhaft für alle wiederkehrenden Besucher und alle Textressourcen, ohne dass am eigentlichen Code oder an den Bildern etwas geändert werden muss. Weil beide Maßnahmen oft übersehen werden — insbesondere bei Standard-Hosting-Konfigurationen ohne aktive Einrichtung — prüft EverAudit sie explizit und getrennt: fehlende Kompression betrifft jede einzelne Übertragung, fehlendes Caching betrifft speziell wiederkehrende Besucher.

Welche Auswirkung hat es#

Ohne wirksames Caching lädt jede wiederkehrende Seite eines Besuchers dieselben CSS-, JS- und Font-Dateien erneut vom Server, statt sie aus dem lokalen Browser-Speicher zu verwenden — das kostet spürbar Ladezeit bei jedem weiteren Seitenaufruf, nicht nur beim ersten Besuch. Fehlende Kompression vergrößert zusätzlich jede einzelne Übertragung von Textdateien, was sich besonders bei mobiler Verbindung und größeren HTML-, CSS- oder JavaScript-Dateien bemerkbar macht. Beide Effekte summieren sich über eine Sitzung mit mehreren Seitenaufrufen und wirken sich damit stärker aus, als eine einzelne Ladezeitmessung zunächst vermuten lässt.

Wie Sie es beheben#

1. Textkompression auf dem Server bzw. CDN aktivieren. Brotli ist für Text-Inhalte in der Regel effizienter als gzip; viele Server und CDNs unterstützen beides parallel mit automatischer Aushandlung über den Accept-Encoding-Header. Bei den meisten Hosting- und CDN-Anbietern lässt sich das über eine Konfigurationsoption aktivieren, ohne den Code anzufassen.

2. Lange Cache-Gültigkeit für gehashte, unveränderliche Assets setzen:

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

Das funktioniert sicher nur, wenn der Dateiname bei jeder inhaltlichen Änderung mitwechselt (Content-Hashing im Build, z. B. app.a1b2c3.js) — sonst würden Besucher über ein Jahr lang eine veraltete Version erhalten.

3. HTML kurz oder gar nicht cachen. Da HTML-Dokumente meist unter einer stabilen URL ausgeliefert werden und sich inhaltlich ändern können, sollte hier eine kurze max-age oder no-cache (mit Revalidierung) gesetzt werden, statt derselben langen Gültigkeit wie bei gehashten Assets.

4. Für unversionierte Dateien ETag oder Last-Modified ergänzen. Wo Content-Hashing nicht möglich ist (etwa bei nutzergenerierten Uploads), erlaubt ein ETag- oder Last-Modified-Header dem Browser eine günstige Revalidierung: Bei unverändertem Inhalt antwortet der Server mit 304 Not Modified statt die Datei erneut vollständig zu übertragen.

5. Die Konfiguration mit den Chrome DevTools verifizieren. Im Network-Tab zeigt jede Anfrage den tatsächlich gesendeten Cache-Control-Header sowie an, ob eine spätere Anfrage aus dem Cache bedient wurde — das ist der zuverlässigste Weg, eine Serverkonfiguration nach der Umstellung zu bestätigen.

6. CDN-Einstellungen nicht vergessen. Wird eine Website über ein CDN ausgeliefert, muss die Cache-Konfiguration teils zusätzlich oder anstelle der Origin-Server-Einstellung im CDN selbst vorgenommen werden — beide Ebenen sollten übereinstimmen.

Fazit#

Caching und Kompression zählen zu den Maßnahmen mit dem geringsten Umsetzungsaufwand und der breitesten Wirkung: Einmal korrekt konfiguriert, profitiert jeder wiederkehrende Besucher und jede Textübertragung automatisch davon, ohne dass am eigentlichen Code etwas geändert werden muss. Die Kombination aus langer Cache-Gültigkeit für gehashte Assets, kurzer Gültigkeit für HTML und aktivierter Brotli-/gzip-Kompression deckt die häufigsten Ursachen zuverlässig ab.