Overview
During the 6.2 Release Cycle, members of the WordPress Performance Team performed a performance analysis in order to identify the biggest opportunities to target for future performance enhancements. To do so, the team first created a methodology that could be used to perform a repeatable process by which results could be tested and confirmed. The full methodology and analysis can be found in this document.
Analysis scope and methodology
To start, the team identified a number of key use cases that would be tested. These were meant to cover the primary out of the box functionality of a simple, default WordPress site, which included testing both a classic theme (Twenty Twenty-One) and a block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme (Twenty Twenty-Three) both configured with the same content from the Theme Unit Test data. 5 specific scenarios were tested for both themes:
- A homepage showing the latest posts: A common use case that includes fetching data for a list of several posts in a single request
- A basic page that is text only: A minimal use case that can serve as a baseline against a more complex post.
- A post page including a large set of images and default blocks: This use case allowed us to observe the effect of extra database queries and PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher routines required to render a complex page that is more realistic.
- The same homepage, with translation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization.: This allowed us to see the performance impact of WPs translation functionality compared to a non-translated site.
- The same basic page, with translation: Same as above.
Each profiling test was done on a wp-env docker environment running PHP 7.4 (the recommended version for WP when the analysis was conducted) with XHProf installed for profiling. Other use cases and configurations were considered but not included in this initial analysis, including testing with a persistent object cache active, a multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site setup, and additional supported PHP versions.
Observations from the analysis
Below are the biggest opportunities identified for potential performance improvements, based on the profiling data collected against WordPress 6.2. An overview of the raw data for these observations is in the full results spreadsheet. When possible, relevant existing tickets for each improvement area are included for reference. These are not meant to be an exhaustive list of everything that will be addressed and additional tickets should be created as needed.
Improve template loading and rendering for classic themes
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 A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. 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.
Related tickets:
Improve rendering of block widgets
Related to template loading, loading and rendering block widgets (i.e. profiling WP_Widget::display_callback) took ~8–24% of the response time. This may be partially due to the inclusion of widgets in the theme test data and may not be representative of all themes. Even so, we have identified that much of this code runs even when a theme is not utilizing widgets, making it a good candidate for further exploration. It’s possible that some widgets have a larger impact than others. For example, the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. categories block used in the category The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. list widget was responsible for 5–10% of the response time in our tests.
Related tickets:
Improve registration of blocks from metadata
In all test scenarios, register_block_type_from_metadata() is called 91 times and takes from 3–24% of total response time across use cases, with a larger impact on block themes than classic themes. It is heaviest on the home page, and always worse in the first request compared with subsequent ones. Again, much of this time is due to file operations that could be optimized. We could also consider techniques like lazy loading block registration based on whether blocks are in use on a page, or caching registered blocks to avoid duplicate file read operations for blocks that are unlikely to change. For block themes, block registration accounts for 15–25% of the total response time, with register_block_style_handle() specifically accounting for most of that time (184 calls, 13–21% of inclusive wall time, or iwt).
Related tickets:
Improve loading translations
In both theme types, the load_textdomain() function was called 2 times when language packs are in use (once for core, and once for the theme), and is responsible for 9–26% of the total response time (most of which is the MO::import_from_file method). This took up a higher percentage of the execution time in the classic theme tests (17–26%) than the block theme tests (9–16%), which may point to opportunities for improvement in classic themes.
- MO::import_from_reader (1 call, 9–25% iwt)
- MO::make_entry (4058 and 3977 calls in our classic and block use cases, respectively, 2–7.5% iwt)
Related tickets:
Improve resolving block templates
For block themes, resolving block templates from the file system takes a large amount of time. This is likely due to the need for both database and file system reads during this process. Example function paths:
- get_block_templates (12–21% iwt)
- get_block_theme_folders (3–6% iwt)
- build_template_part_block_instance_variations (4–6% iwt)
Related tickets:
Improve term field sanitization
Term field sanitization is being called ~3000-5000 times during a page load in our classic theme tests—adding 1–6% to the total response time alone. A recent change has already been identified that contributed to this problem, and a fix has been committed. A deeper look into ways of reducing unnecessary calls to this function could result in additional improvements. Interestingly, block themes don’t exhibit the same problem with sanitize_term_field, as with classic themes, so it would be helpful to understand why to see if the same improvements could be applied to classic themes.
Related tickets:
- #57966
- #37189 (possible regression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. in wp_get_object_cache)
- #50568
- #58327
- #58329
Additional block theme improvements
Other notable functions that are taking up a lot of time in block themes related to parsing and using data from theme.json JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. and block registry include:
- WP_Theme_JSON::compute_style_properties (65 calls, 2–8% iwt)
- > WP_Theme_JSON::get_property_value (3453 calls, 1–2% iwt)
- Note: this has since been fixed (Related PR)
- WP_Block_Type_Registry::get_registered (homepages only: 3422 calls, 1–2% iwt)
- Likely performance improvements can be made to WP_Block_Type_Registry::is_registered method.
- The function, wp_maybe_inline_styles is particularly slow on the homepage, but always contributes to a large portion of the request time for block themes. (2 calls, 7–18% of iwt)
Related tickets:
Proposed priorities from the research
Of all the opportunities identified during this analysis, the ones that seem likely to produce the largest impact are the following:
- Improve template loading for classic themes – A majority of websites (based on an April 2023 search of the HTTPArchive) still use the classic theme architecture, so improvements made here could have the largest horizontal impact.
- Improve translation loading – The translation process has a large performance impact when in use. Given that 56%+ of all WordPress websites are using translations, performance improvements to the translations system should have a large horizontal impact as well.
- Improve handling of block registration from metadata – block registration requires expensive file reading and parsing, which could be cached. Additionally, every block might not be needed for every request, so more intelligent registration logic could eliminate the need for much of this effort.
- Improve resolving block templates – this is a heavy operation for block themes that is unlikely to change often unless the site templates are edited or the theme is updated. The addition of some caching mechanisms could really improve TTFB (note that some improvements to this system have already been implemented during the 6.3 release cycle).
- Improve rendering of block widgets – This is a lower priority when compared to the previous items due to the fact that further research is needed to determine the horizontal impact of these changes. Specifically, it’s possible that these test cases may not be representative of real world uses of block widgets.
These efforts will likely require additional research and architectural design before engineering begins. All other items identified could be worked on directly through individual Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets as capacity allows.
Future efforts worth consideration
- Finish making the XHProf/XHGui tooling available more broadly via wp-env and a core environment integration so more people can verify and extend the work we’ve done here.
- Reach out to hosting companies to get various platforms to run analysis on their infrastructure as well.
- Do additional analysis on use cases not covered in this initial effort, e.g., PHP Versions, Object Caching setups, etc.)
- Review and improve the approach used in this analysis to make it easier for the same type of research to be conducted in the future
Thank you to @annezazu, @desrosj, @flixos90, @mukesh27, @oandregal, @spacedmonkey, and @swissspidy for reviewing and helping with this post.
#6-2, #core, #performance
You must be logged in to post a comment.