WordPress 6.8 performance improvements
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 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.
class=”wp-block-heading”>Key improvements
In total, there were 24 performance related improvements included in this release: 1 feature, 14 enhancements, and 9 bug 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 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 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, 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 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 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 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 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 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.
