Cache Warmup für TYPO3

Warum die ersten 5 Minuten nach einem TYPO3-Deployment über die User Experience entscheiden

Nach jedem Deployment wird der TYPO3-Cache geleert. Das ist technisch notwendig, hat aber eine spürbare Konsequenz: Die ersten Besucher nach dem Deployment sehen ungecachte Seiten. Statt 200ms Ladezeit warten sie 2 bis 5 Sekunden, bei komplexen Seiten auch länger. Bei einem Deployment um 9:00 Uhr morgens trifft das genau die Besucher mit der höchsten Conversion-Wahrscheinlichkeit.

warmup löst dieses Problem, indem es den Cache proaktiv füllt, bevor der erste echte Besucher die Seite aufruft. Die Extension ruft alle Seiten der Website aus dem Seitenbaum auf, in allen Sprachen und für geschützte Seiten je Benutzergruppe. Nach 2 bis 10 Minuten (abhängig von der Seitenzahl) ist der gesamte Cache gefüllt, und jeder Besucher bekommt die volle Performance.

Typische Einsatzszenarien

Automatisiertes Cache-Warming nach CI/CD-Deployments. Ein Unternehmen deployt seine TYPO3-Website 2 bis 3 Mal pro Woche über eine CI/CD-Pipeline (GitLab CI, GitHub Actions, Deployer). Nach jedem Deployment leert Deployer den Cache. warmup wird als letzter Schritt in der Pipeline aufgerufen und füllt den Cache, bevor das Deployment als “erfolgreich” gilt. Die Pipeline wartet, bis warmup fertig ist, und gibt erst dann den Traffic auf die neue Version frei.

Cache-Rebuild nach manuellen Änderungen. Redakteure leeren manchmal den gesamten Cache über das TYPO3-Backend, weil eine einzelne Seite nicht aktuell angezeigt wird. Das betrifft dann alle Seiten. Ein Scheduler-Task kann warmup danach regelmäßig starten und den Cache wieder füllen; einen eigenen Hook auf das Cache-Clear-Event bringt warmup nicht mit. Der Redakteur merkt davon nichts, und nach dem nächsten Lauf ist der Cache wieder voll.

Geplantes Warming für High-Traffic-Zeitfenster. Ein Online-Shop auf TYPO3-Basis hat seine Spitzenzeiten zwischen 10:00 und 12:00 Uhr. Ein Scheduler-Task startet warmup täglich um 9:30 Uhr, damit der Cache pünktlich zum Traffic-Peak vollständig gefüllt ist. Das ist besonders relevant, wenn der TYPO3-Cache eine begrenzte TTL (Time-to-Live) hat und über Nacht teilweise abläuft.

Technische Architektur

warmup arbeitet als TYPO3-CLI-Command und als Scheduler-Task. Der Warmup-Prozess läuft in drei Phasen:

• URL-Sammlung: warmup liest alle Seiten aus der Tabelle pages und erzeugt ihre URLs über das Routing der Site-Konfiguration. Links, Shortcuts, Sysfolder und Mountpoints lässt es aus, eine Sitemap braucht es nicht. Die Liste umfasst jede Seite in allen Sprachen der Site.
• Rootline-Cache: Im Standardlauf baut warmup zuerst den Rootline-Cache aller Seiten auf. Ohne ihn berechnet TYPO3 beim ersten Aufruf die Rootline jeder verlinkten Seite neu, was auf großen Seiten mehrere Sekunden dauern kann. Nach Traffic priorisiert warmup nicht.
• Rendering: warmup rendert jede Seite in einem simulierten Frontend-Request im selben PHP-Prozess, ohne HTTP-Aufruf. Der TYPO3-Caching-Framework speichert das Rendering-Ergebnis. warmup arbeitet die Seiten nacheinander ab, sodass immer nur eine Seite zur Zeit gerendert wird.

Der CLI-Command lautet vendor/bin/typo3 cache:warmupPages, mit dem Argument rootline oder pages wärmt er nur einen Teil. Für die CI/CD-Integration wird er typischerweise als Post-Deploy-Hook aufgerufen.

Abhängigkeiten: TYPO3 Core, Caching Framework. warmup arbeitet mit jedem Cache-Backend zusammen - Dateisystem, Redis, Memcached, APCu. In Kombination mit staticfilecache erzeugt warmup vorab statische HTML-Dateien, die vom Webserver direkt ausgeliefert werden. Die Extension bietet zudem eine Ausgabe jeder aufgerufenen Seite mit URL und Seiten-ID in der Konsole. Das ist nützlich, um nach dem ersten produktiven Lauf zu prüfen, welche Seiten gewärmt wurden.

Häufige Probleme und Lösungen

Problem: warmup-Prozess dauert über 30 Minuten. Bei Websites mit mehr als 5.000 Seiten und Multi-Language-Setup (z.B. 1.000 Seiten x 5 Sprachen = 5.000 URLs) kann der Warmup-Prozess lang dauern. Die Lösung: den Lauf mit cache:warmupPages rootline auf den Rootline-Cache beschränken, der ohne Seiten-Rendering deutlich schneller fertig ist. Die restlichen Seiten werden beim ersten Besuch gecacht.

Problem: Server-Load steigt während des Warmups auf 100%. warmup rendert jede Seite im CLI-Prozess auf dem eigenen Server. Ohne Rate-Limiting kann das die Serverlast auf ein Niveau treiben, das echte Besucher ausbremst. Die Lösung: den Lauf per Scheduler-Task in verkehrsarme Zeiten legen. Auf dedizierten Servern mit ausreichend Ressourcen ist das kein Problem; auf Shared Hosting kann warmup den Server des Providers triggern.

Problem: Gecachte Seiten sind nach dem Warmup nicht aktuell. warmup cached die Seite so, wie sie zum Zeitpunkt des Aufrufs existiert. Wenn Redakteure während des Warmup-Prozesses Content ändern, stimmt der Cache nicht mit dem aktuellen Stand überein. Die Lösung: Warmup erst starten, nachdem alle Content-Änderungen abgeschlossen sind. In CI/CD-Pipelines ist das automatisch der Fall, bei manuellen Cache-Clears sollte der Warmup mit 30 Sekunden Verzögerung starten.

Migration und Versions-Kompatibilität

Die Extension warmup stammt von b13 (b13/warmup) und wird aktiv gepflegt: Version 3.0.0 vom 23.09.2026 unterstützt TYPO3 v12, v13 und v14. Sitemap-basiert arbeitet dagegen die Extension Warming von Elias Häußler (eliashaeussler/typo3-warming).

Wer bisher manuelle Warmup-Scripte nutzt (curl-Schleifen, wget-Crawler), kann diese durch warmup ersetzen. Der Vorteil: warmup kennt den TYPO3-Seitenbaum samt Sprachen und Benutzergruppen und lässt sich über den Scheduler starten. Ein manuelles Script crawlt blind, warmup kennt jede Seite.

Die Kombination warmup + staticfilecache + Redis ist der Performance-Stack, den Gosign für Enterprise-TYPO3-Installationen empfiehlt. warmup füllt den Cache, staticfilecache serviert statische HTML-Dateien ohne PHP, Redis speichert Datenbank-Queries. Zusammen erreichen TYPO3-Websites damit Ladezeiten unter 100ms. Für Websites mit weniger als 500 Seiten und moderatem Traffic reicht warmup allein ohne staticfilecache aus. Der einfache TYPO3-Page-Cache liefert bereits Ladezeiten unter 300ms, wenn er korrekt gefüllt ist. warmup stellt sicher, dass dieses Niveau von der ersten Sekunde nach dem Deployment an gehalten wird.