WordPress 6.2 Core Performance Analysis Finds Improving Template Loading for Classic Themes Could Make a Major Impact

WordPress’ Performance Team has published a summary of a core performance analysis they completed in order to identify and prioritize areas for improvement. As part of this process, contributors created a methodology with a standard set of tools that can be used to collect and share profiling data for various components of the application.

The team tested a classic theme (Twenty Twenty-One) and a block theme (Twenty Twenty-Three) configured with the Theme Unit Test data. They tested out of the box functionality, in addition to different scenarios such as a homepage displaying the latest posts, a basic text-only page, a page with a large set of images and default blocks, and a homepage and a basic page with translation.

These tests uncovered numerous performance issues which the team has documented with related trac tickets and detailed in the summary of the findings. The first priority identified for improvement is template loading for classic themes.

Although WordPress contributors are blazing forward on the project’s roadmap for the block editor, with most of the headline release features focused on site editing, block theme adoption is not where one might expect it to be more than four years after Gutenberg landed in core.

“A majority of websites still use the classic theme architecture, so improvements made here could have the largest horizontal impact,” 10-up sponsored WordPress Core Committer Joe McGill said in the summary.

McGill referenced data collected in April 2023 for the HTTPArchive which uses a query based on a new HTTP Archive custom metric to detect block theme adoption. Based on this information, improving template loading and rendering for classic themes should remain a high priority. Most of the WordPress-powered web is still running on classic themes.

The summary highlights the improvements for template loading that would make the most impact:

In the classic theme tested, the most expensive process is related to locating and rendering template parts. This starts with get_template_part(), includes the process of locating the template part files with locate_template(), and rendering the content for each template part. This whole process accounted for approximately 30–60% of the entire server response in the test results, with much of that time spent handling filesystem checks (e.g., file_exists() is responsible for 4–9% of all time measured and can likely be optimized with a cache), rendering widget blocks, etc. Given many of these filesystem checks aren’t likely to produce different outcomes often between requests, there are likely opportunities to find substantial improvements here.

These improvements are the first of five priorities the Performance Team identified as the result of analysis. The second recommendation is to improve translation loading, as more than 56% of all WordPress websites are using translations.

The other three priorities include improvements for block-powered sites, with the first two ringing up as the most costly operations in terms of performance:

• Improve handling of block registration from metadata
• Improve resolving block templates
• Improve rendering of block widgets

“These efforts will likely require additional research and architectural design before engineering begins,” McGill said. “All other items identified could be worked on directly through individual Trac tickets as capacity allows.”

The Performance Team is considering making the tooling for performance profiling more broadly available so other contributors can extend their work. In the future, they may also consider contacting hosting companies to get them to run analysis on their infrastructure and examine additional use cases, such as PHP versions, Object Caching configuration, and more. Once the methodology used for this analysis is nailed down, future efforts to improve performance may become more frequent and easier to produce.