[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