This post is the latest in a series of updates focused on the performance improvements of major releases (see 6.7, 6.6, 6.5, 6.4, 6.3, and 6.2).
WordPress 6.8, “Cecil” is the first and likely only major version WordPress released in 2025. It includes numerous significant performance improvements to the editing and browsing experience, spearheaded by the speculative loading feature. The release pays special attention to performance in the 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. editor, frontend interactivity, block type registration, and query caching.
This post summarizes the performance changes since the 6.7 release, both in terms of enhancements and concrete metrics. For a comprehensive overview of new features and enhancements beyond just performance, please explore the WordPress 6.8 Field Guide.
Key improvements
In total, there were 24 performance related improvements included in this release: 1 feature, 14 enhancements, and 9 bug 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. This section summarizes a few highlights among them.
Speculative loading for near-instance page loads
In #62503, the speculative loading feature was added. It can notably improve the Largest Contentful Paint (LCP) performance and, depending on the configuration, lead to truly instant page loads. To accomplish this, the feature uses the Speculation Rules API, a web platform API 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. that allows defining rules for which kinds of URLs to prefetch or prerender, and how eagerly speculative loading should occur. By default, URLs are prefetched when the user interacts with a link to them (“conservative” eagerness). For an additional performance boost, up to the instant page loads, the configuration can be adjusted through filters or by using the canonical Speculative Loading plugin.
Please refer to the Speculative Loading dev note for details on the feature’s behavior and how to customize it.
Asynchronous Interactivity API event listeners by default for smoother interactions
In Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ issue #64944, the foundation was set for asynchronous event listeners by default for the Interactivity API. Running event listener logic asynchronously helps avoid long tasks in the browser, which can notably improve the Interaction to Next Paint (INP) performance and thus ensure the website responds to user interactions without any delays. WordPress 6.8 does not actually implement this change just yet, but it prepares for the change to launch in a following release by introducing a withSyncEvent() utility function that needs to be used by any Interactivity API store action that is attached to an event and needs to run synchronously.
Please refer to the Interactivity API best practices dev note for details on how to use withSyncEvent() and how to avoid deprecation warnings.
Smarter WP_Query cache key generation for increased cache hit chance
In #59516, the logic around generating a cache key for post queries via WP_Query was improved to increase the chance for a cache hit. In other words, it reduces the need to run SQL queries for queries that are sure to yield the same results even though their query variables may technically differ. In particular, any query variables that expect arrays in which the order of items does not matter are now being normalized prior to generating the cache key.
count_user_posts() caching to avoid potentially slow queries
In #39242, caching was added to the count_user_posts() function to avoid a SQL query that in certain setups could previously occur on every page load. On sites with many registered users, this query can be slow, which is why caching its results can lead to a notable server-side performance boost. While this primarily applies to WP Admin (and super admin), certain themes also call this function, so it can have a notable impact on the website’s frontend performance as well.
get_option() performance 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. from WordPress 6.4 identified and addressed
In #62692, a performance regression due to a problem introduced in WordPress 6.4 in the get_option() function was identified and fixed. The lookup of a non-existent option was leading to an unnecessary wp_cache_get() call that would always evaluate to false. For large WordPress sites, this could significantly increase the load on caching servers. The fix ensures the unnecessary wp_cache_get() call no longer happens, leading to a constant number of wp_cache_get() calls per non-existent option, even if it is requested many times.
Performance metrics
The performance benchmarks for the WordPress 6.8 release show a small regression in both server-side performance and client-side performance across block themes and classic themes.
The median Largest Contentful Paint (LCP) time, which is the metric most representative of the overall performance, increased by 3.40 ms (1.76%) for Twenty Twenty-One, 2.65 ms (1.92%) for Twenty Twenty-Three, and 10.05 ms (1.73%) for Twenty Twenty-Five. The increased time signifies a decrease in performance, albeit a small one.
While it is natural that every new feature or enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. can incur a performance cost, ideally the regression needs to be investigated for whether there is a specific change that is primarily responsible for it or whether it is simply due to the accumulation of several new features and enhancements with a minor performance cost. At first glance, it might be the latter because a similar degree of regression can be noted more or less across all metrics.
It is worth noting that the performance metrics do not benefit from the new speculative loading feature, since it only helps with performance when navigating from one URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org of the site to another URL of the site. Because the benchmarks rely on individual requests to specific URLs though, speculative loading does not trigger. In other words, it is fair to assume that the actual performance impact of WordPress 6.8 for users navigating through a WordPress site is more positive than the benchmarks indicate.
How release performance is measured
The performance measurements used for the overview are based on benchmarks conducted using an automated workflow on GitHub 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-Five themes, comparing WordPress 6.8-RC3 with WordPress 6.7.2, which was the latest version of 6.7 available as of the 6.8 release.
Under the hood, the automated workflow collects performance metrics from 100 runs for both Web Vitals and Server Timing metrics using CLI scripts from the WPP Research repo.
Full benchmark data
- Twenty Twenty-One:
- Twenty Twenty-Three:
- Twenty Twenty-Five:
What’s next?
Once WordPress 6.8 has been used for at least a month, additional research should be conducted to assess its performance impact in the field by using CrUX data. This will clarify to what extent the regression shown by the benchmarks is an actual reason to worry or not. Additionally, the performance impact of the speculative loading feature should be assessed as part of that, to see how much it influences LCP in practice.
Other than that, the focus of the Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team remains to iterate on the performance of WordPress by identifying areas of improvement and addressing them. With the reduced major release cadence following the 6.8 release, it may be even more important to focus on all the little things that can be done to improve performance—they add up. Minor releases will continue to ship as necessary, and as mentioned in the linked post there will be a more relaxed barrier for inclusion of enhancements. In other words, WordPress Core continues to provide lots of opportunities for improving its performance.
Props @joemcgill for review and proofreading.
#6-8, #core, #core-performance, #performance
