Opened 2 months ago
Last modified 6 weeks ago
#61965 assigned enhancement
Provide a way for classic themes to use `wp-block-library` even when loading block assets only for blocks that actually render on a page
Reported by: | fabiankaegy | Owned by: | flixos90 |
---|---|---|---|
Milestone: | 6.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
This ticket is coming out of a [Discussion in the Make WordPress Slack](https://wordpress.slack.com/archives/C02QB2JS7/p1724866722880979). And it it tangentially related to #61958
As it stands today, classic themes load all the stylesheets of any blocks regardless of whether they are used on the page or not. This is partially due to the fact that for a long time the core blocks all had their styles bundled into one wp-block-library
stylesheet.
In order to change this behavior for core blocks a new flag wp_should_load_separate_core_block_assets
was introduced which is enabled by default for block based themes. When this flag is enabled, core will no longer load the wp-block-library
stylesheet but rather load individual stylesheets for only the blocks that are rendered on the page. Using the should_load_separate_core_block_assets
filter classic themes can also opt into this behavior which does in theory solve this problem.
However I am proposing that we add an additional flag that would allow classic themes to opt into the conditional loading of stylesheets without opting into the wp-block-library
change.
The reasons why I think this is important is that the refactor existing sites have to go through to move their large CSS codebases over to no longer depend on the loading order / specificity implications of having the wp-block-library
CSS is a major effort. So it is going to take time for those sites to move over to having block specific stylesheets.
In the meantime it would already be an arguably even larger performance improvement for these sites to no longer load the separate stylesheets of blocks we already have when they are not needed on the current page.
Third party blocks often have much larger CSS files associated with them. Because they might for example load an entire Maps library, or other really large features.
Change History (5)
#2
@
2 months ago
@fabiankaegy Thank you for opening the ticket.
Based on reading the ticket description and our previous conversation on Slack, I wonder whether this would be more clear if phrased differently:
- The ticket title/summary is currently describing something that's already possible today, via
wp_should_load_separate_core_block_assets()
. - I believe what you're proposing though is more about being able to opt in or opt out of using individual core block stylesheets (vs using the one
wp-block-library
stylesheet), independently of whether block assets are loaded on demand or not. - Related to #61958, I think this conversation is confusing because
wp_should_load_separate_core_block_assets()
does not what its name indicates. Today it is responsible for opting in to load block assets on demand (rather than everywhere unconditionally). By doing that it also opts in to using individual core block stylesheets instead ofwp-block-library
. So as far as I understand, you'd like to be able to control the latter separately.
Did I get that right?
#3
@
2 months ago
@flixos90 That is correct 👍 Thank you for summarizing it in a much better way.
It really comes down to decoupling the wp-block-library
from the independant loading of block stylesheets for third party blocks.
#4
@
2 months ago
- Summary changed from Provide a way for classic themes to opt into only loading styles for 3rd party blocks that actually render on a page to Provide a way for classic themes to use `wp-block-library` even when loading block assets only for blocks that actually render on a page
@fabiankaegy Thanks for confirming. I'll rename the ticket to clarify.
A potential solution for this could be (I'm not going to talk about function names so that we can focus on the solution only):
- There's a function (and filter) "A" that controls whether to load block assets on demand (we already have that today).
- There could be another function (and filter) "B" that controls whether to use individual core block stylesheets instead of
wp-block-library
.- While today's function name sounds like it would do that, that's not actually its primary purpose (see #61958).
- Function "B" would by default rely on the output of function "A". In other words: If block assets are loaded on demand, individual core block stylesheets are used. But the filter in "B" could be used to change that, without changing the output of function "A".
- With this kind of setup, everything would work the same way as today by default. The enhancement though would be that you can change the two configurations independently of each other.
The two new possible scenarios that aren't supported in Core today would be:
- Block assets are loaded on demand, but
wp-block-library
is used: In this scenario, whenever any core blocks is encountered, thewp-block-library
stylesheet would be enqueued. - Block assets are loaded unconditionally, but individual core block stylesheets are used: In this scenario, the individual core block stylesheets would simply be enqueued everywhere.
I don't feel strongly about whether or not it's a good idea to support this. Generally, using wp-block-library
is wasteful when it comes to performance (and sustainability). But I acknowledge that lots of third-party code depends on wp-block-library
today and it'll take time to migrate away from that. When in that situation, today you will have to load all block assets everywhere, even third party blocks that have nothing to do with wp-block-library
. Essentially, today Core only allows you to go all in or get none of the benefits of loading on demand. So differentiating between whether to load block assets on demand and whether to use wp-block-library
might be a worthwhile enhancement.
@gziolo @aristath I'd be curious to get your perspective.
CC: @flixos90 since you participated in the conversation in Slack :)