smic / page-warmup
Page Cache Warmup
Package info
github.com/smichaelsen/typo3-page-warmup
Type:typo3-cms-extension
pkg:composer/smic/page-warmup
Requires
- typo3/cms-core: ^12.4 || ^13.4 || ^14.0
Requires (Dev)
- phpstan/phpstan: ^2.1
- phpunit/phpunit: ^11.5
- typo3/cms-frontend: ^12.4 || ^13.4 || ^14.0
- typo3/cms-scheduler: ^12.4 || ^13.4 || ^14.0
- typo3/testing-framework: ^9.3
Suggests
None
Provides
None
Conflicts
None
Replaces
None
- dev-main
- 1.1.0
- 1.0.0
- dev-topic/reservation-collection-full-scans
- dev-feature/default-user-agent
- dev-topic/v14
- dev-topic/phpstan-level-4-ci
- dev-smichaelsen-patch-1
- dev-topic/v13
- dev-task/v12compat
- dev-bugfix/cache-tag-db
- dev-bugfix/cache-tag
- dev-task/logging-2
- dev-task/remove-flush-bind
- dev-task/whitelisted-params
- dev-task/logging
- dev-task/v11-compat
This package is auto-updated.
Last update: 2026-09-01 13:25:33 UTC
README
Cache warmer for your TYPO3 pages ☕️
When content is edited in TYPO3, caches for certain pages are flushed automatically. Depending on your setup that can be dozens of pages with news plugins that are flushed when a news record is edited, for example.
This extension detects URLs of pages that have fallen out of the cache and provides a scheduler task to warm them up automatically, before your visitors have to do it.
Installation
composer require smic/page-warmup
Usage
After installing the extension, set up a new scheduler task with the class "Page Cache Warmup Queue Worker (page_warmup)". The recommended (conservative) setup is:
- Type: Recurring
- Frequency: 120
- Don't Allow Parallel Execution
- Time limit in seconds: 60
That's it. Whenever the caching framework flushes page caches based on cache tags, the affected pages will automatically get warmed up again.
If the cache warmup is too slow, you can try a more aggressive setup like:
- Type: Recurring
- Frequency: 60
- Allow Parallel Execution
- Time limit in seconds: 240
That will result in ~ 4 simultaneous task processes, that are working on the queue. That means increased load on your system.
Warmup requests
Warmup requests are sent with the user agent TYPO3-PageWarmup, so they can be told apart from
real visitors in your access log and excluded from your analytics.
Before the queue is worked through, the extension dispatches a PrepareWarmupRequestOptions PSR-14
event carrying the Guzzle request options that every warmup request is sent with. A listener can
add to them or replace them — to send HTTP basic auth on a protected instance, to set a cookie the
site needs, or to replace the user agent:
use Smic\PageWarmup\Events\PrepareWarmupRequestOptions; use TYPO3\CMS\Core\Attribute\AsEventListener; #[AsEventListener] final class AddBasicAuthOnWarmupRequest { public function __invoke(PrepareWarmupRequestOptions $event): void { $options = $event->getRequestOptions(); $options['auth'] = ['username', 'password']; $event->setRequestOptions($options); } }
#[AsEventListener] needs TYPO3 v13 or newer. On v12, register the listener with the
event.listener service tag instead.
Under the hood
In the TYPO3 caching framework entries are flushed by tags or all at once, and it gives you no feedback about what content / information has actually been flushed - that makes it hard to know what needs warming up. That's why this extension collects that information when a page is cached. It remembers the URLs and cache tags in a so called warmup reservation. When a cache tag is flushed, the extension can pull up all reservations matching that tag, and write the page URLs to a warmup queue.
Detecting when a page is cached
TYPO3 doesn't have a suitable hook or middleware to react to pages being cached, so this Extension provides a cache VariableFrontendWithWarmupReservation and registers it for the pages cache. It
takes a look at all incoming cache entries and what looks like the cache entry for a page, will be written into a warmup reservation.
