WordPress 6.6 Performance Improvements
This post is the latest in a series of updates focused on the performance improvements of major releases (see 6.5, 6.4, 6.3, and 6.2).
On July 16, 2024, WordPress 6.6 “Dorsey”
was released to the public and includes some significant performance improvements. Continuing with work from previous releases, this release delivers significant performance improvements to the editor. Template loading improved by a notable 35+% with this tracking issue capturing all block editor improvements. For the second release in a row, significant new features were added for users to customize their sites, while ensuring minimal impact on server response times.This post summarizes the performance change since the last release in the 6.5 branch (6.5.5) and the 6.6 release, and then digs into the details of the most significant performance related changes.
Analysis shows that block themes (Twenty Twenty-Four was tested), experienced modest regressions in performance. The median Largest Contentful Pain (LCP) time shows a slight 7ms or 5% decline in tests, and the median Time To First Byte (TTFB) shows a 10ms (14%) decline. While some overhead typically accompanies new features, these declines point to areas where we can improve in the future.
Classic themes show a smaller regression (Twenty Twenty-One was tested). The median Largest Contentful Pain (LCP) time shows a slight 1ms or 1% decline in tests, and the median Time To First Byte (TTFB) shows a 1.2ms (3%) decline.
Further details on the methodology behind these measurements are provided later in this article, along with an explanation of possible regression sources.
Key changes
Priming transient and transient timeout options in `get_transient`
On sites without a persistent cache, temporary transients are stored in two options. One containing the transient itself, the other containing the timeout. In #61993 the querying of expiring transients is reduced from two to a single database request. Impact could be significant on sites running plugins that make heavy use of transients.
Obsolete polyfills dependencies have been removed
In #60962 now obsolete polyfills such as wp-polyfill, wp-polyfill-inert and regenerator-runtime were removed from the react script dependency in WordPress. They are no longer needed in modern browsers supported by WordPress. Typical sites using React on the front end may see a moderate performance improvement because these scripts will no longer need loading and contend for resources other scripts might need.
Disable autoload for large options
In #42441, autoloading for options was given more granular control. In addition, when options are added without explicitly setting an `autoload` value, WordPress will automatically skip autoloading for large options (see dev note). The goal of this change is to reduce slow database responses, sometimes caused by very large autoloaded options.
Add a “Audit Autoloaded Options” section in Site Health
#61276 adds a test under the Site Health section to monitor autoloaded options. It displays the number and size of autoloaded options. It shows a ‘good’ status if the autoloaded options are within acceptable limits but a ‘critical’ status if the autoloaded options exceed the predefined threshold (default: 800,000 bytes), indicating a potential performance issue.
Cache block theme patterns persistently
In [58025], block theme patterns caching was updated to use transients so in order to extend the performance benefits of caching these patterns to sites that are not running an external object cache. Our initial benchmarks showed that eliminating the cost of loading all of the Twenty Twenty Four theme’s block patterns on each request saved ~13% of the total server response time.
Introduce wp-on-async directive as performant directive
In Gutenberg PR 61885 a new wp-on-async directive was added to the Interactivity API. This ensures that when there are multiple directives for the same event, they do not add up to a long task. This is also true if a single directive itself causes a long task. It also gives the main thread time to update the UI before running any potentially long handler code, since this directive yields to the main thread immediately before invoking the action/callback. Core blocks including navigation, query pagination and search were all updated to use the new async callbacks in GB PR #62160. Lastly, if an action is unable to leverage wp-on-async due to needing synchronous access to the event object, the wordpress/interactivity package now exposes a splitTask() function which can be used to manually yield in the callback. See example in the documentation for Async Actions.
Enable lazy-loading of post embeds
WordPress lets you embed a preview of a post into another post simply by pasting its URL in the editor. In #58773, the resulting iframe is now automatically lazy loaded similar to the way other embeds are lazy loaded.
Optimizations for transients
Network transients are now primed in a single call and get_site_transient was updated to prime multiple caches at once. The wp_prime_network_option_caches function was added, saving ~3 datebase calls per page load on multisite. See #61193 and #61053.
How release performance is measured
The performance measurements used for the overview are based on benchmarks conducted using an automated workflow on GitHub action runners. Benchmarks were taken of the homepage of the Twenty Twenty-One and Twenty Twenty-Four themes with and without object caching enabled via memcached, comparing WordPress 6.6 with WordPress 6.5.5 (the latest version of WP 6.5 available when 6.6 was released).
Performance metrics were collected from 100 runs for both Core Web Vitals (CWV) and Server-Timing headers provided by the Performance Lab plugin using CLI scripts from the WPP Research repo.
Benchmark Data
The report data is summarized in this document.
Full report data is below:
- Twenty Twenty-One – a Classic Theme
- Twenty Twenty-Four – a Block Theme
Follow up from this release
- An issue was opened to investigate where the regressions may have come from. Current investigations point to a couple of possible regression points:
- r57920: Options, Meta APIs: Use more sensible default for autoloading options.
- r58264: Block Themes: Add section styling via extended block style variations – which is being worked on in core.trac.wordpress.org/ticket/61451.
- The performance team is working to improve our performance testing tools consistency and robustness, including a roadmap for performance testing next steps.
- Performance Labs – the plugin(s) we use to test out new performance features for core – continues to add new features such as Image Prioritizer , Embed Optimizer, Speculative Loading, Performant Translations and Modern Image Formats (added AVIF and picture element support), and Enhanced Responsive Images.
- Work on better alignment between test methodologies for Core and Gutenberg.
Thanks to @westonruter, @joemcgill and @annezazu and @spacedmonkey for contributing to this post.
