Cacheebenen, Varianten und Invalidierung zuordnen: Eine Architekturmatrix für WordPress, Origin, CDN, Browser und private Zustände.
Ein Cacheproblem lässt sich leichter lösen, wenn die Antwort einer Schicht zugeordnet werden kann. LSCache ist dabei ein Teil einer möglichen Architektur. Dieser Leitfaden zeichnet den Weg vom Browser zur Anwendung und entwickelt eine kleine Zuständigkeitsmatrix für Betrieb, Änderungen und Diagnose.
Wählen Sie eine vorhandene öffentliche Seite, zum Beispiel einen Ratgeber. Notieren Sie die vollständige URL mit Protokoll, Hostname, Pfad und gegebenenfalls Querystring. Öffnen Sie die Seite anschließend in einer anonymen Sitzung. Diese feste Referenz verhindert, dass verschiedene Beteiligte unbemerkt andere Zustände untersuchen. Ein Aufruf als angemeldeter Administrator kann einen anderen Pfad verwenden als der Aufruf eines Lesers. Auch eine Adresse mit abweichendem Hostnamen kann zunächst durch eine Weiterleitung laufen.
Die Architektur beginnt bereits vor WordPress. DNS liefert eine Zieladresse. Der Browser baut eine Verbindung auf und prüft das Zertifikat. Eine vorgeschaltete Plattform kann die Anfrage übernehmen, weiterleiten oder selbst beantworten. Erst danach erreicht der Request möglicherweise den originären Webserver. Wenn die Seitenansicht falsch ist, lohnt sich deshalb die Frage, ob die Anwendung überhaupt angesprochen wurde. Ein Pluginwechsel kann keinen alten Inhalt korrigieren, der ausschließlich aus einer vorgelagerten Kopie stammt.
Zeichnen Sie zunächst nur nachweislich vorhandene Komponenten ein. Ein mögliches CDN wird als ungeklärt markiert, bis DNS, Anbieterbestand oder passende Antwortbelege seine Rolle bestätigen. Ein Markenheader allein kann unvollständig sein. Ziel ist kein beeindruckendes Schaubild, sondern eine brauchbare Karte. Jeder eingezeichnete Knoten sollte eine konkrete Frage beantworten: Was empfängt er, was speichert er und wohin gibt er die Anfrage weiter?
| Schicht | Typischer gespeicherter Inhalt | Änderungsfrage |
|---|---|---|
| Browser | Bilder, CSS, JavaScript, gegebenenfalls Dokumente | Erkennt die Dateiversion die neue Fassung? |
| CDN oder Reverse Proxy | Öffentliche Antworten und statische Ressourcen | Erreicht die Invalidierung alle relevanten Kopien? |
| LSCache am Origin | Geeignete fertige Seitenantworten | Welche Tags, Varianten und TTL gelten? |
| WordPress Object Cache | Wiederverwendbare Anwendungsobjekte | Wer invalidiert geänderte Objekte? |
| PHP OPcache | Kompilierter PHP-Code | Wie werden Codeupdates wirksam? |
| Datenbank | Primäre Inhalte und Einstellungen | Ist die gespeicherte Information korrekt? |
Die Matrix trennt bewusst Cache und Primärdaten. Ein Cache soll aus einem verlässlichen Ursprung wiederherstellbar sein. Die Datenbank ist gewöhnlich Teil dieses Ursprungs und benötigt einen anderen Schutz. Das Leeren eines Caches ist deshalb nicht mit dem Löschen von Inhaltsdaten gleichzusetzen. Eine Diagnoseanleitung, die beides ohne genaue Abgrenzung vermischt, kann aus einem Darstellungsproblem einen Datenverlust machen.
Die WordPress-Dokumentation zum Caching beschreibt mehrere Ebenen. Für die konkrete Architektur bleibt zu prüfen, welche davon tatsächlich eingesetzt werden. Ein Object-Cache-Plugin kann installiert sein, ohne eine nutzbare Verbindung zu einem Cachebackend zu besitzen. OPcache kann in einer CLI-Laufzeit anders konfiguriert sein als im PHP-Prozess der Website. Ein Zustandsnachweis gehört immer zum relevanten Pfad.
Eine gespeicherte Seite ist nur hilfreich, wenn sie zur Anfrage passt. Der Schlüssel und seine Varianten müssen die Unterschiede berücksichtigen, die für den Inhalt relevant sind. Dazu können URL, ausgewählte Cookies oder ein bestimmter Besucherzustand gehören. Werden Unterschiede ignoriert, erhält jemand die falsche Ansicht. Werden zu viele nebensächliche Unterschiede aufgenommen, entstehen zahlreiche Kopien, die nur selten wiederverwendet werden. Beides ist ein Architekturproblem.
Ein Beispiel ist eine Produktübersicht, deren Sortierung über einen Queryparameter gewählt wird. Die Sortierung verändert den Inhalt und darf nicht versehentlich mit einer anderen Auswahl vermischt werden. Ein reiner Kampagnenparameter kann dagegen dieselbe öffentliche Seite adressieren. Ob solche Parameter ignoriert werden dürfen, hängt von der Anwendung ab. Eine Analyse braucht daher reale URLs und die Kenntnis ihrer Bedeutung. Ein pauschales Entfernen aller Querystrings wäre keine sichere Vereinfachung.
Cookies verlangen die gleiche Sorgfalt. Ein Cookie kann einen Login kennzeichnen, einen Warenkorb begleiten oder lediglich eine Darstellungspräferenz speichern. Die LiteSpeed-Dokumentation zu Cache Vary erläutert die technische Variationssteuerung. Für Betreiber ist der erste Schritt eine fachliche Zuordnung: Ändert der Cookie den sichtbaren Inhalt? Enthält die daraus entstehende Ansicht personenbezogene Daten? Soll die Antwort gemeinsam oder individuell verwendet werden?
Eine TTL legt fest, wie lange eine Kopie nutzbar bleibt. Sie ist kein Versprechen, dass der Inhalt in dieser Zeit unverändert bleibt. Eine Änderungsmeldung kann eine Kopie vorher ungültig machen. Umgekehrt kann eine fehlende Änderungsmeldung dazu führen, dass sie bis zum Ablauf eine alte Fassung zeigt. Die Architektur braucht deshalb beides: passende Lebensdauern und verlässliche Invalidierung wichtiger Änderungen. Nur eine kurze TTL zu setzen, ersetzt keine funktionierende Ereignisintegration.
Für eine Redaktion lohnt sich ein Abhängigkeitsplan. Ein Artikel steht auf seiner Einzelansicht und erscheint zusätzlich in Übersichten. Eine Änderung seiner Kategorie betrifft andere Zusammenstellungen als eine reine Textkorrektur. Ein globales Menü erscheint auf vielen Seiten. Der technische Cache kann diese Beziehungen über Tags und Ereignisse abbilden, aber ungewöhnliche Erweiterungen brauchen möglicherweise zusätzliche Integration. Der Leitfaden zu TTL und Purge entwickelt daraus ein praktisches Änderungsprotokoll.
Bei mehreren Cacheebenen muss außerdem der Weg einer Invalidierung bekannt sein. Wird nur der Origin geleert, kann das CDN weiterhin eine eigene Kopie ausliefern. Wird nur das CDN geleert, kann es anschließend eine alte Originantwort neu speichern. Ein erfolgreicher Purgebutton an einer Stelle sagt daher noch nicht, dass die sichtbare Information überall aktuell ist. Entscheidend ist die anschließend geprüfte Antwort an der tatsächlichen Besucheradresse.
Die öffentliche Architektur sollte von Anfang an neben dem privaten Pfad stehen. Ein Konto, ein Warenkorb oder eine Vorschau kann andere Cachevorgaben benötigen. Nicht jede dynamische Seite muss privat sein, und nicht jede private Funktion befindet sich auf einer offensichtlich privaten URL. Eine persönliche Begrüßung im Header kann auch die öffentliche Startseite verändern. Deshalb werden alle sichtbaren Komponenten nach ihrer Zuständigkeit untersucht.
Eine einfache Architektur lässt ungeeignete Antworten dynamisch. Eine komplexere Architektur kann unterstützte Fragmentfunktionen einsetzen. ESI teilt Teile einer Seite in eigene Antworten auf, sofern die eingesetzte Plattform und Integration es ermöglichen. Das verlangt zusätzliche Prüfungen: Eine öffentliche Hülle und ein privates Fragment müssen für zwei getrennte Sitzungen korrekt zusammenspielen. OpenLiteSpeed unterstützt ESI nach der aktuellen LiteSpeed-Dokumentation nicht. Eine Architekturzeichnung darf diese Fähigkeit nicht voraussetzen.
Für die erste Abnahme reichen zwei bewusst getrennte Nutzerzustände. Sitzung A erhält eine definierte persönliche Information, Sitzung B eine andere oder keine. Beide öffnen dieselben relevanten Seiten nacheinander. Es werden Inhalt und Header untersucht. Dieser Test ist aussagekräftiger als ein einzelner Aufruf im Administratorkonto. Er prüft direkt die wichtigste Grenze: Eine Antwort darf ihre eigene Nutzerzuordnung nicht verlieren.
Mehrere Werkzeuge können dieselbe Funktion anbieten. Ein Theme minimiert CSS, ein Plugin minimiert es erneut und ein CDN verändert die Datei ein drittes Mal. Das kann die Fehlersuche erschweren und Funktionen beschädigen. Die Architekturmatrix sollte deshalb auch den Konfigurationsbesitz festhalten. Für jede Transformation gibt es eine bewusst gewählte Stelle. Andere Stellen werden nur ergänzt, wenn ihr zusätzlicher Zweck klar beschrieben und getestet wurde.
Diese Zuordnung betrifft auch Redirects, Kompression und Sicherheitsheader. Ein Panel kann eine HTTPS-Weiterleitung erzeugen, während WordPress ebenfalls eine Weiterleitung ausführt. Unterschiedliche Hauptadressen können daraus eine Schleife machen. Ein Reverse Proxy kann ein Protokoll anders melden als der Origin erwartet. Solche Fehler werden verständlich, wenn jede Stufe und ihre Eingaben dokumentiert sind. Ein weiterer Cache wird sie nicht zuverlässig lösen.
Praktisch genügen für jede Funktion vier Felder: zuständige Komponente, aktuelle Einstellung, verantwortliche Person oder Rolle und Abnahmetest. Das ist kein vollständiges Betriebsbuch, aber eine brauchbare Arbeitsgrundlage. Die Notizen sollten ohne Zugangsdaten auskommen. Geheimnisse gehören in einen geschützten Zugangsspeicher; die Architektur braucht lediglich sichere Referenzen und verständliche Zuständigkeiten.
Der Originvergleich ist besonders nützlich, wenn eine vorgeschaltete Plattform andere Antworten liefert. Er muss aber technisch korrekt erfolgen. Hostname und Zertifikatsprüfung bleiben erhalten; eine Verbindung zu einer IP mit abgeschalteter TLS-Prüfung ist kein gleichwertiger Beleg für den regulären Besucherpfad. Ebenso wird ein direkter erfolgreicher IPv6-Aufruf getrennt von einer veröffentlichten AAAA-Adresse bewertet. Die Architektur umfasst sowohl vorhandene Fähigkeiten als auch die tatsächlich verwendete Verbindung.
Am Ende des Durchlaufs bleibt eine kurze, nachvollziehbare Aussage: Welche URL wurde in welchem Zustand von welcher Schicht beantwortet und war der Inhalt korrekt? Diese Formulierung ist präziser als „Cache funktioniert“. Sie hilft bei Supportanfragen, bei Änderungen und beim späteren Hostingwechsel. Wenn die Antwort nicht eindeutig zugeordnet werden kann, ist genau diese Unklarheit der nächste Prüfpunkt.
Ein Fachportal verwendet WordPress, einen Origin-Seiten-Cache und versionierte statische Dateien. Persönliche Konten bleiben dynamisch, während öffentliche Ratgeber eine gemeinsame Kopie erhalten. Die Redaktion veröffentlicht über WordPress und prüft anschließend Artikel und Themenübersicht. CSS-Optimierung hat genau einen Besitzer. Ein optionales CDN wird erst ergänzt, wenn sein Zweck und die Invalidierung dokumentiert sind. Diese Architektur ist weder eine Universalempfehlung noch ein gemessener Bestfall; sie zeigt eine beherrschbare Ausgangslage.
Wächst das Portal, wird jede zusätzliche Ebene an einer konkreten Beobachtung begründet. Häufige dynamische Datenbankzugriffe können Anlass sein, Object Caching zu prüfen. Internationale Besucher können einen Anlass für eine CDN-Bewertung liefern. Ein langsames Titelbild verlangt zuerst die Untersuchung von Bildgröße und Priorität. Die Architektur bleibt dadurch verständlich, weil jede Erweiterung ein benanntes Problem bearbeitet und einen eigenen Abnahmetest erhält.
Haken Sie einen Punkt erst ab, wenn der zugehörige Befund in Ihrer Architekturmatrix steht. Die Liste unterstützt die eigene Abnahme; ein gesetztes Häkchen führt keinen Servertest aus. Mit aktivierter interaktiver Darstellung bleibt der Fortschritt in diesem Browser und kann zurückgesetzt werden.
7. Oktober 2026. Die Matrix und Szenarien sind eigene redaktionelle Arbeit, keine Behauptung einer konkret eingesetzten Tarifarchitektur.