TTL und Purge an Inhalte anpassen: Änderungsabhängigkeiten, mehrere Cacheebenen, Wiederaufbau und eine überprüfbare Veröffentlichungsprobe.
Eine Cachekopie braucht eine sinnvolle Lebensdauer und einen verlässlichen Umgang mit Änderungen. TTL und Purge lösen verschiedene Aufgaben. Wer beide an den Inhalt bindet, erhält aktuelle Seiten, ohne nach jeder kleinen Korrektur den gesamten Cachebestand unnötig neu aufbauen zu müssen.
TTL steht für Time to Live. Im Cachekontext bezeichnet sie eine Zeitspanne, innerhalb der eine gespeicherte Antwort unter den geltenden Regeln nutzbar bleibt. Eine lange TTL kann wiederholte öffentliche Anfragen entlasten. Sie bedeutet jedoch nicht, dass ein Inhalt in dieser Zeit garantiert unverändert bleibt. Eine wichtige Korrektur kann wenige Minuten nach dem Speichern erfolgen. Deshalb muss die Architektur Änderungen unabhängig von der geplanten Lebensdauer behandeln können.
Eine kurze TTL ist ebenfalls kein universeller Schutz gegen veraltete Angaben. Zwischen einer Änderung und dem Ablauf kann weiterhin eine frühere Fassung erscheinen. Wenn eine wichtige Information unmittelbar korrekt sein muss, ist eine gezielte Invalidierung oder ein bewusst dynamischer Pfad erforderlich. Die Einstellung einer kleinen Zahl verdeckt diese fachliche Anforderung. Sie kann zudem häufige Neuberechnungen auslösen, ohne das grundlegende Änderungsproblem zu lösen.
Beginnen Sie mit Inhaltsklassen. Ein stabiler Hintergrundartikel, eine Veranstaltungsliste und ein persönlicher Warenkorb haben unterschiedliche Anforderungen. Die LiteSpeed-Dokumentation zur TTL erläutert die verfügbaren Einstellungen. Welche Werte sinnvoll sind, muss aus Ihrem Bestand abgeleitet und anschließend geprüft werden. Fremde „beste Einstellungen“ kennen weder Ihren Veröffentlichungsrhythmus noch die Bedeutung Ihrer dynamischen Elemente.
Ein Purge macht betroffene Kopien ungültig, bevor ihre bisherige Lebensdauer abgelaufen ist. Das ist die passende Idee für Ereignisse wie eine Textkorrektur oder die Veröffentlichung eines neuen Beitrags. Wichtig ist der Umfang. Nur die Einzelansicht zu behandeln kann unzureichend sein, wenn der Beitrag ebenfalls auf der Startseite oder in einer Kategorieübersicht erscheint. Alles zu leeren kann dagegen unnötig viel Wiederaufbau verursachen.
Die offizielle Purge-Dokumentation beschreibt die Anbindung an WordPress-Abläufe. Für eine redaktionelle Planung wird daraus eine eigene Abhängigkeitsliste. Welche Übersichten enthalten den Beitrag? Welche globalen Elemente ändern sich? Welche Daten kommen aus einer zusätzlichen Erweiterung? Ein Cache kann nur die Beziehungen berücksichtigen, die ihm bekannt sind oder die über passende Regeln gemeldet werden.
Ein manuelles Leeren ist sinnvoll für eine gezielte Prüfung oder eine bekannte Sonderänderung. Es sollte nicht zum einzigen Weg werden, mit dem die Redaktion aktuelle Inhalte sichtbar macht. Wenn nach jedem Speichern ein Administrator eingreifen muss, fehlt möglicherweise eine Integration. Die Lösung liegt dann in der Änderungsmeldung oder einer passenden Inhaltsarchitektur, nicht in einer immer längeren Liste manueller Nacharbeiten.
| Änderung | Mögliche betroffene Ansichten | Abnahme |
|---|---|---|
| Textkorrektur im Beitrag | Einzelansicht, gegebenenfalls Auszüge | Geänderten Satz anonym suchen |
| Neue Kategoriezuordnung | Beitrag, alte und neue Übersicht | Einordnung auf beiden Übersichten prüfen |
| Globales Menü | Viele öffentliche Seiten | Mehrere Seitentypen kontrollieren |
| Externer Datenimport | Vom Import abhängige Bereiche | Importereignis und sichtbare Fassung verbinden |
| Shopbestand | Produkt und relevante Listen | Bestandsdarstellung und Kaufablauf prüfen |
Die einfachste Bestandsaufnahme beginnt bei einem typischen Beitrag. Zeichnen Sie alle Stellen auf, an denen Titel, Auszug, Bild oder Kategorie erscheinen. Ein Archiv kann einen automatisch erzeugten Auszug verwenden, während eine individuell gestaltete Startseite eine separat gespeicherte Kurzbeschreibung nutzt. Beide Bereiche können nach einer Textänderung unterschiedliche fachliche Erwartungen haben. Das ist eine Inhaltsfrage, bevor es eine Cachefrage ist.
Ein globales Element verdient besondere Aufmerksamkeit. Ein „neueste Beiträge“-Bereich verändert sich bei jeder Veröffentlichung und kann auf sehr vielen Seiten stehen. Die Website muss entscheiden, ob diese Abhängigkeit die ganze Seite invalidiert oder ob ein unterstützter eigener Pfad sinnvoll ist. Eine Fragmentlösung ist eine mögliche Architekturentscheidung, verlangt aber zusätzliche Voraussetzungen und Tests. Unser ESI-Ratgeber behandelt diese Abwägung getrennt.
Notieren Sie außerdem den Weg der Änderung. Ein normaler WordPress-Speichervorgang kann andere Ereignisse auslösen als ein eigener Datenimport. Ein Plugin kann Werte direkt aktualisieren, ohne die erwartete Cachemeldung zu erzeugen. Für solche Fälle braucht der Entwickler einen dokumentierten Integrationspunkt. Die LiteSpeed-API-Dokumentation beschreibt verfügbare Hooks und Steuerungen. Ihre Anwendung muss zum tatsächlichen Änderungsweg passen.
Wählen Sie eine geeignete Testseite und erzeugen Sie eine bekannte Ausgangsfassung. Prüfen Sie anonym, ob eine nutzbare Cachekopie entsteht. Ändern Sie dann einen eindeutig erkennbaren Text. Anschließend öffnen Sie die reguläre Besucheradresse erneut und kontrollieren den Inhalt. Prüfen Sie danach eine betroffene Übersicht. So wird direkt untersucht, ob die erwartete Änderungsmeldung ihre fachlichen Abhängigkeiten erreicht.
Der Test braucht eine feste Dokumentation: geänderter Inhalt, Zeitpunkt, URL und beobachtete Antwort. Ein HIT nach der Änderung kann korrekt sein, wenn bereits die neue Fassung gespeichert wurde. Ein MISS allein beweist dagegen nicht, dass die richtige Fassung vorliegt. Vielleicht erzeugt die Anwendung selbst noch alte Daten. Deshalb wird der konkrete geänderte Satz gelesen, statt nur der Headerzustand bewertet.
Falls eine Übersicht alt bleibt, klären Sie zuerst deren Datenquelle. Hat sie einen eigenen manuell gepflegten Auszug? Gibt es eine zusätzliche Cacheebene? Wurde der erwartete Zusammenhang tatsächlich invalidiert? Diese drei Fragen führen zu unterschiedlichen Lösungen. Ein pauschaler Gesamtpurge kann zwar kurzfristig die Ansicht ändern, erklärt aber noch nicht, warum die reguläre Veröffentlichung unvollständig war.
Ein CDN kann eine eigene Kopie halten, während der Origin bereits aktuell ist. Umgekehrt kann ein geleertes CDN die frühere Fassung erneut vom Origin beziehen. Die Änderungsplanung muss deshalb alle tatsächlich vorhandenen Ebenen kennen. In der Architekturmatrix erhält jede Ebene ihre Daten, ihre Gültigkeitsregeln und einen verantwortlichen Prüfpunkt. Ein zusätzlicher Dienst ohne diese Zuordnung vergrößert die Unklarheit.
Statische Dateien brauchen ebenfalls eine Strategie. Eine geänderte CSS-Datei unter demselben Namen kann beim Besucher noch aus dem Browsercache kommen. Eine passende Dateiversion oder ein neuer Dateiname ermöglicht eine eindeutige neue Ressource. Der Seitenpurge und die Assetversionierung lösen hier verschiedene Aufgaben. Beide können für eine sichtbare Themeänderung notwendig sein, aber sie sollten nicht als dieselbe Funktion behandelt werden.
Die praktische Abnahme betrachtet daher Inhalt und Gestaltung getrennt. Ist der neue Satz angekommen? Wird die neue CSS-Fassung geladen? Stammt ein Bild aus einer alten oder neuen Ableitung? Diese Fragen verhindern, dass eine teilweise erfolgreiche Änderung als vollständig verifiziert gilt. Die erwartete Fassung wird pro Ressourcentyp nachvollzogen.
Nach einem Purge müssen fehlende Antworten erneut erzeugt werden. Das geschieht durch Besucher oder durch einen bewusst eingerichteten Crawler. Ein großer Gesamtpurge kann deshalb viele dynamische Anfragen in kurzer Zeit auslösen. Ob das relevant ist, hängt von Umfang, Zugriffsmuster und Ressourcen ab. Es wird nicht aus der bloßen Zahl veröffentlichter Seiten abgeleitet.
Ein Crawler ist kein kostenloser Ersatz für jede Betriebsentscheidung. Er führt Anfragen aus und beansprucht dabei Ressourcen. Die LiteSpeed-Crawler-Dokumentation beschreibt Steuerungen und Grenzen. Vor der Aktivierung muss der Hostinganbieter die Nutzung erlauben, und der konkrete Bestand muss die nötigen Funktionen bieten. Auf einer geschützten Vorschau kann der Zugriff absichtlich nicht möglich sein.
Für ein Portal mit regelmäßigen Veröffentlichungen kann ein gezielter Wiederaufbau wichtiger Ansichten ausreichen. Für einen Shop müssen dynamische Pfade und aktuelle Zustände weiterhin korrekt bleiben. Eine Lastbeobachtung vor und nach dem Purge zeigt, ob die gewählte Strategie tragfähig ist. Erfundenen Warmup-Zeitangaben oder pauschalen Besuchergrenzen fehlt dagegen die Grundlage.
Ein Countdown, eine ablaufende Anmeldung oder eine tagesabhängige Empfehlung kann sich verändern, ohne dass jemand einen Beitrag speichert. Solche Inhalte passen nicht automatisch in denselben Änderungsweg wie redaktioneller Text. Es muss geklärt werden, ob die Anwendung ein Ereignis auslöst, ob ein geeignetes dynamisches Fragment vorliegt oder ob die Seite bewusst kurzlebig beziehungsweise ungecacht bleibt.
Formularmerkmale und Sicherheitsmechanismen werden am tatsächlichen Ablauf geprüft. Eine ältere Seite kann eine Information enthalten, die für den nächsten Schritt nicht mehr gültig ist. Der Test unmittelbar nach dem Leeren erkennt das nicht zuverlässig. Planen Sie daher einen späteren Aufruf aus einer vorhandenen Kopie und kontrollieren Sie die Aktion. Die fachlich erlaubte Zeitspanne bestimmt den Testzeitpunkt.
Bei geschäftskritischen Angaben zählt die korrekte Entscheidung des Besuchers. Ein alter Veranstaltungstermin oder eine nicht mehr gültige Angebotsbedingung kann auch dann problematisch sein, wenn der Cache technisch wie konfiguriert arbeitet. Die Redaktion muss solche Informationen benennen. Technik und Inhalt brauchen hier eine gemeinsame Abnahme, weil keine Cacheoption ihre fachliche Bedeutung erraten kann.
Dieses Protokoll lässt sich auf wenige Zeilen reduzieren und im Redaktionsteam wiederverwenden. Es zwingt niemanden, für eine Textkorrektur Serverlogs zu lesen. Die Redaktion kontrolliert den Inhalt, die Technik untersucht bei Bedarf den Cacheweg. Beide arbeiten am selben erwarteten Ergebnis. Dadurch wird ein Fehler früh sichtbar, ohne jede Veröffentlichung unnötig kompliziert zu machen.
Wenn die Regeln stabil funktionieren, kann die TTL danach begründet angepasst werden. Eine höhere Lebensdauer wird nicht als allgemeiner Geschwindigkeitsgewinn versprochen. Sie wird daran bewertet, ob passende öffentliche Kopien länger nutzbar bleiben und Änderungen weiterhin zuverlässig ankommen. Der Messleitfaden zeigt, wie sich eine solche Anpassung unter vergleichbaren Bedingungen untersuchen lässt.
Für eine Fehlkorrektur bleibt der ursprüngliche Befund erhalten. Ein später erfolgreicher Purge erhält einen neuen Eintrag mit der nun sichtbaren Fassung. So lässt sich bei einer wiederkehrenden Störung unterscheiden, ob die reguläre Integration repariert wurde oder ob lediglich ein manueller Eingriff das aktuelle Symptom beseitigt hat.
7. Oktober 2026. Eigene Änderungsmethodik; keine pauschalen TTL-Werte und keine behaupteten Messresultate.