I had a client last week—big WooCommerce store, about 15k products—complaining that their Largest Contentful Paint (LCP) scores were “in the red” despite using every “speed booster” plugin under the sun. They’d spent a fortune on licensing, but the site was a mess of broken CSS and layout shifts. Total nightmare. They were trying to solve deep, core-level architectural issues with expensive band-aids.
The reality is that WordPress performance optimization isn’t just about ticking boxes in a dashboard. It’s about understanding how the core engine handles resources. I was looking through the recent performance chat summary over at the official Make WordPress blog, and it’s clear the core team is still battling the same gremlins we see in the field. Specifically, the fallout from how separate block styles are loaded on demand—a feature that’s been tricky since WordPress 6.9.
Why Your CSS Strategy Might Be Tanking Your LCP
I’ll admit, when block styles first started getting decoupled, my first instinct was to just dequeue everything. I thought I’d be smart and bundle a single minified CSS file for the whole site. And yeah, it worked… for about five minutes. As soon as the client’s marketing team added a new Gutenberg block I hadn’t accounted for, the layout collapsed. Not good. The real trick is working with the core style engine, not against it.
In the latest dev updates, Weston Ruter is still refining PR #10601 to fix these exact separate block style issues. The goal is to load only what’s needed without triggering the “Flicker of Unstyled Content” (FOUC) or bloating the header. If you’re trying to optimize a site manually, you should be looking at how you register and enqueue styles for custom blocks to ensure they aren’t loading globally.
/**
* Proper way to register block-specific styles to avoid global bloat.
* Prefixing with bbioon to stay clean.
*/
function bbioon_register_optimized_block_styles() {
if ( ! function_exists( 'wp_enqueue_block_style' ) ) {
return;
}
// Only load this CSS when the specific core/quote block is used.
wp_enqueue_block_style( 'core/quote', array(
'handle' => 'bbioon-quote-styles',
'src' => get_template_directory_uri() . '/assets/css/blocks/quote.css',
'path' => get_template_directory() . '/assets/css/blocks/quote.css',
) );
}
add_action( 'init', 'bbioon_register_optimized_block_styles' );New Tools in the Performance Arsenal
One huge takeaway from the recent chat is that Safari finally supports measuring the LCP metric. For the longest time, we were basically flying blind when it came to Apple users. With this capability, the “Optimization Detective” tool is going to get a lot more accurate. This means we can finally stop guessing how half of our mobile traffic is experiencing the site and start making data-driven decisions on WordPress performance optimization.
Another thing that caught my eye was the discussion on Compression Dictionaries. It sounds like high-level server talk, but it’s actually something that can be implemented in PHP with relatively low effort. It allows for much more aggressive compression of HTML, which is a game-changer for massive WooCommerce archives that tend to have heavy DOM trees. Trust me on this, once this hits core or the Performance Lab plugin, you’ll want it enabled.
The Bottom Line
Performance isn’t a “set and forget” thing. Between the sunsetting of the Web Worker Offloading plugin and the upcoming 2026 roadmap, the goalposts are always moving. If you’re still relying on a “one-click” optimization plugin to do the heavy lifting, you’re likely leaving money on the table—or worse, breaking your site for a subset of users you aren’t even tracking.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
Are you seeing weird LCP shifts on your mobile Safari traffic lately?
Leave a Reply