WordPress 6.2 “Dolphy” was released a few days ago. It is the first release that has had a positive impact across the board, improving all kind of themes, classic and block ones:

The server-side performance of WordPress 6.2.0 entails a +25% improvement for block themes and 10% for classic ones compared to 6.1.1.

— Evolution of WordPress TTFB: 5.6 to 6.2

This is accounting for the 75th percentile — a common industry standard behind web vitals and the HTTP Archive.

The numbers are a major improvement. At the same time, I learned it is a partial picture. That is what this post is about.

The components of Time To First Byte

Time To First Byte (TTFB) is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive.

— Time To First Byte, as defined by web.dev

In essence, it can be influenced by three things:

• The network. The time it takes packets to communicate between client and server: DNS propagation, whether you use CDNs, etc.
• The server. Things that fall into this bucket are: whether you use Apache or ngnix and its configurations, balance loaders, which version of the language is in use, etc.
• The application. How performant the application is.

Those are the components that affect TTFB measured “in the field” — aka data from real users. A lot of the TTFB is influenced by things out of the control of application developers. For example, the same WordPress website will be faster or slower depending on the PHP version provided by the hosting company.

When TTFB is measured “in the lab” –aka data not from real users- important components, such as the network, are very difficult to replicate. This can be an advantage: it allows you to evaluate the impact of some components in isolation from others more easily.

Let’s say you are able to set up an environment where the effects of the network & server can be discarded. Perhaps they don’t contribute much, and you can ignore them. Or perhaps they don’t change, so any difference can be attributable to the application. That’s useful. That’s how TTFB, in the lab, can serve as a proxy for the server-side performance of your application.

Caveats of Time To First Byte

Variations to Time To First Byte do not always match variations to user-perceived performance. That’s why TTFB is not part of the Core Web Vitals and other metrics such as Largest Contentful Page (LCP) are. I’ll share two concrete examples related to WordPress.

The server can do more while the user-perceived performance is improved.

If your WordPress site uses a block theme, one of the things the server does is inspecting the blocks in use by the page. This takes more time than not doing it. It’s worse TTFB.

However, with the extra processing, the server identifies which styles are necessary for the page, and enqueues only those instead of the whole block library stylesheet. By shipping only the CSS in use, the overall performance improves for the user.

This feature was shipped as part of WordPress 5.8, before we tracked any metrics. During the WordPress 6.2 cycle, I was interested in clarifying the relationship between TTFB and other user-centered metrics and raised the topic everywhere I could – specially in the first and in the second hallway hangouts about performance.

Some of the early data points I was able to gather are:

• This experiment. It analyzes the impact of shipping only the CSS in use. This data point tells us that TwentyTwentyThree (block theme) is faster than TwentyTwenty (classic theme), as reported by a user-centered metric such as LCP: 198.60ms vs 208.35ms.

• The Gutenberg dashboard. It now reports some front-end metrics for themes. The data says that TwentyTwentyThree is faster than TwentyTwentyOne in the client, as reported by LCP-TTFB: 30.26ms vs 38.26ms

Even if in early stages, the data points above challenge the common discourse of many in the WordPress ecosystem (“classic themes are faster than block themes“).

I believe TTFB improvements are great, and we need more of them. The WordPress core dashboard shows how close block & classic themes are already: 74.57ms vs 58.72ms. They’ll be even closer in WordPress 6.3, as per some ongoing work. But TTFB is not the full picture.

Your site can be cached, commoditizing server time

The nitty-gritty of measuring server-time was a lot of fun and enlightening. However, there is a clearer use case in which server-time doesn’t correlate to user-perceived performance: caches.

Does your site use a full-page cache plugin? If it does, the time it takes WordPress to process anything in the server becomes the time it takes the cache to return the page. The server setup is commoditized.

One of the best examples I’ve seen discussing this topic is Felix Arntz’s “Rebuilding my website using a block theme“. Felix was the performance release lead for WordPress 6.2, and he’s heavily involved in WordPress performance team. He knows a few things! Go there and read his essay, it’s an account of how block themes are already faster than classic themes in some scenarios. According to his data, his new block theme improves (or matches) the old classic theme in every metric that can be tracked. It’s actually 45% faster than the old classic theme he was using:

Coda

The improvements of Time To First Byte in the WordPress 6.2 cycle have had a great impact on performance across the board. According to this data, it’s the first release that improves server-time performance for all kind of themes — classic and blocks. It’s great progress.

At the same time, Time To First Byte is only a partial picture and, in many scenarios, a distorted one. For a holistic perspective on performance, we need to track user-perceived performance (LCP) and client-side metrics as well (LCP-TTFB).

By understanding the full impact of our work, we will be able to prioritize our work based on impact.