[wp-trac] [WordPress Trac] #55639: Implement Async CSS

WordPress Trac noreply at wordpress.org
Tue Jun 10 15:50:24 UTC 2025


#55639: Implement Async CSS
-----------------------------+--------------------------------------
 Reporter:  mihaidumitrascu  |       Owner:  (none)
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  javascript, performance
-----------------------------+--------------------------------------
Changes (by westonruter):

 * keywords:  has-patch =>


Comment:

 What about just printing the stylesheet in the footer instead? This would
 avoid the need for JavaScript.

 On my blog, for example, I have a Social Links block in my footer. Because
 of this, there's no need for the large block stylesheet (cf.
 [https://github.com/WordPress/gutenberg/issues/69613 gutenberg#69613 ]) to
 be loaded in the `HEAD` and block rendering. So I'm moving it to the
 footer via:

 {{{#!php
 <?php
 add_action(
         'wp_enqueue_scripts',
         static function () {
                 $handle = 'wp-block-social-links';

                 $style = wp_styles()->query( $handle, 'registered' );
                 if ( ! $style ) {
                         return;
                 }

                 // Prevent inlining.
                 unset( $style->extra['path'] );

                 // Move to footer.
                 $style->add_data( 'group', 1 ); // This doesn't seem to
 work. I need to dequeue and then re-enqueue in the footer.
                 if ( wp_style_is( $style->handle, 'enqueued' ) ) {
                         wp_dequeue_style( $style->handle );
                         add_action( 'wp_footer', function () use ( $style
 ) {
                                 wp_enqueue_style( $style->handle );
                         }, 0 );
                 }
         },
         PHP_INT_MAX
 );
 }}}

 And this fixes the performance problem. Since it is printed at
 `wp_footer`, after which there is content to render (normally) and since
 the footer is far outside the initial viewport (normally) then there
 should be no FOUC.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55639#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list