WordPress 6.2 “Dolphy” was released a few days ago. It is the first release where I was involved in performance work, as per my role of core contributor. It is also 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 that is also used for measuring web vitals and the HTTP Archive.
It is impressive, isn’t it? It really is. At the same time, by contributing to WordPress, I learned that server-time 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, TTFB 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 — this is, 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.
A different dataset results of measuring TTFB “in the lab”, which stands for measuring a non-production environment. Important components, such as the network, are very difficult to replicate in the lab. The lab also has advantages: it allows you to evaluate the impact of some components in isolation from others more easily.
Let’s say that 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. 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 in WordPress 5.8, before we tracked any metrics. During the WordPress 6.2 cycle, I partly focused on clarifying the relationship between TTFB and other user-centered metrics. I raised the topic of metrics and methodology 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. It was enlightening as well. However, there is a bigger 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. No matter which kind of theme you use.
This is a very common setup. 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 add client-side metrics to the mix (LCP-TTFB). By understanding the full impact of our work, we will be able to prioritize our work based on impact.
Leave a Reply