TYPO3-Performance: Caching und Ladezeit im Griff behalten

TYPO3 speichert das gerenderte Ergebnis einer Seite und liefert es beim nächsten Aufruf aus dem Cache. Wie lange ein solcher Eintrag gilt, steuert config.cache_period; die Voreinstellung liegt bei 86.400 Sekunden, also 24 Stunden (TYPO3-TypoScript-Referenz, config). Ein Wert im Seitenfeld cache_timeout sticht die globale Einstellung, sobald er über null liegt. Kurze Lebensdauern sind dabei kein Widerspruch zum Caching: Die Core-API-Dokumentation hält ausdrücklich fest, dass selbst 30 Sekunden in manchen Szenarien schon etwas bringen. Für eine Übersichtsseite, die sich stündlich ändert, ist eine Minute Cache besser als gar keiner.

Der schnellste Weg, diesen Cache zu verlieren, ist config.no_cache = 1. Die Voreinstellung steht auf 0, und das aus gutem Grund: Mit 1 wird das Ergebnis gar nicht mehr im Seiten-Cache abgelegt (TYPO3-TypoScript-Referenz, config). Jede Anfrage durchläuft dann den vollen Aufbau aus TypoScript, Extbase, Fluid und Datenbankabfragen. In der Praxis landet die Einstellung oft in einer Bedingung, die einmal für eine einzelne Seite gedacht war und später global griff. Wer wissen will, was das kostet, misst die Zeit bis zum ersten Byte einmal mit und einmal ohne aktiven Cache-Treffer.

Die Dokumentation nennt den Ausweg direkt neben der Einstellung: Statt den Cache global abzuschalten, wird der dynamische Teil von USER auf USER_INT umgestellt, beziehungsweise COA auf COA_INT. TYPO3 holt dann den gecachten Teil der Seite aus dem Speicher und rendert anschließend nur die dynamischen Bereiche. Ein Suchformular, eine Anzeige des angemeldeten Namens oder ein Warenkorb-Kopf kostet damit einen Bruchteil dessen, was eine vollständig ungecachte Seite kostet. Der Preis dafür ist die Sorgfalt: Jeder dynamische Baustein läuft bei jedem Aufruf, auch bei dem des Suchmaschinen-Crawlers.

Welche Zeile für den eigenen Aufruf gilt, lässt sich nicht raten. TYPO3 schickt die Cache-Kopfzeilen nur, wenn vier Bedingungen gleichzeitig erfüllt sind: die Seite war gecacht, es liegen keine *_INT- oder *_EXT-Objekte auf der Seite, es ist kein Frontend-Benutzer angemeldet und es ist kein Backend-Benutzer angemeldet (TYPO3-TypoScript-Referenz, config.sendCacheHeaders). Andernfalls geht die Antwort mit Cache-Control: private, no-store heraus. Ein Redakteur, der die Seite im angemeldeten Zustand prüft, bekommt deshalb einen anderen Fall zu sehen als der Besucher. Wer genauer wissen will, wo die Zeit im Backend bleibt, hängt Server-Timing an die Antwort und trennt Datenbank, Rendering und Fremdaufrufe voneinander.

Unter dem Seiten-Cache liegt das Caching-Framework mit mehreren Cache-Gruppen und je Gruppe einem Backend. Ohne eigene Konfiguration schreibt TYPO3 in die Datenbank: Das Datenbank-Backend ist laut Dokumentation die Voreinstellung, wenn kein Backend gesetzt wurde. Ein Eintrag ohne eigene Lebensdauer gilt dabei 3.600 Sekunden (TYPO3-Dokumentation, Caching-Backends). Diese Zahl betrifft nicht den Seiten-Cache, sondern die Vorgabe der Backends selbst; sie erklärt, warum ein selbst gesetzter Anwendungs-Cache nach einer Stunde wieder kalt ist, obwohl niemand ihn geleert hat. Wie sich die Schichten darüber verhalten, ist im Beitrag zu Varnish, Redis und Browser-Cache beschrieben.

Das Datenbank-Backend räumt nicht von selbst auf; die Dokumentation verweist dafür ausdrücklich auf die Scheduler-Aufgabe zur Garbage Collection. Fehlt diese Aufgabe, wachsen die Cache-Tabellen samt ihrer Tag-Tabellen weiter, und der Zugriff auf den Cache wird selbst zur Last. Für große Cache-Tabellen nennt die Dokumentation das Redis-Backend als Alternative, die den Datenbankserver entlastet. Der Wechsel ist eine Frage von wenigen Zeilen in der Systemkonfiguration; die Entscheidung, welche Gruppe umzieht, ist die eigentliche Arbeit. In welcher Reihenfolge die Schichten greifen, fasst unsere Seite zu Caching-Strategien zusammen.

Ein voller Cache verkürzt die Serverzeit, nicht die Ladezeit im Browser. Sobald die Antwort in wenigen Millisekunden kommt, entscheiden Bilder, Schriften und Skripte darüber, wann die Seite nutzbar ist. Für Bilder aus der TYPO3-Dateiverwaltung heißt das: passende Größen statt eines Originals mit mehreren tausend Pixeln Breite, moderne Formate und feste Maße im Markup, damit beim Nachladen nichts springt. Die vollständige Kette vom Original bis zur ausgelieferten Datei geht der Beitrag zu WebP und AVIF durch.

Die zweite Gruppe von Bremsen sitzt hinter der Seite: Formularstrecken, Verfügbarkeitsabfragen, Preisberechnungen, Anbindungen an ein Warenwirtschaftssystem. Sie laufen häufig in einem dynamischen Baustein und damit bei jedem Aufruf, und sie bringen eine Laufzeit mit, die niemand im eigenen Haus kontrolliert. Wie sich Zeitüberschreitungen dort auf den Seitenaufbau auswirken und welche Absicherungen sich bewährt haben, steht im Beitrag zu Fremdsystemen im Seitenaufbau.

Hinter einer Anmeldung verschwindet der Seiten-Cache ohnehin weitgehend. Dort zählt, was der Server je Aufruf leistet, und dort fällt jede unnötige Abfrage doppelt ins Gewicht, weil sie sich nicht mehr auf viele Besucher verteilt. Wie sich dieser Bereich messen lässt, ohne die Messung durch die Anmeldung selbst zu verfälschen, beschreibt der Beitrag zum Tempo hinter dem Login.