-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exploration on how to refactor per-block styles #25118
Closed
Closed
+498
−62
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
Related to performance efforts
[Feature] Themes
Questions or issues with incorporating or styling blocks in a theme.
labels
Sep 11, 2020
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
Labels
[Feature] Themes
Questions or issues with incorporating or styling blocks in a theme.
[Type] Performance
Related to performance efforts
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_Styles
class.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_block
so 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/cover
block 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 anid
to 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 theinline
method.dependencies
argument likewp_enqueue_style
has, 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-styles
theme-support.How to test
To test the different modes of operation, you can try the following:
try/styles-loading-refactor
branchnpm run build
wp-content/mu-plugins
):You can test all the different loading methods by changing the value from
footer
to any of the available methods.Notes
Editor Styles