WordPress Core Committer Adam Silverstein has published a proposal for adding automated performance tooling that would offer continuous monitoring for performance issues so they can be resolved before major regressions are committed to core.
“Similar to our unit test suite, automated performance testing would help protect core from introducing large performance regressions by catching problems immediately and tracking performance over time,” Silverstein said. “Automating testing also means saving contributor effort by replacing a time consuming manual process.”
As the Performance team is focused on introducing new features with measurable gains, as well as testing new WordPress releases before they ship, they have haphazardly uncovered what Silverstein described as “significant performance regressions.” A few examples include a regression found before WP 6.1 in theme.json processing and another issue with changes for loading the textdomain.
“Automated testing would catch this type of regression as soon as it was introduced, making it much easier to resolve,” he said.
Silverstein highlighted the Gutenberg project as a good example of performance tracking, as each release publishes metrics for changes in loading time, typing time, and block selection time. The team has also begun tracking TTFB (time to first byte) for classic versus block themes in their code health dashboard, which is helping them see the immediate impact of the latest commits.
“It’s making visible the performance regression in block theme rendering when compared with classic themes for a simple ‘hello world’ page,” WordPress Performance team contributor Emily Clarke said in the team’s most recent meeting. “As a team, we would like to make sure we’re properly prioritizing the tickets we have for 6.2 that would positively impact this metric—particularly anything that we need to land before the beta 1 milestone next week.”
A few contributors have already been working on improving the server response times for block themes, with PRs that should be landing in 6.2.
“Similar to Gutenberg, WordPress core would gather a set of automated performance metrics along with the existing test runs (e.g. unit tests, coding standards) we already have for each new commit,” Silverstein said. “These metrics can be used to identify the exact point a performance regression is introduced into core. At milestones like a major release, the metrics can be compared against the previous release to gauge progress.”
Silverstein proposes WordPress start small with by simply running a set of automated tests on each core commit for things like load time and total query time for classic and block themes. In the future, the team could capture additional server timing metrics and metrics for other contexts beyond the home page, such as the admin and single post post.
Response to the proposal so far has been positive, as the only alternative is relying on individuals to manually uncover new performance bottlenecks and report them. Better tools will help pinpoint these issues faster, before they get rolled out to millions of people.
“Given how much emphasis peer CMS platforms place on ‘advertising’ their performance and benchmarking it against the industry leaders, investing in tools to ensure WordPress continues to perform optimally makes a lot of sense,” WordPress marketing contributor Dan Soschin said. “And, given how many sites are powered by WordPress, even minor gains in performance (including those unnoticeable to most people) add a lot of value to web hosts and lowering overall internet traffic burdens/bandwidth.”
