Evolution of WordPress TTFB: 5.6 to 6.2

Published on February 6th, 2023: data was for WordPress 6.2.0 beta. Edited on March 30th: updated the numbers using the public version of WordPress 6.2.0 and polished the wording and links.

During the last trimester of 2022, I focused my time on improving server-side performance for WordPress. That work has been shipped as part of WordPress 6.2 “Dolphy”. It was a lot of fun, I’ll share more about it some day. This post is about something related: tracking front-end server-side performance.

One of the things I shipped on this cycle was the ability to track front-end metrics in Gutenberg. Initially, server-side metrics like Time To First Byte — aka TTFB. Then, also some client-side metrics. I was inspired by the long history of tracking editor metrics in Gutenberg that Riad set up. The performance team was inspired by this whole effort as well, and they set up a dashboard for WordPress server-side metrics.

With this new tool in my toolbox, I wanted to know the evolution of TTFB across the last major WordPress releases. So. I prepared an experiment: how long does it take the server to process the homepage for each of the last 4 default themes? I ran the experiment 1 000 times for each scenario and calculated a few metrics related to time per request: median, minimum, maximum, and 75th percentile (see full dataset):

Key takeaways:

• 6.2 is the first major version that improves server-side performance across the board:
  • +25% for block themes in all metrics (median, min, max, 75th percentile).
  • +10% improvement for classic themes (75th percentile).
• 6.1 worsened it for block themes and improved it for classic ones.
• 6.0 and 5.8 took a major hit for every type of theme. 5.7 also had a negative impact.
• 5.9 improved classic themes.

Steps to replicate

In case anyone is interested in replicating the experiment, this is what I’ve done:

1. Cloned the wordpress-develop repository and switched to the corresponding major version to measure.
2. Set WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG to false in .env.
3. Started the environment: npm install && npm run build:dev && npm run env:start && npm run env:install.
4. Ran the test: load the homepage. I used this command: seq 1000 | xargs -Iz curl -o /dev/null -H 'Cache-Control: no-cache' -s -w "%{time_starttransfer}\n" http://localhost:8889 | xclip -selection clipboard.
5. Pasted the results in the spreadsheet.
6. Switched to a different theme. Go to step 4.

Coda

WordPress 6.2 brings a great improvement in server-side performance, it’s the first that has had a positive impact across the board. Though great to see, improving server-time performance is only a part of the picture, in some scenarios it even becomes commoditized.

Tracking front-end metrics has improved the quality of the conversations around performance in the WordPress community. In retrospect, it’s obvious: until we can see the impact of our work, we are unable to prioritize work based on impact.