WordPress 6.7 Performance Improvements
This post is the latest in a series of updates focused on the performance improvements of major releases (see 6.6, 6.5, 6.4, 6.3, and 6.2).
WordPress 6.7, “Rollins” is the last major version of WordPress released in 2024. This release delivers important performance updates, including faster pattern loading, optimized previews in the data views component, improved PHP 8+ support and removal of deprecated code, auto sizes for lazy-loaded images, and more efficient tag processing in the HTML API.
Explore the WordPress 6.7 Field Guide. Learn about the changes in this release with detailed developer notes.
Further details on the methodology behind these measurements are provided later in this article, along with an explanation of possible regression sources.
Key improvements
Media: Auto sizes for lazy loaded images
In #61847, support was added for sizes=”auto” for lazy-loaded images. This feature, which was recently added to the HTML specification, allows the browser to use the rendered layout width of the image when selecting a source from the srcset list, since lazy loaded images don’t load until after the layout is known. It maintains backward compatibility while boosting performance, particularly for responsive and dynamic layouts. Explore the details in the official dev note.
Media: Caching _wp_image_editor_choose results for improved performance
In #61532, WordPress now caches the results of _wp_image_editor_choose, storing the WP_Image_Editor implementation that supports queried options. This avoids redundant and costly compatibility checks, such as multiple calls to WP_Image_Editor_Imagick::supports_mime_type(), often triggered during tasks like setting up wp_plupload_default_settings(). The cache, stored for one day, speeds up editor loading times and introduces a new global caching group, image_editor, to manage future optimizations for image editor performance.
Media: Improve speed of AVIF image generation
In #61758, the change results in the AVIF encoder working faster by raising heic:speed to 7 from the default of 5. AVIF generation time is reduced by up to 20% with minimal impact on image size.
Editor: New block type registration APIs to improve performance
In #62002, new block type registration APIs were introduced, offering a more efficient way to manage block metadata and improve performance across the board. These APIs allow developers to register blocks more flexibly, reducing server-side processing and enhancing editor load times. With these changes, WordPress lays the groundwork for faster, more scalable block-based experiences while maintaining backward compatibility. Explore the details in the official dev note.
Editor: Caching Global Styles for Blocks
In #59595, profiling WordPress 6.4 revealed that the WP_Theme_JSON::compute_style_properties method could account for 6-11% of server time during page generation. To address this, the editor now caches the generated CSS for block nodes derived from merged Theme JSON data. By saving the computed styles in a transient, WordPress avoids repeated and resource-intensive operations, significantly improving performance and reducing server load. This change is a key optimization for sites leveraging block themes and theme.json.
Themes: Improve performance of applying background image styles in theme.json.
In #61858, the cost of using WP_Theme_JSON::get_block_nodes() for this in its original shape was high enough to lead to a performance regression. Therefore this changeset introduces a new option on the method that allows to bypass all logic except for retrieving the node paths, which is much faster and everything that this functionality needs.
Miscellaneous Editor improvements:
In addition to the previously listed editor improvements, this release includes the following list of changes that improves the editor experience itself:
- Reusable blocks: fix performance of __experimentalGetAllowedPatterns (helps when there are thousands of patterns).
- Performance: Fetch permissions for visible patterns only
- DataViews: Optimize the templates dataviews by extracting the fields definition & DataViews: Optimize the patterns dataviews by extracting the fields definition (not sold on these based on the PR descriptions).
- Section Styles: improve performance and conceptual consistency
Additional performance focused changes
In total, there were 23 performance related improvements included in this release, split evenly between new enhancements (12) and bug fixes (11).
Performance metrics
In our analysis, block themes (Twenty Twenty-Four was tested) experienced a modest regression in performance. The median Largest Contentful Pain (LCP) time increased by ~6ms or ~3.5% in tests, and the median Time To First Byte (TTFB) shows a 2ms (2%) regression.
Classic themes show a slight improvement (Twenty Twenty-One was tested). The median Largest Contentful Pain (LCP) and Time To First Byte (TTFB) time shows a slight 0.2ms or 0.2% improvement in tests.
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 from the homepage of the Twenty Twenty-one, Twenty Twenty-three, and Twenty Twenty-four themes, comparing WordPress 6.7 with WordPress 6.6.2 (the latest version of WP 6.6 available when 6.7 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
- Twenty Twenty-one
- Twenty Twenty-three
- Twenty Twenty-four
Follow up from this release
WordPress 6.7 shows a regression in performance. While some overhead typically accompanies new features, these declines point to areas where the performance team continues to investigate where these regressions came from and how they can be addressed in the upcoming releases.
Each release, the Performance Team looks for opportunities to improve the performance of WordPress for the following releases, which includes identifying ways we can improve the tooling and processes we use to support the performance practice. For example, we’re collecting opportunities to improve our performance testing in this GitHub issue.
Performance Lab – 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, Modern Image Formats, Enhanced Responsive Images, and Web Worker Offloading.
You can also follow progress on other performance-related work being planned for the WordPress 6.8 release in Trac. A full list of the Performance Team’s priorities for the year is available on the 2024 Roadmap page. Additionally, the 2025 Roadmap will be published early in Q1 2025 in the team’s handbook. Come join us in making WordPress as performant as possible.
Props to @joemcgill, @flixos90, @westonruter, and @fabiankaegy for contributing to this post.
