WordPress 6.9 Performance Landings

WordPress 6.9 includes so many performance improvements! Scripts with fetchpriority, increased inline CSS, minified theme styles, on demand block styles in classic themes, the template enhancement output buffer, and much more! Check out the field guide I just published:

WordPress 6.9 Frontend Performance Field Guide

There were many contributors from the Core Performance Team involved in making this possible. Personally, this is a culmination of a year of work, including a bunch of research and development I wrote about previously and spoke about at WordCamp US:

The Site Speed Frontier with Performance Lab and Beyond

I’ve been working nights and weekends (and days) to help make sure all of this lands in time for the December 2nd release. This is evident from looking at the “A Month in Core” post for October! It has been fun—feeling like the good ol’ contribution days when I was deep in the Customizer up through WordPress 4.9 (2013–2017). But I’m really looking forward to being able to unwind for the holidays.

I hope your sites get a great speed boost for Christmas! 🎄

Where I’ve shared the field guide:

performance

Comments

5 responses to “WordPress 6.9 Performance Landings”

March 20, 2026

Chris Brailsford

Hey Weston! I was adding some custom block stylesheets to override core block styles in a Classic theme. Although you mentioned that loading separate stylesheets is now opt-in by default, I noticed the override stylesheets I added with wp_enqueue_block_style still output, even if the block is not on the page. The only way I can make it work as I anticipated is by setting add_filter( ‘should_load_separate_core_block_assets’, ‘__return_true’ );

I’ve included a sample bit of code as a Gist here: https://gist.github.com/cabrailsford/c7b9bcce83edb05838854bfebd0d191a

Is that necessary, or am I possibly missing something else here?

Reply
1. March 20, 2026
  
  Weston Ruter
  
  Hey! I’m at the CloudFest Hackathon the next few days, so won’t be able to investigate this much. But loading separate block styles on demand is actually the default. It was previously the case for block themes, and in 6.9 it was made the default in classic themes as well. Are you able to reproduce this issue in a fresh install with either Twenty Twenty-One (a classic theme) or Twenty Twenty-Five (a block theme), and no other plugins active other than your sample code active?
  
  Reply
  1. March 20, 2026
    
    Chris Brailsford
    
    Hey Weston! Thanks for taking the time to reply, and I hope CloudFest Hackathon is a good time!
    
    I went and tested the code in both Twenty Twenty-One and Twenty Twenty-Five with no other plugins active. The classic theme is where the custom style overrides still output (though not the default block styles) even if the block is no longer on the page (without forcibly setting the filter to true). I am currently running 7.0.5 beta, in case that makes any difference. Thanks!
    
    Reply
    1. March 20, 2026
      
      Weston Ruter
      
      Ah, I see you are enqueueing at after_setup_theme. This is too early. The earliest that you shoes be doing any style registration is at the init action. The situation is improved by https://core.trac.wordpress.org/ticket/64846 but only when enqueueing at an early init priority. Just switch to enqueueing at init and that should fix the problem.
      
      Reply
      1. March 21, 2026
        
        Chris Brailsford
        
        It looks like using the init hook worked! Funny enough, I was using it prior to 6.9, but then things broke (for a different reason), so I switched to ‘after_setup_theme’, which seemed to resolve the problem at that time. Also, it’s interesting that most of the top articles I can find when searching for the enqueue block style function all use ‘after_setup_theme’ instead of ‘init’, though they ARE a bit older/prior to 6.9’s release.

Weston Ruter

WordPress 6.9 Performance Landings

Comments

5 responses to “WordPress 6.9 Performance Landings”