WordPress gets back on track with the help of automated performance benchmarking and cooperation between core authors. The core development team’s processes were improved throughout the creation of WordPress 6.2.
Which led to a constant focus on performance throughout the whole development process. As modifications are made, these new processes identify issues and stop them from making it into the released version.
The two developments that brought about this transformation are:
A new/unique performance lead role to facilitate communication across teams.
The WordPress team was able to include performance into the development of every aspect of WordPress thanks to those two enhancements, thereby incorporating it into the DNA of the platform.
Comparing those outcomes to earlier core version releases, they are more impressive. With poor performance ratings, WordPress versions 6.1, 6.0, 5.8, and 5.9 all lagged behind.
WordPress 6.1’s Lessons for Developers
Performance regressions, as WordPress calls them, were present in the previous WordPress release, version 6.1, which was characterized by a general decline in performance. When performance declines after an improvement, this is referred to as a performance regression.
They found that even after fixing the biggest single source of performance regression and introducing numerous performance improvements, the total site performance was still impacted by modifications that had a negative impact on performance.
WordPress Performance Core Development
A new performance lead job served as the point person for coordinating the development of WordPress 6.2. The performance lead is not driving the adjustments and enhancements. The development team was responsible for that.
Simply coordinating between the teams, the performance lead. The performance victories on each team’s projects are their responsibility.