I’ve spent enough nights debugging race conditions to know that “instant” usually comes with a catch. We often chase the latest trends in WordPress Performance Optimization, but the recent core chat for January 2026 proves that the real work is happening in the deep, unsexy parts of the codebase. If you’re managing high-traffic sites, you need to pay attention to how Speculative Loading and Admin View Transitions are evolving as we head toward WordPress 7.0.
The Shift to “Moderate” Speculative Loading
One of the most impactful discussions revolved around Trac #64066. The proposal is to change Speculative Loading’s default eagerness from conservative to moderate specifically when server-side caching is detected.
For the uninitiated, “Moderate” eagerness means the browser starts prerendering links when a user hovers over them, rather than waiting for a more definitive signal. While this significantly improves Largest Contentful Paint (LCP), it can also spike server load if your caching layer isn’t airtight. It’s a classic trade-off: front-end perceived speed versus back-end resource consumption.
If you’re already implementing these features, you might find my previous deep dive on solving WordPress admin performance with view transitions useful for context.
Controlling Eagerness via Filter
In many cases, you’ll want to override the default behavior based on the specific needs of your client’s hosting environment. Here is how you might refactor the eagerness level programmatically:
<?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 “Gotcha”
We also saw updates on Trac #64470, which aims to bring cross-document View Transitions to the WordPress Admin. This is a massive win for the user experience, making the dashboard feel like a modern Single Page Application (SPA) without the overhead of a full JS framework refactor.
However, the PR (#10699) is currently hitting a wall with unexpected end-to-end (E2E) test failures. As a dev, I’ve been there—everything looks solid in the unminified scripts, but the automated runner disagrees. The plan is to debug further with unminified scripts to isolate whether the failure is a race condition or an asset loading bottleneck. This level of technical precision is exactly why WordPress Performance Optimization at the core level takes time to land.
Modern Image Formats: Still Messy
Weston Ruter also highlighted issues with Modern Image Formats in core (#60480). Despite the push for AVIF and WebP, the implementation details in the media library still have some sharp edges. When you’re dealing with legacy themes that don’t support modern srcset logic, these core updates can occasionally break layouts. Always test your media output filters when updating to the latest 7.0 betas.
Look, if this WordPress Performance Optimization stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Takeaway for WordPress 7.0
With WordCamp Asia 2026 lining up with the WordPress 7.0 release, it’s clear the focus is on a faster, more “app-like” core experience. Between Speculative Loading becoming more aggressive and View Transitions cleaning up the admin UX, the platform is shedding its “slow” reputation. Furthermore, the work on Performance Lab continues to act as the staging ground for these features before they hit the masses. Ship your code, but keep a close eye on your server transients and cache hit ratios—things are about to get a lot faster.
