ESI in LiteSpeed verstehen: Servervoraussetzungen, öffentliche und private Fragmente, Nonces sowie konkrete Tests mit getrennten Sitzungen.
ESI setzt eine Seite aus getrennt behandelten Bestandteilen zusammen. Ein öffentlicher Artikel kann aus dem Seitencache stammen, während ein persönlicher Bereich zur aktuellen Sitzung gehört. Der Gewinn hängt davon ab, ob diese Aufteilung zur Anwendung passt. Dieser Leitfaden behandelt Voraussetzungen, Fragmentgrenzen und die Abnahme mit zwei getrennten Nutzern.
Stellen Sie sich eine allgemeine Wissensseite mit einem persönlichen Begrüßungsbereich vor. Der Artikeltext ist für alle Besucher gleich. Der Name in der Begrüßung ist es nicht. Ohne eine passende Trennung muss die vollständige Antwort entsprechend persönlich behandelt werden. Mit einer geeigneten ESI-Integration lassen sich diese Bestandteile getrennt erzeugen und zusammensetzen. Das ist eine konzeptionelle Illustration, keine Aussage über eine bereits gemessene Installation.
Erstellen Sie eine Liste aller Ausgaben, die sich nach Anmeldung, Rolle oder Sitzung verändern. Dazu gehören auch kleine Teile: ein Bearbeitungslink, ein zuletzt angesehenes Produkt oder ein Kommentarformular. Notieren Sie für jeden Teil, ob er für alle Besucher identisch, für eine begrenzte Gruppe gleich oder wirklich individuell ist. Die Sichtbarkeit allein genügt nicht. Ein persönlicher Wert kann in einem HTML-Attribut oder einem Skript stehen, ohne sofort aufzufallen.
Eine sinnvolle Grenze umfasst alle miteinander verbundenen persönlichen Angaben. Werden etwa Name und Zähler zusammen aktualisiert, sollten sie nicht versehentlich nach verschiedenen Regeln veralten. Umgekehrt muss ein allgemeiner Veranstaltungshinweis nicht für jede Sitzung separat gespeichert werden. Die Aufteilung folgt dem fachlichen Zustand. Erst wenn dieser klar beschrieben ist, wird entschieden, welche Cacheart und welche Laufzeit für ein Fragment vertretbar sind.
Ermitteln Sie die Servervariante und den Besucherpfad. Das WordPress-Plugin kann installiert sein, ohne dass der antwortende Server ESI ausführt. Auch ein vorgeschaltetes System gehört zur Betrachtung. Fragen Sie bei einem verwalteten Hosting nach der Funktion für Ihre konkrete Domain und nicht nur nach einem Produktnamen. Der Artikel Enterprise und OpenLiteSpeed beschreibt weitere Unterschiede, die für den Betrieb relevant sind.
LiteSpeed dokumentiert eine Freigabe auf Serverebene und eine Aktivierung im Plugin. Auf gemeinsam genutztem Hosting ist die Serverkonfiguration Aufgabe des zuständigen Betreibers. Kopieren Sie keine globale Serverdirektive in ein Feld, dessen Geltungsbereich Sie nicht kennen. Ein nachvollziehbarer Befund lautet beispielsweise: Die Domain besitzt einen bestätigten ESI-fähigen Auslieferungspfad, der Pluginbereich ist aktiviert und ein konkretes Fragment wurde anschließend geprüft.
Die Herstelleranleitung nennt außerdem Einschränkungen für ESI-Widgets im neueren WordPress-Widgetsystem. Prüfen Sie deshalb, welches Widgetsystem Ihre Installation tatsächlich verwendet und welche Integration aktuell unterstützt wird. Eine sichtbare Option im klassischen Widgeteditor ist nicht automatisch auf einen Block übertragbar. Wählen Sie einen vom Hersteller vorgesehenen Weg oder eine gezielt entwickelte Integration; eine eigene HTML-Markierung erzeugt von sich aus noch keine ESI-Verarbeitung.
Ein öffentliches Fragment besitzt für den definierten Besucherzustand denselben Inhalt. Es kann unabhängig vom Rest der Seite eine eigene Laufzeit und eine eigene Invalidierung benötigen. Ein Beispiel wäre eine allgemeine Liste neuer Beiträge. Prüfen Sie bei diesem Modell, welche Veröffentlichung die Liste aktualisieren soll und ob der gesamte Artikel dafür tatsächlich neu gespeichert werden muss. Die Trennung kann den Umfang einer Aktualisierung reduzieren.
Ein privates Fragment enthält sitzungs- oder nutzerbezogene Informationen. Seine Zuordnung muss auch dann stimmen, wenn dieselbe öffentliche Seite von mehreren Personen nacheinander aufgerufen wird. Eine private Cachekopie ist keine zusätzliche Berechtigungsprüfung. Die Anwendung muss weiterhin entscheiden, welche Informationen ein Konto sehen darf. Halten Sie deshalb fachliche Zugriffskontrolle und Wiederverwendung einer bereits korrekt erzeugten Ausgabe als zwei verschiedene Aufgaben fest.
Ein dynamisches, nicht gespeichertes Fragment kann passend sein, wenn jede Anforderung einen aktuellen Zustand benötigt. Auch dieses Fragment verursacht Arbeit. ESI macht individuelle Verarbeitung nicht kostenlos; es begrenzt sie auf bestimmte Teile. Vergleichen Sie den Aufwand mit einer einfachen komplett dynamischen Seite. Bei sehr vielen privaten Bestandteilen kann die ganze Antwort ohnehin von persönlicher Verarbeitung abhängen, sodass eine Fragmentierung wenig Nutzen bringt.
| Bestandteil | Mögliche Behandlung | Abnahmefrage |
|---|---|---|
| Allgemeiner Artikelrahmen | Öffentlicher Cache | Enthält er wirklich keine individuellen Werte? |
| Allgemeine Liste neuer Beiträge | Öffentliches Fragment mit eigener Aktualisierung | Erscheint eine neue Veröffentlichung rechtzeitig? |
| Persönliche Begrüßung | Privates Fragment | Ist sie ausschließlich der richtigen Sitzung zugeordnet? |
| Zustandsabhängiger Formularteil | Geeignete Integration oder dynamische Ausgabe | Funktionieren frische und länger geöffnete Formulare? |
| Fast vollständig persönliches Dashboard | Dynamische oder passende private Gesamtantwort prüfen | Ist die zusätzliche Fragmentierung überhaupt hilfreich? |
Starten Sie auf einer geschützten Testumgebung mit genau einem belegten Fragment. Sichern Sie die aktuellen Einstellungen und halten Sie fest, welche Seite und welcher Bestandteil untersucht werden. Aktivieren Sie die erforderliche Pluginfunktion nach Herstelleranleitung. Prüfen Sie dann, ob die gewählte Integration das Fragment tatsächlich erzeugt. Ein Diagramm der geplanten Aufteilung erleichtert den Vergleich zwischen Wunsch und ausgelieferter Antwort.
Führen Sie gleichzeitig keine weiteren Cachevarianten oder Optimierungsschalter ein. Sonst lässt sich eine Abweichung später nicht zuverlässig zuordnen. Vergleichen Sie die Seite vor und nach der einzelnen Änderung. Funktion, sichtbarer Inhalt und private Zuordnung sind die ersten Kriterien. Erst nach dieser Prüfung betrachten Sie Zeiten und Serverarbeit. Der Messleitfaden hilft, die späteren Zahlen unter vergleichbaren Bedingungen zu erheben.
Kontrollieren Sie das Gesamtdokument und die Fragmentausgabe. Ein Cache-HIT am Artikelrahmen beweist nicht, dass das persönliche Fragment richtig geladen wurde. Ein leeres Fragment kann eine schnelle Seite ergeben und trotzdem eine fehlende Funktion darstellen. Definieren Sie deshalb vorab eine erkennbare erwartete Ausgabe. Bei einem allgemeinen Widget genügt ein Testbeitrag; bei einer persönlichen Anzeige verwenden Sie eindeutig benannte, künstliche Testkonten.
Verwenden Sie getrennte Browserprofile für A und B. Beide besuchen dieselbe Seite, besitzen aber verschiedene erlaubte Testdaten. Laden Sie die Seite mehrfach und ändern Sie anschließend nur A. B muss seine eigene Ansicht behalten. Wiederholen Sie den Ablauf mit vertauschter Reihenfolge und nach einem Purge. Damit prüfen Sie auch, ob eine zuerst erzeugte Antwort ungewollt als Vorlage für alle folgenden Sitzungen verwendet wird.
Testen Sie einen dritten Zustand ohne Anmeldung. Dort darf kein persönlicher Name und kein für ein Konto bestimmter Bearbeitungslink erscheinen. Betrachten Sie auch den Seitenquelltext beziehungsweise die beobachtete Antwort, soweit dies für die Integration sinnvoll ist. Eine Information, die lediglich durch CSS verborgen wird, ist nicht dadurch privat. Dokumentieren Sie die tatsächlich ausgelieferten Werte und bereinigen Sie persönliche oder sitzungsbezogene Daten vor einer Weitergabe.
Prüfen Sie Anmeldung und Abmeldung innerhalb eines normalen Besuchsablaufs. Ein neuer Request nach der Abmeldung muss zum anonymen Zustand passen. Werden Fragmente zusätzlich im Browser aktualisiert, testen Sie sowohl die Aktualisierung als auch ein vollständiges erneutes Laden. So lässt sich unterscheiden, ob ein Fehler im zusammengesetzten Serverdokument oder in der späteren JavaScript-Verarbeitung liegt. Die Korrektur sollte die betroffene Ebene benennen.
WordPress verwendet Nonces als zeitlich begrenzte Prüfwerte für bestimmte Aktionen. Nach der offiziellen WordPress-Referenz ersetzen sie weder Anmeldung noch Berechtigungsprüfung. Ein Formular kann deshalb zwei unabhängige Anforderungen besitzen: Der Nutzer muss die Aktion ausführen dürfen und der mitgesendete Prüfwert muss gültig sein. Ein lange gespeichertes Dokument kann einen Prüfwert enthalten, der zum späteren Absendezeitpunkt nicht mehr akzeptiert wird.
LiteSpeed bietet einen ESI-Bereich für Nonces und eine Liste bekannter Integrationen. Verwenden Sie ihn gezielt für den tatsächlich identifizierten Aktionswert. Eine erfundene Wildcard für sämtliche Formulare ist kein sinnvoller Ersatz für eine Untersuchung. Testen Sie ein frisch geladenes Formular, einen länger offenen Zustand und die Reaktion nach einer erneuten Anmeldung. Die erwartete Fehlermeldung soll verständlich sein und keine fehlerhafte Aktion stillschweigend ausführen.
Verlängern Sie eine Sicherheitslaufzeit nicht allein, um einen Cachefehler unsichtbar zu machen. Klären Sie stattdessen, welche Ausgabe erneuert werden muss und wie die Integration den gültigen Wert bereitstellt. Die TTL des allgemeinen Artikels und die Gültigkeit des Formularzustands müssen nicht gleich sein. Ihre gemeinsame Abnahme gehört jedoch in einen dokumentierten Ablauf. Der Artikel TTL und Purge erklärt die Unterschiede zwischen Ablauf und gezielter Invalidierung.
Eine Cachevariante speichert eine andere Gesamtansicht für einen definierten Zustand. Ein Fragment behandelt einen Teil der Antwort getrennt. Beide Konzepte können zusammen auftreten, erfüllen aber unterschiedliche Aufgaben. Eine Variante je Rolle darf nur dann gemeinsam verwendet werden, wenn die darin enthaltenen Informationen für diese Rolle tatsächlich identisch sind. Zwei Kunden derselben Rolle besitzen nicht automatisch denselben Warenkorb oder dieselbe Bestellübersicht.
Begrenzen Sie die Zahl der Varianten auf fachlich benötigte Zustände. Sprache, Gerätausgabe und Preisgruppe können sich kombinieren und dadurch den Umfang des Caches erhöhen. Prüfen Sie, ob das Theme wirklich verschiedene mobile HTML-Ausgaben erzeugt oder nur ein responsives Layout besitzt. Überflüssige Trennungen erzeugen zusätzliche Kopien, die neu befüllt und aktualisiert werden müssen. Die Cookie-Anleitung führt diese Zustandsanalyse weiter.
Eine konkrete Gegenprobe untersucht eine Veröffentlichung im allgemeinen Fragment. Laden Sie den Artikelrahmen und die Liste neuer Beiträge zunächst wiederholt. Veröffentlichen Sie auf Staging einen eindeutig benannten Testbeitrag und prüfen Sie anschließend dieselbe Seite. Die Liste soll den Beitrag nach dem vorgesehenen Aktualisierungspfad zeigen; der persönliche Bereich muss weiterhin zur jeweiligen Sitzung gehören. Dieser Fall prüft die Invalidierung eines öffentlichen Fragments, ohne seine Aufgabe mit der Aktualisierung eines privaten Fragments zu vermischen.
Bleibt die Liste alt, vergleichen Sie einen neuen Request mit einer bereits offenen Browseransicht. Prüfen Sie danach, ob das Fragment überhaupt getrennt verarbeitet wird oder ob das Theme die Liste zusätzlich im allgemeinen Rahmen ausgibt. Zwei ähnliche sichtbare Listen können aus unterschiedlichen Stellen stammen. Notieren Sie das betroffene Element und dessen Datenquelle. Ein globaler Purge kann beide Fassungen erneuern und dadurch eine fehlende gezielte Anbindung verdecken. Wiederholen Sie deshalb nach der Korrektur denselben kleinen Veröffentlichungsfall.
Erstellen Sie für die Integration eine kurze Zuordnung zwischen Funktion und Fragment: allgemeine Liste, persönliche Anzeige, zuständiges Plugin und Aktualisierungsereignis. Diese Zuordnung ist für eine spätere Wartung oft hilfreicher als eine lange Sammlung sämtlicher Header. Sie zeigt, welche Änderung welchen Bestandteil erreichen muss. Ein neuer Widgettyp oder ein umgebauter Kopfbereich wird dann gezielt gegen die vorhandene Fragmentgrenze geprüft.
Messen Sie erst nach erfolgreicher Funktionsprüfung einen repräsentativen Ablauf mit und ohne die getestete Fragmentierung. Nutzen Sie gleiche URLs, gleiche Zustände und vergleichbare Wiederholungen. Beobachten Sie Serverarbeit und Antwortzeiten, soweit Ihre Plattform entsprechende Daten liefert. Eine allgemeine Aussage über eine mögliche ESI-Wirkung ist keine garantierte Verbesserung auf Ihrer Website. Ein kleiner Blog und ein stark personalisiertes Portal können unterschiedliche Ergebnisse liefern.
Halten Sie den Rückweg bereit: welche Einstellung wird zurückgenommen, welche Cachekopien müssen invalidiert werden und welche Funktion wird danach erneut geprüft? Ein Rückbau muss auch die bisher öffentlichen Antworten berücksichtigen. Die Dokumentation sollte nennen, warum ESI eingeführt wurde und welche Fragmente dazugehören. Damit können spätere Theme- oder Pluginupdates anhand derselben Erwartung geprüft werden, statt die ursprüngliche Aufteilung erneut erraten zu müssen.
7. Oktober 2026. Die Fragmentbeispiele illustrieren eine Prüfmethode und keine ausgeführte Installation.