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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8+ support and removal of deprecated code, auto sizes for lazy-loaded images, and more efficient tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) processing in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..

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 regressionregression 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. 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 blockBlock 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. 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 CSSCSS Cascading Style Sheets. for block nodes derived from merged Theme JSONJSON 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. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Web Vitals (CWV) and Server-Timing headers provided by the Performance Lab pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party using CLI scripts from the WPP Research repo.

Benchmark Data

• Twenty Twenty-one
  • Web Vitals
  • Server-Timing
• Twenty Twenty-three
  • Web Vitals
  • Server-Timing
• Twenty Twenty-four
  • Web Vitals
  • Server-Timing

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.

#6-7, #core, #core-performance, #performance