t3land

Improve

TYPO3 Page Speed Optimisation

A slow TYPO3 site almost always has one of three causes, and none of them is “the images are too big”. We look first for what is defeating the page cache and optimise what is left afterwards.

Start a project

Three causes cover nearly everything

When we take over a slow TYPO3 installation, the finding is rarely exotic. It is nearly always one of three things: the page does not come from the cache, images go out at their original size, or every page loads code that only one page needs.

All three are easy to find once you know where to look, and all three are configuration questions rather than rebuilding projects. So the work starts with a measurement, not with an estimate.

The page cache is the biggest lever

TYPO3 stores the finished page and serves it directly on the next request. That is the single most important reason a TYPO3 site can be fast, and the most common place where speed goes missing.

The cache is easy to defeat: a content element that deliberately renders uncached, a plugin that recalculates its output on every request, an extension that starts a session and thereby personalises the page for everyone. The effect does not show during development, because development runs without the cache anyway. It does not show in testing either. It shows when traffic arrives.

So we look first at which pages are being cached at all and which element is preventing it. Often it is exactly one, and often it can be rebuilt so that only the dynamic part stays uncached instead of the whole page. What sits behind this is described in the glossary under caching.

Images: not smaller, but right

The TYPO3 file handling converts images into the sizes actually needed and stores the results. That works well once configured, and not at all when the template outputs the original file.

We check three things here: whether conversion happens at all, whether modern formats go out, and whether every image carries width and height in the markup. The last point has nothing to do with file size and is often the most visible one: without dimensions the browser does not know how much space to reserve, and the layout jumps while the page loads. That is exactly what Google measures as layout shift.

What loads on which page

The third classic is assets included globally through TypoScript. A carousel script only the home page needs. A stylesheet for a form that appears on a single subpage. An icon set of which three symbols are used.

This does not come from carelessness but because including something globally is the shorter route and bothers nobody while building. Clearing it up means finding out what is genuinely used and moving the rest to where it belongs.

Measuring, and measuring properly

In optimisation work, the measurement is the actual job. Measure two variants one after the other and a substantial part of what you measure is the daily form of the machine you measure on.

So we work like this. The baseline is taken on Google’s infrastructure, not on a development machine. Comparisons between two states run interleaved, A, B, A, B, across several passes, and the median is what counts. Measured in blocks, every load fluctuation of the machine moves straight into the comparison and you end up optimising against noise.

It sounds laborious and it is the difference between a demonstrated improvement and a claimed one.

What happens afterwards

An optimisation is a date, not a state. Content grows, extensions get updates, and at some point somebody adds a script for a campaign and never removes it.

For that to surface before anyone reports it, an ongoing measurement belongs to the job. We use SiteSentry for it, the free tool from aceArt GmbH: it measures at regular intervals through Google’s official interface and gets in touch when a value drops below your threshold.

Where we look first

What defeats the cache

The biggest lever in TYPO3 is the page cache. A single careless content element that renders uncached costs more time than any amount of image work gives back.

Images through FAL

Which sizes actually go out, is the conversion to modern formats taking effect, and are width and height in the markup? Missing dimensions are the most common cause of a jumping layout.

Assets where they are needed

Stylesheets and scripts included on every page through TypoScript although only one detail view needs them. That never shows up during development and shows up on every request.

Queries and database

List views without a limit, relations fetched one record at a time, missing indexes. None of it appears with twenty test records; it appears with real data.

Fonts and third-party content

Embedded maps, videos and other people's widgets are often the largest single item. Which of them is genuinely needed is an editorial decision, not a technical one.

Measure before and after

Every change is measured against the same baseline. Without a reference point, an optimisation is a claim rather than a result.

Common questions

We score close to full marks in PageSpeed Insights and the site still feels sluggish. How?

Because the score comes from a lab measurement: a simulated connection, a simulated device, one page. What your visitors experience is field data from real Chrome sessions, and that sits in Search Console under Core Web Vitals.

The two usually diverge for the same reasons: the home page was measured and the search results list is the slow one. Or the lab measures with an empty cache while the bottleneck only appears for logged-in users, for whom TYPO3 is not allowed to cache at all.

Is compressing the images not enough?

That is the part that goes fastest and rarely the part that gives most back. TYPO3 can convert images into suitable sizes and modern formats largely on its own; that is a question of configuration.

The bigger item usually sits before it. If the page does not come from the cache at all, TYPO3 rebuilds it on every request. How heavy the images are is secondary at that point.

Would a faster server help?

Sometimes, and usually less than people hope. More processing power shortens the time to the first byte when the bottleneck genuinely sits there. When the page comes from the cache, that time is short anyway.

Looking at the environment is still worthwhile, just elsewhere: PHP version, OPcache, database version. What an environment has to bring is set out in the guide on hosting requirements.

How long does an optimisation last?

Without observation: until the next larger round of content work. A site rarely turns slow in a day. It turns slow over months, because content grows, extensions arrive and somebody adds a marketing script.

So a measurement that keeps running belongs to an optimisation. How that works without effort is described under page speed monitoring.

More services

Site feeling slow?

Send us the address. We will measure where it stands and tell you whether the bottleneck sits in the caching, in the delivery or in a single extension.

Start a project See what we do