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.


9 responses to “WordPress 6.2 Core Performance Analysis Finds Improving Template Loading for Classic Themes Could Make a Major Impact”

  1. That is amazing that the core performance is taking care of classic themes.

    I have been with WordPress since before B2.

    Do think it would be ever be possible for WordPress core to detach from old libraries?

    Maybe, give 10 years notice, I might be asking too much but just maybe we need to build forward.

    “People might start with LiveJournal or Blogger, but if they get serious, they’ll graduate to WordPress. We try to cater to the more powerful users.”

    • In order to keep their market share, 10 years is too much, people redesign and rebuild based on modern closed-sourced SaaS easy-to-set-up CMSes that blow WP out of the water in terms of performance. If something should happen, it should happen NOW.

    • That is your fault for not learning.

      For me it was like learning something new again. It was difficult at first but it got easier once I understood how it worked.

      WordPress has always been evolving and if you are a WordPress maximalist then learning something new is a requirement.

      Once you stop learning then you start becoming obsolete.

      • Blaming the user…a classic n00b mistake :(

        Having the ability and willingness to learn is not connected to how ease – or not – the material is to learn.

        And when many people (i.e., “The Market) keep repeating the same issues at some point it makes sense to stop ignoring them and listen.

  2. I run two blogs. I’ve switched from classic to FSE and back. Depending on how I want to set the stage for my content, I select the theme I like best, whether classic or FSE. I hope there will always be the option to select from either or. Why put all eggs in one basket?


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: