Exploration on how to refactor per-block styles #25118
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: -1 B Total Size: 1.22 MB
ℹ️ View Unchanged
|
|
I'm thinking perhaps all blocks should have an |
This was referenced Sep 10, 2020
aristath
added
[Type] Performance
3 tasks
|
Closing this one in favor of #28358 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is an exploration on how we can make the styles loading more efficient for Gutenberg blocks.
With full-site-editing in the horizon, all styles will basically be block styles.
Currently WordPress prints a monolithic stylesheet containing all styles for all blocks - regardless of whether these are actually used in a page or not.
The goal of this PR is to identify issues and find solutions.
For the purposes of this exploration we add a new
WP_Block_Stylesclass.It implements 4 new ways to add block styles:
inline- Prints styles inline.inline_link- Adds a<link rel="stylesheet">inline.inject- Injects the style in<head>via JS.footer- Adds styles to the footer.All 4 methods are hooked in
render_blockso styles for a block are only added when a block is actually used on a page. All of these block-styles additions only get triggered the 1st time a block-type is encountered.Each method has its pros and cons, and serves a different purpose.
Each block can have multiple styles, and the way these are loaded can be independent.
Block-styles are filterable, so for example if we want to add a new style for the
core/coverblock which will add some styles in the footer, we can add something like this:The arguments in that array are similar to what we use in
wp_enqueue_style(), with a few additions/tweaks. So we have:handle(string): The handle. It's used to add anidto the element added.src(string): The URL of our styles.ver(string): The version of our styles.media(string, optional):all|screen|print. Can also be a media-query. Defaults toall.method(string):inline|inline_link|inject|footer.path(string): This is only really needed if we want to print styles with theinlinemethod.dependenciesargument likewp_enqueue_stylehas, it doesn't make sense to have it in this implementation.Plugins & themes can add/modify the array of styles available for each block-type, and how these get loaded. If a style is extremely small (like for example the paragraph styles), they can be added inline. Other styles (like the cover block) could be added in the footer or injected via JS since they are not critical in most cases, while the column styles will be better inline since they are small & adding them in the footer could cause a layout shift if they get loaded later.
Overall, this gives plugin authors, theme-authors and most of all site-owners the ability to control what gets loaded, when it gets loaded, and the overall performance boost for visitors is significant.
This implementation is hidden behind a
split-block-stylestheme-support.How to test
To test the different modes of operation, you can try the following:
try/styles-loading-refactorbranchnpm run buildwp-content/mu-plugins):You can test all the different loading methods by changing the value from
footerto any of the available methods.Notes
Editor Styles