WordPress 6.x and the Performance Lab plugin are pushing the boundaries of how we handle responsive images. I’ve been following the latest discussions around the Auto Sizes feature, and frankly, it’s about time we addressed the sizes attribute bottleneck. During the recent chat on April 21, 2026, the team laid out a roadmap that is critical for anyone serious about WordPress Core Performance.
The Problem with Static Image Sizes
For years, we’ve relied on WordPress to generate the sizes attribute based on a set of breakpoints. It worked, but it was never truly accurate. Specifically, when you have complex layouts like the Gallery block, the browser often downloads a much larger image than necessary because the sizes attribute doesn’t reflect the actual render size. This is a massive hit to your LCP (Largest Contentful Paint) and overall WordPress Core Performance.
Weston Ruter and the performance team are now prioritizing the “Auto Sizes” feature. However, as with any major shift in the core API, it isn’t without its war stories. We’ve seen issues where images in galleries appear skewed or distorted when sizes="auto" is applied without proper aspect ratio handling. Specifically, GitHub issue #2449 outlines the next steps to resolve these Gallery block quirks before this can be proposed for WordPress Core.
If you’ve been struggling with similar issues, you might want to check out my previous guide on fixing Fetchpriority logic to further optimize your asset loading.
Refactoring for WordPress Core Performance
When the Performance Lab plugin experiments with these features, it’s our job as developers to ensure our custom themes don’t break. A common mistake I see is developers trying to force-fix the sizes attribute by regexing the the_content filter. That is a race condition waiting to happen and a nightmare for server-side transients.
Instead, we should be using the correct hooks to manipulate how WordPress calculates responsive image attributes. Here is a safer approach to ensuring your images play nice with modern performance standards:
<?php
/**
* Adjusting image sizes attributes for better WordPress Core Performance.
*/
function bbioon_optimize_gallery_auto_sizes( $sizes, $size, $image_src, $image_meta, $attachment_id ) {
// Only apply logic if we are on the frontend and not in the admin
if ( is_admin() ) {
return $sizes;
}
// Example logic to ensure 'auto' is included for lazy-loaded images
// This aligns with the roadmap discussed in the performance chat.
if ( false !== strpos( $sizes, '100vw' ) ) {
return 'auto, ' . $sizes;
}
return $sizes;
}
add_filter( 'wp_calculate_image_sizes', 'bbioon_optimize_gallery_auto_sizes', 10, 5 );
Why the Gallery Block is the Final Boss
The chat highlighted that resolving the sizes issue for the Gallery block is the “final boss” standing in the way of a core merge. Because galleries use CSS grid or flexbox, the browser cannot predict the image width until the CSS is fully parsed. By moving toward sizes="auto", we allow the browser to determine the size at runtime, but we must ensure the aspect-ratio is preserved to prevent layout shifts (CLS).
Furthermore, contributors like Mukesh and Ravi are actively looking for testers. If you’re running a high-traffic site, now is the time to spin up a staging environment and test the latest Performance Lab updates. We need to move away from legacy hacks and embrace these native browser features.
Look, if this WordPress Core Performance stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Road Ahead
The next performance chat is scheduled for May 5, 2026. Specifically, the focus will remain on stabilizing the “Enhanced Responsive Images” module. If we can nail the Gallery block implementation, we are looking at a significantly faster web for every WordPress user. For now, keep your transients clean and your hooks precise. I’ll see you in the Slack logs.
“},excerpt:{raw:
