Cache Warmup for TYPO3

Why the first 5 minutes after a TYPO3 deployment determine the user experience

After every deployment, the TYPO3 cache is cleared. This is technically necessary but has a noticeable consequence: the first visitors after deployment see uncached pages. Instead of 200ms loading time, they wait 2 to 5 seconds - for complex pages, even longer. A deployment at 9:00 AM hits exactly the visitors with the highest conversion probability.

warmup solves this problem by proactively filling the cache before the first real visitor accesses the page. The extension calls all pages of the website from the page tree, in all languages and, for protected pages, per user group. After 2 to 10 minutes (depending on page count), the entire cache is filled and every visitor gets full performance.

Typical use cases

Automated cache warming after CI/CD deployments. A company deploys its TYPO3 website 2 to 3 times per week through a CI/CD pipeline (GitLab CI, GitHub Actions, Deployer). After each deployment, Deployer clears the cache. warmup is called as the last step in the pipeline and fills the cache before the deployment is marked as “successful”. The pipeline waits until warmup finishes and only then releases traffic to the new version.

Cache rebuild after manual changes. Editors sometimes clear the entire cache through the TYPO3 backend because a single page is not displaying current content. This affects all pages. A scheduler task can start warmup regularly and refill the cache; warmup does not ship its own hook on the cache clear event. The editor notices nothing, and after the next run the cache is full again.

Scheduled warming for high-traffic time windows. A TYPO3-based online shop has peak hours between 10:00 and 12:00 AM. A scheduler task starts warmup daily at 9:30 AM so the cache is fully filled by the time the traffic peak begins. This is especially relevant when the TYPO3 cache has a limited TTL (time-to-live) and partially expires overnight.

Technical architecture

warmup operates as a TYPO3 CLI command and as a scheduler task. The warmup process runs in three phases:

• URL collection: warmup reads all pages from the pages table and builds their URLs through the routing of the site configuration. It skips links, shortcuts, sysfolders and mount points and needs no sitemap. The list covers every page in all languages of the site.
• Rootline cache: in the default run, warmup first builds the rootline cache of all pages. Without it, TYPO3 recalculates the rootline of every linked page on the first call, which can take several seconds on large sites. warmup does not prioritize by traffic.
• Rendering: warmup renders each page in a simulated frontend request within the same PHP process, without an HTTP call. The TYPO3 caching framework stores the rendering result. warmup processes the pages one after another, so only one page is rendered at a time.

The CLI command is vendor/bin/typo3 cache:warmupPages; with the argument rootline or pages it warms up only one part. For CI/CD integration, it is typically called as a post-deploy hook.

Dependencies: TYPO3 Core, caching framework. warmup works with any cache backend - file system, Redis, Memcached, APCu. In combination with staticfilecache, warmup creates static HTML files in advance that the web server serves directly. The extension also prints every page it calls, with URL and page ID, to the console. This is useful for checking which pages were warmed after the first production run.

Common problems and solutions

warmup process takes over 30 minutes. For websites with more than 5,000 pages and multi-language setups (e.g. 1,000 pages x 5 languages = 5,000 URLs), the warmup process can be lengthy. Solution: limit the run to the rootline cache with cache:warmupPages rootline, which finishes much faster without page rendering. Remaining pages are cached on first visit.

Server load hits 100% during warmup. warmup renders every page in the CLI process on the server itself. Without rate limiting, this can drive server load to a level that slows down real visitors. Solution: schedule the run in low-traffic hours with a scheduler task. On dedicated servers with sufficient resources, this is not an issue; on shared hosting, warmup may trigger the provider’s server limits.

Cached pages are not current after warmup. warmup caches the page as it exists at the time of the call. If editors change content during the warmup process, the cache does not match the current state. Solution: only start warmup after all content changes are complete. In CI/CD pipelines, this is automatic; for manual cache clears, warmup should start with a 30-second delay.

Migration and version compatibility

The warmup extension comes from b13 (b13/warmup) and is actively maintained: version 3.0.0 of 23 September 2026 supports TYPO3 v12, v13 and v14. The sitemap-based alternative is the Warming extension by Elias Häußler (eliashaeussler/typo3-warming).

Those currently using manual warmup scripts (curl loops, wget crawlers) can replace them with warmup. The advantage: warmup knows the TYPO3 page tree including languages and user groups and can be started from the scheduler. A manual script crawls blindly; warmup knows every page.

The combination warmup + staticfilecache + Redis is the performance stack Gosign recommends for enterprise TYPO3 installations. warmup fills the cache, staticfilecache serves static HTML files without PHP, Redis stores database queries. Together, TYPO3 websites achieve loading times under 100ms. For websites with fewer than 500 pages and moderate traffic, warmup alone without staticfilecache is sufficient. The simple TYPO3 page cache already delivers loading times under 300ms when correctly filled. warmup ensures this level is maintained from the first second after deployment.