Caching in TYPO3—Part 1

Caching is a technique whereby a calculation or query is executed once, then stored for future reference. This can make all subsequent queries much faster.

One problem with this approach is that the cached version can become out of date if information, such as a database entry, changes. For this reason, the cached data needs to be invalidated periodically or whenever the source information changes.

The cached data also needs to be identified by certain parameters so it can be retrieved when appropriate.

TYPO3 has included resilient caching mechanisms for over a decade now. These have proven to be robust and flexible. At the time of writing, we’re looking at TYPO3 v10 specifically, although all concepts already existed in a similar fashion in previous versions of TYPO3. 

There are a number of different caches within TYPO3. In this article we’re focusing on the cache mechanism for generating and rendering a single page.
When TYPO3 renders a specific page on a website, it fetches the output—typically HTML—from TYPO3’s internal caching framework. TYPO3 offers granular caching configuration options. By default, a webpage rendered with TYPO3 is stored for 24 hours in the TYPO3 cache. This cache entry contains data based on all the content and plugins on a page, but also takes into account all relevant URL query string parameters (more on that later) as well as the currently logged in user and their user group. This means TYPO3 caches the output on a per-user-group basis so that, for example, a menu entry that is only accessible to logged-in users can still be retrieved from the cache.

Certain parts of a page might have a piece of specific information, like a personalized greeting, like “Good Evening Benni,” which should never be cached. At b13, we call these parts of a page “uncacheable blocks”. TYPO3 refers to them as “USER_INT” or “COA_INT” objects. TYPO3’s caching mechanism puts placeholders in the cached data as HTML comments—just like the Edge-Side-Includes or Server-Side-Includes approaches and replaces them at the end of every single request with fully dynamic content.

If there are no uncacheable blocks on a website, and the visitor is not logged in, the page is “fully cacheable.” Then, TYPO3 can fetch the full HTML output directly from the cache with a single query to the cache.

When we are consulted to analyze and improve TYPO3’s performance for a website, we look at the website from three angles:

In this scenario, all of TYPO3’s instructions are fetched, all content and all menus are generated, links to other pages are resolved, permission checks are carried out and all referenced images are validated and resized. Once the final output is computed, we have one large string.

The result is stored in the “pages” cache. If there are uncacheable blocks, this information is stored in the cache as well, as these parts need to be executed later on for each request.

The final output (HTML, JSON or RSS) is then sent to the browser.

The contents of a page—menu items, text, media, etc.—have all been calculated cached on a previous hit to the page and are fetched directly from the cache. Calling a cached page is usually approximately 10 times faster than the first hit. So you’ll notice a major loading difference between a first hit and a cached hit.

If there are no uncacheable blocks and no user is logged in, the page could even be cached by a proxy or CDN, resulting in a delivery time of around 20–40ms. By activating the TypoScript option “config.sendCacheHeaders“, you tell TYPO3 to send the appropriate HTTP headers to the browser to the page for a certain amount of time within the browser cache.

A lot of plugins use the uncacheable block mechanism (USER_INT). Login forms, or areas indicating whether a user is logged in, are common use cases. 

However, some extension authors sometimes do not fully validate whether a plugin is cacheable. Even if the plugin shows “nearly real-time” information, the plugin could be configured to only be cached for 1 hour, 30 minutes or even 1 minute.

On the other hand, an element like the login form that, for example, indicates the current login status in the header area of every page of a website, should never be stored in the cache. Here’s a great tip: Fetching this part with an AJAX call makes the rest of the page fully cacheable. In fact, TYPO3’s community hub—TYPO3.org—does exactly that. However, this also means that every visit to a page triggers two calls to your TYPO3 application.

Keeping this information in the back of your head and doing comparisons in the network tab of a browser already gives you a good indication of where a possible bottleneck of a TYPO3 webpage may be hiding.

TYPO3 ships with reasonable default caching settings for regular websites so that many users do not have to configure anything when building a website. However, they are not optimized to every possible use case, which can range from purely static to highly dynamic websites. Depending on one of the angles discussed above (see sections 1, 2, 2a and 2b), TYPO3 already automatically sends the HTTP response headers relevant for browsers and cache servers using the previously described TypoScript setting. However, extensions can modify these headers and site administrators can configure them as well. So in order to fully understand the system’s performance, one must carefully analyze how and why these parameters are sent.

As soon as an editor modifies content on a page, or changes the page title, the page and all pages pointing to this page need to have their cache entries invalidated. TYPO3 does this automatically for you under the hood.

The cached hit needs to be as fast as possible. Depending on the project it should not take longer than 100–200ms.

Analyzing the first hit (preferably with the help of profiling tools like Blackfire can make it more likely to spot a possible bottleneck, revealing some insights on what takes a lot of computing time. So-called mega menus, or separate mobile menus on the same page for various browser breakpoints, create an unusually large number of links (and HTML code) on a page, making the uncached first hit very slow. 

Editors should never need to clear any cache manually if the developer has utilized TYPO3’s full caching power.

Below, we show you a few tricks that we use for all of our projects.

By default, TYPO3 stores cached information in the database (in tables like “cache_pages” or “cache_rootline”). But using the database as a cache can result in slow page rendering. Often the database is stored on a different server, leading to increased network latency, which will add to the system’s overall response time. Having the database service running on the same server can result in the database taking up lots of CPU resources. A relational database such as MySQL is not the ideal tool to use for caching, but all hosters offer a database suitable for TYPO3, so this option is always available.

In more advanced setups, TYPO3 can be customized to use a different cache backend. We’ll highlight the different caches backends in a further chapter.

A cache backend is like an adapter that tells the system where the cached information should be stored. TYPO3 offers adapters for databases, filesystems, pure memory stores, and distributed backends out-of-the-box. As a rule of thumb, putting the most pressing caches for frontend output into a memory-based cache like Redis or Memcached makes our websites load 30% faster. These include “pages” for cacheable page output, “pagesection” for TypoScript instructions and “rootline” for hierarchy-based information of pages, all of which are the “frontend caches” an editor can clear in the TYPO3 backend). Because of the speed improvement, we ship all of our TYPO3 projects hosted in our TYPO3 supported environment with a configured Redis service by default. A fully cached page in TYPO3 configured with Redis as cache backend only needs one database request. The database can then be used solely (and therefore more efficiently) for content management and data retrieval.

Using the right cache backend is crucial, but also highly dependent on your hosting infrastructure. If your database server is located on a remote server, but no memory cache is available, it might be feasible to store your caches on the filesystem—if the server runs with a fast SSD hard disk. But: Using a file-based cache backend is highly discouraged for distributed systems sharing files via NFS. So in general, there is no best way for everybody out there—but there is a specific best way for your project!

Before considering running TYPO3 in a multi-node server setup for performance reasons, ensure you understand the actual bottlenecks of your system and optimize the underlying code or configuration.

We highly recommend reaching out to your hoster and asking about Redis or Memcache support for your TYPO3 website.

Scan for any “no_cache” flags in your TypoScript configuration, and try to find out why this option was set in the first place. We’ve heard about slow TYPO3 setups where developers turned on this option for development purposes but forgot to remove that setting before the page went into production.

TYPO3’s Admin Panel (comes with the system extension adminpanel) can be used to identify uncacheable objects on your webpage and verify if those really need to be uncacheable.

When your “first hit” is slow and you know you can’t do anything about it—perhaps due to various user group combinations and logged-in states, there are ways to warm up these pages periodically by using the crawler extension or a custom warmup extension.

The webserver and the PHP version in use could also become bottlenecks when considering a more performant website, where more optimizations can be achieved in a reasonable amount of time. An audit via web.dev can identify if there are pieces other than TYPO3 that could make your website load faster.

We use web.dev and Blackfire to optimize performance rendering times on our setup to ensure that we get the most out of TYPO3. Feel free to reach out to us and consult b13 to make your visitors‘ experience a pleasure.

Once you’ve optimized your PHP execution times, and you still want to improve the rendering times of a fully cached page, consider using a proxy like Varnish, or a CDN. This needs some developer experience, but we believe these optimizations are worth the effort. At b13, we use Cloudflare as a CDN provider. Cloudflare offers a global scope for having fully cached content available, and even more features like a Web Application Firewall, so your server setups need even less CPU power, since most requests are already handled by the CDN. But beware: With more caching come more pitfalls with regards to not invalidating cache entries properly.

Our core business at b13 is delivering highly customizable, multilingual websites with global reach. Performant websites are a must-have for today’s globally active businesses. Talking to SEO agencies and search index maintainers shows us that performance is the key benefit not just for search rankings, but actually to make the users feel happy on your website.

TYPO3 supports us delivering just that when we follow its internal-caching best practices.

• Ensure that you’ve fully optimized your website following the steps above. If you still feel like there is room for improvement with your existing TYPO3 website, ask us for an independent audit of your project.
• Make sure that the webserver setup is not the actual bottleneck, and optimize for performance beyond PHP.

Our next blog posts in our caching series will give you more insights into the infamous “cHash” parameter, and later-on we’ll also show you how your editors will never ever have to clear a cache ever again because you will have everything perfectly optimized!

See more about cHash-Parameters in Part 2 now.