A client came to me last week with a big WooCommerce store, roughly 15k products, complaining that their Largest Contentful Paint (LCP) scores were “in the red” despite running every speed booster plugin on the market. They had spent a fortune on licensing and still had broken CSS and layout shifts all over the site. They were paying for expensive band-aids over problems that sat in the architecture.
WordPress performance optimization is not a matter of ticking boxes in a dashboard. It comes down to how the core engine handles resources. Reading the recent performance chat summary on the official Make WordPress blog, the core team is clearly still fighting the same gremlins the rest of us hit in client work, particularly the fallout from loading separate block styles on demand. That one has been awkward since WordPress 6.9.
How your CSS strategy tanks your LCP
When block styles first got decoupled, my instinct was to dequeue the lot and ship one minified CSS file for the whole site. That worked for about five minutes. The client’s marketing team added a Gutenberg block I had not accounted for and the layout collapsed. The trick is to work with the core style engine instead of around it.
In the latest dev updates, Weston Ruter is still refining PR #10601 to fix these separate block style issues. The goal is to load only what a page needs without causing a “Flicker of Unstyled Content” (FOUC) or bloating the header. If you are optimizing a site by hand, start with how you register and enqueue styles for custom blocks so they are not 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 measurement tools
Safari can finally measure LCP. Until now we were flying blind on Apple users, so the “Optimization Detective” tool is about to get a lot more accurate. That is the difference between guessing what mobile visitors experience and actually knowing, and knowing is where any serious WordPress performance optimization work starts.
The discussion on Compression Dictionaries also caught my eye. It sounds like server-team territory, but it can be implemented in PHP without much effort, and it allows far more aggressive compression of HTML. That matters on massive WooCommerce archives with heavy DOM trees. Once it reaches core or the Performance Lab plugin, turn it on.
Where that leaves you
Performance is not a set and forget job. Between the sunsetting of the Web Worker Offloading plugin and the 2026 roadmap, the goalposts keep moving. If a one-click optimization plugin is doing all of your tuning, you are probably losing sales, or quietly breaking the site for a group of users you are not even tracking.
This gets complicated fast. If you would rather not debug someone else’s mess and just want the site to work, drop my team a line. We have probably seen it before.
Are you seeing odd LCP shifts on your mobile Safari traffic lately?
