Caching-Strategien, die jede Anfrage beschleunigen

Effektives Caching findet nicht auf einer einzelnen Ebene statt, sondern als koordiniertes Zusammenspiel mehrerer Schichten. Jede Schicht hat ihre eigene Stärke: Der Browser-Cache eliminiert überflüssige Netzwerkanfragen. Der Applikations-Cache speichert das Ergebnis teurer Datenbankabfragen. Der Reverse-Proxy-Cache fängt vollständig gerenderte Seiten ab, bevor die Anwendung überhaupt kontaktiert wird. Das CDN schließlich reduziert die physische Distanz zwischen Server und Nutzer auf ein Minimum. Wir implementieren alle vier Schichten aufeinander abgestimmt, sodass jede Anfrage so früh wie möglich abgefangen wird.

Browser-Caching wird über HTTP-Response-Header gesteuert, die der Server bei jeder Antwort mitsendet. Diese Header teilen dem Browser mit, wie lange eine Ressource zwischengespeichert werden darf und unter welchen Bedingungen sie erneut validiert werden muss. Die wichtigsten Header sind Cache-Control, ETag und Last-Modified. Eine häufige Fehlerquelle ist das Fehlen dieser Header bei statischen Assets: Ohne Caching-Direktiven speichert der Browser Assets entweder gar nicht oder für sehr kurze Zeit, was zu unnötigen Netzwerkanfragen bei jedem Folgebesuch führt.

Für statische Assets — CSS, JavaScript, Bilder, Schriftarten — setzen wir Cache-Control: public, max-age=31536000, immutable. Das entspricht einem Jahr Cachezeit, die das immutable-Direktiv als unveränderlich markiert. Browser müssen die Ressource bei Seiten-Refreshes nicht erneut validieren, was die Ladezeit für Folgebesuche weiter verkürzt. Damit diese langen Cache-Laufzeiten keine Deployment-Probleme verursachen, implementieren wir Content-Hashing: Jede geänderte Datei erhält einen neuen Fingerprint im Dateinamen (z. B. app.a3f9c2.js). Damit wird der Browser-Cache automatisch invalidiert, ohne dass wir ihn manuell leeren müssen — eine Technik, die als Cache-Busting bekannt ist.

Auf Server-Ebene unterscheiden wir zwischen drei Arten von Caches: dem PHP-OPcache, der kompilierten PHP-Bytecode im Shared Memory hält, dem Applikations-Cache für Datenbankabfrageergebnisse und berechnete Werte, sowie dem Fragment-Cache für einzelne HTML-Blöcke. Alle drei arbeiten komplementär und adressieren unterschiedliche Engpässe in der Anfrageverarbeitung. In der Praxis reduziert die Kombination dieser Schichten die PHP-Ausführungszeit pro Request um 50 bis 80 Prozent (Projekterfahrung).

Ein Reverse Proxy ist die wirksamste Maßnahme gegen hohe Server-Last. Varnish und nginx speichern vollständig gerenderte HTTP-Antworten im Arbeitsspeicher und liefern sie bei identischen Folge-Anfragen in unter 5 Millisekunden aus — ohne dass PHP, die Datenbank oder die Anwendungslogik überhaupt kontaktiert werden. In Projekten mit gut konfiguriertem Reverse-Proxy-Cache beantwortet der Proxy über 90 Prozent aller Anfragen direkt aus dem Cache (Projekterfahrung). Das bedeutet konkret: Neun von zehn Seitenaufrufen kosten den Anwendungsserver keinen einzigen CPU-Zyklus.

Die größte Herausforderung beim Reverse-Proxy-Caching ist die korrekte Behandlung von Cookies und personalisierten Inhalten. Standardmäßig cachen Varnish und nginx keine Anfragen, die Cookies enthalten — weil Cookies auf personalisierte Inhalte hindeuten. Das ist korrekt für eingeloggte Nutzer, aber falsch für anonyme Besucher mit Cookie-Banner- oder Analytics-Cookies. Wir konfigurieren die Cache-Bypass-Logik so, dass echte Personalisierungs-Cookies (Session-ID, Warenkorb) den Cache überspringen, während harmlose Tracking-Cookies ignoriert werden und der Cache aktiv bleibt. Damit erreichen wir hohe Cache-Trefferquoten auch bei Websites mit Cookie-Consent-Bannern.

Ein Content Delivery Network ergänzt das Server-seitige Caching um eine geografisch verteilte Auslieferungsschicht. Statt alle Anfragen an einen einzelnen Ursprungsserver zu schicken, werden gecachte Inhalte von Edge-Servern in der Nähe der Nutzer ausgeliefert. Für Websites mit primär deutschem Publikum sind das Edge-Knoten in Frankfurt, Amsterdam und Paris mit Antwortzeiten unter 20 Millisekunden. Für internationale Projekte reduziert ein CDN die Ladezeiten für Besucher aus Amerika oder Asien um 200 bis 400 Millisekunden (Projekterfahrung).

Cache-Invalidierung — das rechtzeitige Verwerfen veralteter Einträge — ist die technisch anspruchsvollste Komponente jeder Caching-Strategie. Zu kurze Cache-Zeiten verschenken den Performance-Gewinn, zu lange Cache-Zeiten führen dazu, dass Nutzer veraltete Inhalte sehen. Wir implementieren Invalidierungsstrategien, die eine hohe Cache-Trefferquote mit aktuellen Inhalten verbinden, und unterscheiden dabei zwischen drei grundlegenden Ansätzen.

Jedes System bringt eigene Caching-Ebenen, Konfigurationsparameter und Invalidierungsbesonderheiten mit. Generische Caching-Konfigurationen passen nicht auf alle Systeme. Wir kennen die systemspezifischen Besonderheiten für alle gängigen Plattformen und implementieren maßgeschneiderte Caching-Strategien, die das volle Potenzial der jeweiligen Plattform ausschöpfen.

Caching ist kein reines Einrichtungsprojekt. Neue Features, Content-Strukturänderungen und Traffic-Muster können die Cache-Effizienz über Zeit degradieren. Wir richten Monitoring ein, das die Cache-Trefferquote, die TTFB bei Cache-Treffern und Cache-Fehltreffern sowie die Invalidierungshäufigkeit dauerhaft überwacht. Kritische Abweichungen lösen automatische Alerts aus. Alle Metriken werden im Rahmen eines regelmäßigen Performance-Audits auf Basis der aktuellen Nutzungsmuster optimiert.