[wp-trac] [WordPress Trac] #56990: Render blocking CSS `classic-themes.css` unnecessarily enqueued

WordPress Trac noreply at wordpress.org
Thu Nov 3 22:21:14 UTC 2022


#56990: Render blocking CSS `classic-themes.css` unnecessarily enqueued
------------------------------+-------------------------
 Reporter:  adamsilverstein   |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  6.1.1
Component:  General           |    Version:  6.1
 Severity:  normal            |   Keywords:  needs-patch
  Focuses:  css, performance  |
------------------------------+-------------------------
 Since WordPress 6.1, a new CSS file
 [https://github.com/WordPress/WordPress/blob/master/wp-includes/css
 /classic-themes.css classic-themes.css] is now enqueued on all pages on
 the front end of non-block themes.

 This stylesheet seems to only include styles related to the `wp-block-
 button__link` class and the stylesheet is added regardless of whether a
 block button is used on the page. Although the file itself is tiny, the
 cumulative impact of every WordPress site using a non-block theme is huge
 and no explanation is given in the doc block as to why the style is
 needed.

 This change was originally added in
 https://github.com/WordPress/gutenberg/pull/44731 and ported over to core.
 Even in
 [https://github.com/WordPress/gutenberg/pull/44731#pullrequestreview-1133944306
 this comment] though, the front end view already looks fine, so it is
 unclear why the style needs to be added manually here. The original
 Gutenberg patch only enqueued the styles in the editor, so it is unclear
 why styles were added to the front end in
 this commit:
 https://github.com/WordPress/WordPress/commit/bbb40de012670768a525193639c0d5e4ea932df7.

 In my testing, removing the style had no front end impact, the button
 looked exactly the same before and after I removed the stylesheet. The
 button is already styled from `blocks.css`.

 This stylesheet adds an unnecessary render blocking stylesheet with a huge
 cumulative impact on WordPress sites. I suggest we remove it.

 Worth noting that this enqueue was added during RC, probably something we
 avoid doing if we hope to avoid performance regressions. Also points to
 the need for better performance metrics, even something as simple as
 catching new front end enqueues could be useful here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56990>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list