The development of WordPress 6.2 has introduced significant improvements in the core team’s workflow, resulting in a consistent focus on performance at every stage of development. These new processes catch issues when changes are introduced, preventing them from making it into the final version release.
The two key improvements driving this change are:
- A new performance lead role to coordinate between teams.
- Automated benchmarking.
These improvements have made performance a fundamental aspect of developing every part of WordPress, essentially integrating it into its development DNA.
The results speak for themselves:
6.2 is the first major version to improve 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).
These results are particularly impressive compared to previous core version releases.
WordPress versions 6.1, 6.0, 5.8, and 5.9 all experienced negative performance measurements.
Lessons Learned from WordPress 6.1
The previous release, version 6.1, saw an overall decrease in performance, referred to as performance regressions. A performance regression occurs when an improvement leads to a decrease in performance. Despite fixing the largest single cause of performance regression and introducing multiple performance enhancements, overall site performance was still hindered by changes that degraded performance.
WordPress shared the lesson learned from the 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 of WordPress 6.2 was guided by a new performance lead role. This role did not initiate the changes and improvements; that was the development team’s responsibility. The performance lead simply coordinated between the teams. Each team was responsible for the performance wins on their projects.
The performance lead explained:
“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 in identifying performance weaknesses. The introduction of the Performance Lead role …merely provided better representation of performance alongside the other members of the release squad.”
WordPress Automated Benchmarking
Performance regressions often went unnoticed because not every change could be manually checked for its impact on the overall release. To address this issue, WordPress introduced automated performance benchmarking for all changes. This automated system measures the impact of every change to catch hidden performance bottlenecks before they reach the final release versions.
WordPress described 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. This allows us to easily spot potential regressions that previously would have gone unnoticed.”
The WordPress 6.1 update had introduced performance regressions in Gutenberg, which would have been caught earlier with automated testing. Automated performance tests are now conducted at each core commit in GitHub to measure WordPress performance on block and classic themes. The testing also collects server timing metrics using the latest version of PHP.
WordPress Contributors Worked Together
WordPress contributors worked collaboratively to identify areas needing improvement, with a renewed focus on performance. Profiling the server-side performance of the WordPress core was done using open-source tools like Xdebug, XHProf, and Blackfire (SaaS). Standardization of the tools used for performance measurements is in progress to ensure all teams are measuring the same metrics with the same tools.
Fact: WordPress 6.2 Performs Better
The result of automated performance benchmarking and coordination between development teams has led to substantial improvements 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) has seen a major boost of 17-23% for block themes and 3-5% for classic themes, directly contributing to overall load time.”
Performance testing occurs not only at the core commit stage but also for the entire WordPress release candidates.
WordPress described this process:
“At this point, 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 is perfect for this use-case, providing 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 assess how WordPress core performance has changed.”
WordPress Turned a Corner on Performance
For the past few years, WordPress has been working hard to integrate performance improvements into the development workflow. Initially, the performance team focused on reducing redundant or unnecessary JavaScript and adding features like lazy loading images. Now, the team is integrating performance benchmarking directly into the development phase of each component at the GitHub commit level and using automated benchmarking to scale improvements.
In essence, WordPress has successfully embedded performance into its development process. This is one of the most significant changes in how WordPress is developed and a sign that WordPress is catching up with other content management systems.
Finally, WordPress may be back in the performance game.
Featured image by Shutterstock/Asier Romero
