The development of WordPress 6.2 introduced improvements to how the core development team works, resulting in a consistent focus on performance at every step of development. These new processes catch problems at the time changes are introduced, preventing them from making it into the final version release.
The two improvements responsible for this change are:
- A new performance lead role to coordinate between teams
- Automated benchmarking
Those two improvements allowed the WordPress team to make performance a part of developing every part of WordPress, essentially adding it to its development DNA.
The results speak for themselves:
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).
Those results are more remarkable when compared to previous core version releases.
WordPress versions 6.1, 6.0, 5.8 and 5.9 all fell behind with negative performance measurements.
Lessons Learned from WordPress 6.1
The previous WordPress release, version 6.1, was marked by an overall decrease in performance, what WordPress refers to as performance regressions.
A performance regression is when an improvement leads to a decrease in performance.
What they discovered is that even though they fixed the largest single cause of performance regression as well as introduced multiple performance enhancements, the overall site performance was still dragged down by changes that degraded performance.
WordPress explained the lesson they learned from the version 6.1 release:
“Despite other performance enhancements landing in those releases, the regressions effectively ended up canceling out the enhancements.”
…The more regressions there are, the less impactful any other performance enhancements are overall.”
WordPress Development Performance Lead
The development process for WordPress 6.2 was completed with coordination from a new performance lead role.
The Performance Lead is not initiating the changes and improvements. That was the job of the development team.
The Performance lead simply coordinated between the teams.
Each of the teams are responsible for the performance wins on their projects.
The performance lead explained how this worked:
“This enabled me to closely collaborate and support the other contributors and coordinate with them our performance measurement approaches.
…the performance wins in this release are a result of excellent work from several contributors on identifying performance weaknesses.
The introduction of the Performance Lead role …merely brought a better representation of performance alongside the other members of the release squad.”
WordPress Automated Benchmarking
WordPress noted that performance regressions happened unnoticed because not every change could was manually checked for the impact to the overall release.
To address the shortcoming of not being able to manually test every single change to the core, WordPress introduced automated performance benchmarking for all changes.
Automated performance benchmarking measures the impact of every change in order to catch hidden performance bottlenecks before they make it into the final release versions.
WordPress describes this workflow change:
“Several contributors have been collaborating on introducing an automated performance measuring CI workflow to WordPress core…
With this CI workflow, WordPress core performance metrics are now recorded for every single commit and are available in this dashboard.
This allows us to easily spot a potential regression where previously it would have gone unnoticed.”
The WordPress 6.1 update introduced performance regressions in Gutenberg, problems that would have been caught ahead of time with automated testing.
Automated performance tests happen at each core commit in GitHub to measure how WordPress performs on block and classic themes.
The testing also collects server timing metrics using the latest version of PHP.
More information on automated performance monitoring here: Automated performance monitoring in WordPress core.
WordPress Contributors Worked Together
WordPress contributors worked to identify areas that needed improvement with a renewed focus on performance.
Profiling the server-side performance of the WordPress core was done with open source tools Xdebug, XHProf and Blackfire (SaaS).
Benchmarking the WordPress core was less straightforward because the development groups used different tools.
Standardization of the tools used for performance measurements is currently in progress so that all the teams are measuring the same thing with the same set of tools.
Fact: WordPress 6.2 Performs Better
The result of automated performance benchmarking and the performance coordination between the development teams is a substantial improvement in performance metrics.
WordPress shared:
“Based on lab benchmarks, WordPress 6.2 loads 14-18% faster overall for block themes and 2-5% faster overall for classic themes (measured via Largest Contentful Paint / LCP).
Particularly server-side performance (measured via Time to First Byte / TTFB) is seeing a major boost of 17-23% for block themes and 3-5% for classic themes, which directly contributes to the overall load time.”
Performance testing happens not only at the core commit stage, benchmarking takes place for the entire WordPress release candidates.
WordPress describes this process:
“At this point in particular, it is advisable to use the production ZIP version of WordPress core (e.g. a particular Beta or RC release) instead of measuring in the WordPress core development environment.
The ‘benchmark-web-vitals’ command mentioned in the previous section is perfect for this use-case, as it provides high-level performance metrics that capture both server-side and client-side performance.
The resulting data can then be compared with the same metrics from e.g. the previous stable release, to get an idea how performance of WordPress core has changed (hopefully improved!) in the new release.”
WordPress Turned a Corner on Performance
WordPress has been working hard for the past few years to integrate performance improvements into the development workflow.
In the beginning the performance team was making improvements such as reducing redundant or unnecessary JavaScript that was loaded for each page and adding things like lazy loading images.
But now the performance team is integrating performance benchmarking straight into the development phase of each improved component at the GitHub commit level and using automated performance benchmarking to scale improvements.
In essence, WordPress has successfully added performance into the DNA of it’s development process.
This is one of the most consequential changes for how WordPress is developed and a sign that WordPress is on the path to catching up to other content management systems.
Finally, WordPress may be back in the performance game.
Read the full WordPress announcement, which contains details of their progress and links to the tools used to benchmark performance.
The benefits of prioritizing and measuring performance in WordPress 6.2
Featured image by Shutterstock/Asier Romero
SEJ is Now Subscriber-Only
