Die schnellste HTTP-Anfrage ist die, die nie beim Server ankommt. Besucht jemand Deine Seite zum zweiten Mal, muss ein korrekt gecachtes Logo, Stylesheet oder Schriftpaket kein einziges Byte erneut aus dem Netz laden – es liegt längst im Browser. Das spart nicht nur Millisekunden, sondern jede Datenübertragung, die sonst wieder durch Netz und Rechenzentrum gewandert wäre. Genau deshalb stuft die Sustainable-Web-Design-Community den Energie- und Emissionshebel dieser Guideline als hoch ein – nicht als netten Performance-Bonus, sondern als handfeste Stellschraube für die CO₂-Bilanz.
Die zwei Erfolgskriterien von Guideline 4.2 (meine Übersetzung des Originals):
Ressourcen zwischenspeichern: Setze Caching ein, um Verarbeitungszeit sowie wiederholte Datenbankabfragen, API-Aufrufe und Netzwerkanfragen zu reduzieren. Wende serverseitiges Caching für dynamische Inhalte an und clientseitiges Caching für Ressourcen, die sich selten ändern. Steuere die Lebensdauer des Caches, liefere statische Versionen für stabile Assets aus und minimiere wiederholte Anfragen für häufig genutzte Ressourcen – abgewogen gegen zusätzliche Komplexität und Wartungskosten, um die Datenauslieferung zu verbessern.
Offline-Zugriff: Halte wesentliche Inhalte und Funktionen auch bei Netzwerkunterbrechungen verfügbar. Ermögliche den Offline-Zugriff über Fähigkeiten der Web-Plattform wie Progressive Web Applications (PWA), Service Worker, Web Worker oder lokalen Speicher.
Meine Einordnung
Beide Kriterien zielen auf denselben Punkt: Arbeit, die schon einmal getan wurde, soll nicht bei jedem Aufruf erneut anfallen. Das erste Kriterium trennt dabei sauber zwischen zwei Ebenen. Serverseitig geht es darum, teure Datenbankabfragen und dynamische Berechnungen nicht bei jedem Request zu wiederholen. Clientseitig geht es um die statischen Assets – Bilder, Schriften, CSS, JavaScript –, die im Browser des Besuchers liegen bleiben dürfen.
Die Größenordnung wird schnell greifbar. Eine durchschnittliche Seite zieht laut Web Almanac mehrere Megabyte an Assets. Ohne saubere Cache-Header lädt ein wiederkehrender Besucher davon einen großen Teil bei jedem Klick neu. Mit korrekt gesetzten Headern – etwa einem Jahr Gültigkeit für fingerprintete Dateien – sinkt das beim zweiten Seitenaufruf gegen null. Bei einer Million Seitenaufrufen im Monat ist das kein Rundungsfehler, sondern eingesparte Datenübertragung im hohen Gigabyte-Bereich.
Das Original nennt einen wichtigen Vorbehalt gleich mit: Caching muss gegen zusätzliche Komplexität und Wartungskosten abgewogen werden. Das ist keine Floskel. Der schwierigste Teil am Caching ist nicht das Speichern, sondern das Verwerfen zur richtigen Zeit. Ein veralteter Cache, der geänderte Inhalte festhält, kostet mehr Nerven als er Bytes spart. Genau deshalb sind fingerprintete Dateinamen, bei denen sich der Name mit dem Inhalt ändert, so elegant: Ändert sich die Datei, ändert sich die URL, und die Cache-Frage löst sich von selbst.
In meiner eigenen Toolbox nutze ich Caching aus genau diesem Grund an einer Stelle, an die man zuerst nicht denkt. Meine kleinen PHP-Werkzeuge, die externe APIs abfragen, speichern ihre Antworten dateibasiert zwischen. So löst nicht jeder Besucher denselben teuren API-Aufruf erneut aus. Der Effekt ist nicht in erster Linie Tempo, sondern vermiedene Last – bei mir, beim API-Anbieter und im Netz dazwischen.
Wo ich weiter gehe
Hier setzt mein Vorbehalt an. Caching optimiert den Wiederbesuch. Es sagt nichts über den ersten Kontakt aus – und der trifft jeden neuen Besucher und jeden Bot mit voller Wucht. Wer eine überladene Seite hinter perfekten Cache-Headern versteckt, verlagert das Problem nur auf die, die zum ersten Mal kommen. Und das sind bei den meisten Websites überraschend viele.
Beim zweiten Kriterium bin ich noch vorsichtiger. Offline-Zugriff über Service Worker klingt nach Fortschritt, ist aber zusätzlicher JavaScript-Code, der selbst Energie kostet und gewartet werden will. Für eine App, die unterwegs ohne Netz funktionieren muss, ist das goldrichtig. Für einen Blog, der eine PWA sein möchte, weil es die Checkliste so verlangt, ist es das Gegenteil von Suffizienz. Die Regel bleibt: Baue die Fähigkeit ein, wenn ein echter Bedarf sie rechtfertigt – nicht, weil ein Häkchen fehlt.
Dein erster Schritt heute
Du musst nichts installieren, um Deinen Ist-Zustand zu sehen.
.htaccess oder Server-Konfiguration.Auf einem Apache-Server genügt oft ein kompakter mod_expires-Block, der stabilen Assets wie Icons, Schriften und fingerprinteten Dateien eine lange Gültigkeit gibt. Wer einen Static Site Generator einsetzt, hat die halbe Miete ohnehin schon: Statisch ausgelieferte Seiten sind der Idealfall dessen, was das erste Kriterium mit „serve static versions" meint.
Der sparsamste Cache ist am Ende der, der möglichst wenig zwischenspeichern muss. Denn jede Anfrage, die Du gar nicht erst auslöst, muss auch kein Cache mehr abfangen.
Quellen: W3C-Fassung von Guideline 4.2 · Interpretation bei Sustainable Web Design