I have read enough core chat logs to know that most of the interesting changes land in the unglamorous parts of the codebase. The January 2026 chat on WordPress Performance Optimization is a good example. Nothing flashy came out of it, but if you run high-traffic sites, speculative loading and admin view transitions are both worth watching as WordPress 7.0 gets closer.
Moving the default to “moderate” eagerness
Most of that discussion sat on Trac #64066, which proposes changing Speculative Loading’s default eagerness from conservative to moderate when server-side caching is detected.
Moderate eagerness means the browser starts prerendering a link when the user hovers over it, instead of waiting for a more definitive signal. That helps Largest Contentful Paint (LCP), and it can also spike server load if your caching layer is not airtight. You are buying perceived front-end speed with back-end resources.
If you are already running these features, my earlier write-up on solving WordPress admin performance with view transitions covers more of the background.
Overriding eagerness with a filter
Hosting environments differ, so you will sometimes want to override the default for a particular client. This sets the eagerness level in code:
<?php
/**
* Adjust Speculative Loading eagerness based on environment.
* Prefix: bbioon_
*/
add_filter( 'wp_speculative_loading_configuration', 'bbioon_adjust_speculative_eagerness' );
function bbioon_adjust_speculative_eagerness( $config ) {
// If we're on a low-resource server, keep it conservative
if ( defined( 'WP_LOW_RESOURCE_ENV' ) && WP_LOW_RESOURCE_ENV ) {
$config['eagerness'] = 'conservative';
} else {
$config['eagerness'] = 'moderate';
}
return $config;
}
Admin view transitions and the E2E test failures
There were also updates on Trac #64470, which aims to bring cross-document View Transitions to the WordPress admin. That would make the dashboard feel closer to a single page application (SPA) without refactoring the whole thing onto a JS framework.
The PR (#10699) is stuck on unexpected end-to-end (E2E) test failures. I have been there: the unminified scripts look fine and the automated runner still disagrees. The plan is to keep debugging with unminified scripts to work out whether the failure is a race condition or an asset loading bottleneck. That kind of detail is why WordPress Performance Optimization work takes so long to land in core.
Modern image formats are still messy
Weston Ruter also raised issues with Modern Image Formats in core (#60480). AVIF and WebP have been pushed for a while, but the media library implementation still has rough spots. Legacy themes that do not handle modern srcset logic can end up with broken layouts after a core update, so test your media output filters against the 7.0 betas.
If this WordPress performance work is eating your dev hours, hand it over to me. I have been wrestling with WordPress since the 4.x days.
What this means for WordPress 7.0
WordCamp Asia 2026 lines up with the WordPress 7.0 release, and the direction is a faster, more app-like core. Speculative Loading gets more aggressive and View Transitions clean up the admin, with Performance Lab still acting as the staging ground before any of it reaches most sites. If you are running the betas, keep an eye on your server transients and cache hit ratios.
