TYPO3 Page Cache: Cutting Load on Read‑Heavy Sites

The problem: spikes on public pages

On a typical TYPO3 site the majority of traffic hits a handful of public pages—landing pages, news listings, product overviews. Each request runs the full PHP bootstrap, resolves TypoScript, queries the database, and renders Fluid templates. When traffic spikes, CPU and database load climb sharply, and response times degrade.

The built‑in page cache extension solves exactly this: it stores the final HTML fragment of a page in the configured cache backend (file, database, Redis, etc.) and serves it on subsequent hits without re‑executing the rendering pipeline.

How the page cache works

• Cache key – generated from the page ID, language, and optional cache tags.
• Storage backend – any backend registered in $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']. The default is the file backend; Redis or Memcached are common production choices.
• TTL – time‑to‑live in seconds (default 86400). After expiry the entry is recomputed.
• Tags – optional identifiers (e.g., news_123) that allow targeted invalidation when a record changes.

When a request arrives, TYPO3 checks the cache first. A hit returns the stored HTML and adds an X-Cache: HIT header; a miss runs the normal rendering and writes the result back to the cache.

Enabling and configuring the cache

The extension ships with the core, so activation is a one‑line change in ext_localconf.php of your site package (or any extension that loads early).

// EXT:my_site/ext_localconf.php
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['backend'] = \TYPO3\CMS\Core\Cache\Backend\RedisBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['options'] = [
    'server' => '127.0.0.1',
    'port'   => 6379,
    'database' => 0,
];
// Enable page cache globally
$GLOBALS['TYPO3_CONF_VARS']['FE']['pageCache']['enabled'] = true;
// Optional: default TTL (seconds)
$GLOBALS['TYPO3_CONF_VARS']['FE']['pageCache']['ttl'] = 3600;

After editing, clear the system caches so the new configuration is loaded:

# Run from the project root (requires write access to var/cache)
./vendor/bin/typo3 cache:flush

Permissions: the CLI user must own var/cache (or the configured Redis instance must be reachable).

Worked example: a news listing page

1. Identify the page UID (e.g., 42) that renders the news list.
2. Add a cache tag to the plugin so the entry can be invalidated when a news record changes:

   # EXT:my_site/Configuration/TypoScript/setup.typoscript
   plugin.tx_news {
       settings {
           cacheTags = news_list
       }
   }

3. Deploy the change and flush caches (./vendor/bin/typo3 cache:flush).
4. Visit the page once to populate the cache.
5. Verify the cache hit:

   curl -I https://example.com/news/
   # Expected header
   X-Cache: HIT

6. Run a quick load test (ApacheBench shown for illustration; adjust concurrency to your environment):

   ab -n 200 -c 20 https://example.com/news/

   Compare the Time per request before and after enabling the cache. A typical reduction on a read‑heavy page is 60‑80 %.

Note: The numbers above are illustrative; actual improvement depends on template complexity, backend latency, and server resources.

Trade‑offs and limitations

• Memory pressure – File or Redis backends evict entries when memory limits are reached, causing frequent recomputation on low‑memory hosts.
• Manual invalidation – The cache does not automatically know when a content element changes. You must either rely on TTL expiry or explicitly flush tags (e.g., ./vendor/bin/typo3 cache:flushtags news_list). Stale content appears if this step is missed.
• Dynamic content – Personalized blocks (user‑specific menus, session‑dependent pricing) cannot be cached safely. Use COA_INT or USER_INT objects for those fragments.

Verification checklist

1. Inspect response headers for X-Cache: HIT on a second request.
2. Open the TYPO3 backend → Administration → System → Cache → Page Cache and confirm entries exist for the target page UID.
3. Run a before/after benchmark (ApacheBench, k6, or GTmetrix) and record the median response time.
4. Trigger a content change (edit a news record) and verify that the cache entry is removed either by TTL expiry or by running cache:flushtags news_list.

Actionable next step

Enable the page cache on your staging environment today, point it at a Redis backend, and run the verification checklist. Once you see a stable X-Cache: HIT and a measurable latency drop, promote the same configuration to production. Remember to add cache‑tag invalidation to your deployment scripts so content editors never serve stale pages.