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 crawls all pages of the website in the background, based on the sitemap, and prioritizes the most visited pages. 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. warmup registers as a hook on the cache clear event and automatically starts the warmup process. The editor notices nothing, but visitors experience no performance drop.

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 the website’s sitemap (sitemap.xml) and extracts all URLs. Alternatively, a crawler can generate the sitemap from the TYPO3 page tree if no sitemap extension is configured. The URL list can be filtered via configuration (e.g. only specific page trees or languages).
• Prioritization: URLs are sorted by priority. Priority can come from the sitemap (<priority> tag), from Matomo/Analytics data or from a manual configuration. The homepage and top-10 landing pages are cached first.
• Crawling: warmup calls each URL via HTTP request. The TYPO3 caching framework stores the rendering result. warmup supports parallel crawling (configurable, default: 4 simultaneous requests) to speed up the process without overloading the server.

The CLI command is vendor/bin/typo3 warmup:execute. 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 offers a dry-run mode that displays the URL list without executing requests. This is useful for verifying the warmup configuration before 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: increase parallelism (e.g. to 8 simultaneous requests), exclude unimportant pages (e.g. pagination pages, tag archives) and limit the process to the top 500 pages. Remaining pages are cached on first visit.

Server load hits 100% during warmup. warmup generates real HTTP requests against the server itself. Without rate limiting, this can drive server load to a level that slows down real visitors. Solution: reduce parallelism and configure a delay between requests (e.g. 100ms). 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 (eliashaeussler/typo3-warming) is available for TYPO3 v11 and v12 LTS and is actively maintained. For TYPO3 v13, compatibility is expected shortly after the release.

Those currently using manual warmup scripts (curl loops, wget crawlers) can replace them with warmup. The advantage: warmup understands the TYPO3 sitemap structure, prioritizes by traffic and integrates with the scheduler. A manual script crawls blindly; warmup crawls intelligently.

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.