WordPress performance: fixing the fetchpriority logic

The WordPress Core Performance team has spent months trying to automate LCP (Largest Contentful Paint) work so site owners never have to think about it. The latest WordPress Performance Optimization chat shows where that runs into trouble. A browser hint like fetchpriority only helps when the logic behind it picks the right image.

The fetchpriority=”high” problem in Core

Most of the March 10th chat went to Ticket #64823. Core was handing fetchpriority="high" to images sitting inside hidden Gutenberg blocks, navigation overlays being the obvious case. Tell the browser an image is high priority when it is not even in the first viewport, and it spends bandwidth there instead of on the actual LCP element.

I have hit this on client sites: a hero image fighting a hidden mobile menu image that Core marked high priority, and an LCP score that made no sense until I read the markup. A patch is under review now to tighten wp_get_loading_optimization_attributes() and wp_maybe_add_fetchpriority_high_attr().

// The naive approach: Add high priority to the first image found
// The fixed approach: Ensure the image isn't hidden by block logic
function bbioon_refine_priority_logic( $attrs, $tag_name, $context ) {
    if ( 'IMG' === $tag_name && isset( $attrs['fetchpriority'] ) ) {
        // Additional checks for block-specific hidden states
        if ( bbioon_is_image_hidden_in_block( $context ) ) {
            $attrs['fetchpriority'] = 'auto'; // Downgrade to default
        }
    }
    return $attrs;
}
add_filter( 'wp_get_loading_optimization_attributes', 'bbioon_refine_priority_logic', 10, 3 );

Why the web worker offloading experiment is ending

Over in the Performance Lab plugin, the team is sunsetting the “Web Worker Offloading” feature. It used Partytown to push heavy third-party scripts, Google Analytics being the usual suspect, onto a web worker so the main thread stayed free.

The idea holds up right until something breaks, and then you are reading partytown source to work out why. Weston Ruter pointed out that the version carrying the sunset warning has gone out in more than 6,000 updates with zero user feedback, which means either nobody was running it or they had already switched to steadier WordPress Performance Optimization methods.

For query-heavy sites, I covered the backend side in Critical WordPress Performance Updates: The WP_Query Shift. Those bottlenecks sit well below anything fetchpriority can reach.

If WordPress performance work is eating your week, I can take it on. I have been working with WordPress since the 4.x days.

Where this leaves you

An attribute only counts as an optimization when Core puts it on the right element, and block markup makes that harder to get right than it used to be. Weston Ruter is traveling for the next two weeks, so Core Performance news will be quiet, but PR #11196 is the one to watch for the fetchpriority fix.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.