annezazu 8:51 pm on March 4, 2021
Tags: core-editor ( 402 ), core-editor-improvement ( 10 )

Core Editor Improvement: Need for (page/post) Speed

Thank you to @aristath who helped with this post.

In today’s world, speed matters whether you’re trying to write a post in the editor or load a page as a visitor. Over the last couple of months, a lot has changed around performance to improve both of these aspects, but the changes might have happened so fast you missed them! This post will focus solely on front end performance with a future post in the works that covers performance-related changes to the editor itself. For now, read on to learn just how speedy the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor makes your site and get excited because what’s discussed here is currently available in Gutenberg 10.1!

Updates to front end performance

As most developers know, you can think of front end performance as the type of performance that impacts SEO and the experience visitors have when they check out your site. Lots of things contribute to the performance of your site including various CSSCSS Cascading Style Sheets. styles, JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. files, and more. While your theme and plugins contribute to what needs to be loaded to create the magic of viewing a page or post, the core editor does as well!

With the merging of this PR, CSS styles are only loaded for blocks used on a page, which cuts down the amount of CSS needed and increases performance dramatically. For context, in previous GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ releases, all styles for all blocks were enqueued in a single file causing extra page load. This means that now only what’s necessary is loaded when you’re viewing content!

After the work was done to separate out block styles, an additional PR was merged for Gutenberg 10.1 to improve the performance of these blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. styles. Since most blocks have fairly small stylesheets, it didn’t make sense to send requests to the server for these bite-sized styles. To resolve this, the tiny stylesheets were inlined, further improving the performance by including everything the browser needs in a single request. Think of this as sending one text message covering a few topics, rather than writing a bunch of individual messages one after the other.

Right now, both of the above changes are the default behavior in FSE, but they are opt-in for non-FSE templates to avoid backward-compatibility issues with CSS overrides in older themes. When FSE gets merged into Core, these improvements will be more widely available and make a big difference for all.

Stay tuned for more

As with many performance enhancements, it’s easier to notice when things break compared to when they are running smoothly. Hopefully, this post gave you a behind-the-scenes look into the work that goes into keeping your sites speedy while using the Core Editor. While a lot of work is put into democratizing publishing in the WordPress project, this kind of work helps democratize delivery, allowing people to get the content they want to consume easier and faster. With changes coming to Google Search related to the speed of webpages, performance improvements for both the front end and in the editor have never been more timely.

The work here is never done though so, if you’re interested in working on improving performance, make sure to join #core-editor, check out the current focuses, and attend the Core Editor weekly meeting Wednesday @ 14:00 UTC.

#core-editor, #core-editor-improvement

curtiskessler 1:20 am on March 5, 2021

Only loading blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. styles that are necessary is a fantastic move to improve front end load speed and thus user experience across the board.

Personally I hope to see WordPress pursue this “load only what is necessary” policy across the board. For example, why does WordPress load an emoji support script by default if no emoji has been published on the website? Ideally, WordPress would only enable this if it were actually needed.
- Ari Stathopoulos 7:48 am on March 5, 2021
  
  I’ve actually been discussing the emojis thing with @jonoaldersonwp and the main difficulty there is detecting if there are emojis present in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. or not.
  In FSE the whole page content gets parsed before the , so if we can efficiently and reliably detect whether the page contains emojis or not, then we can conditionally load the script.
Sami Keijonen 8:56 am on March 5, 2021

Is there a documentation (or pointing to source code) how custom blocks can leverage the same technique?

At least for the part loading only blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. styles if the block exist on the page.
- Greg Ziółkowski 1:10 pm on March 5, 2021
  It isn’t documented as it’s still being tested in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. As soon as we start backporting changes to the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., we will include all the necessary information in the documentation.
  
  In practice, it should be very straightforward to integrate:
  - this feature is automatically enabled for FSE themes
  - it can be enabled with a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for other teams
  - blocks that use `register_block_type` to define `style` and `editorStyle` get this optimization by design
  - blocks that use `block.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.` in combination with `register_block_type_from_metadata` get this optimization by design, as well
  - Sami Keijonen 1:16 pm on March 5, 2021
    
    Thanks!
titsmaker 3:35 pm on March 6, 2021

Kudos fot this change!
mrwweb 6:40 pm on March 8, 2021

This is a really neat change, but I do have a question about whether it’s unambiguously good for performance.

By inlining styles, they can no longer be cached. So while the first page load should always be improved by this change, subsequent page loads could be slower/larger. For a site with a very low pages/visit ratio, that is probably a good tradeoff, but for a site with a higher one, it seems like the gains would evaporate after a few pages for a single visit.

I did see that there was a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to adjust this behavior as well, but that wasn’t mentioned in the post. I wonder if there would be any way to detect when sites are better off with a cached file vs. inline styles.

Was caching considered as part of this change? I didn’t see any direct mentions of it on the ticketticket Created for both bug reports and feature development on the bug tracker., but I didn’t dig that deep either. I’d love to understand what considerations were taken and for information about potential tradeoffs to be included in documentation of the feature and filter.
- Ari Stathopoulos 7:34 pm on March 8, 2021
  
  There were a lot of different implementations and concepts before we ended up with this one… And yes, caching was taken into account. I like to think of what we did as AMP without all the hassle of AMP, with a few tweaks to better fit the WP ecosystem. First we do some basic tree-shaking by only adding styles for blocks that are used on the page, then we inline styles. There’s a reason why AMP has a limit for styles size, and that’s because they need to fit in a single request.
  
  The process for deciding whether a stylesheet will get inlined or not goes something like this:
  
  1. Gather all blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. assets and get their size in bytes
  2. Order all assets going from smallest to largest
  3. Start inlining smallest to largest styles, until we hit the 20k limit (or other value if a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. is used to change it).
  
  Larger files benefit from caching, while smaller stylesheets benefit from inlining.
  There is no perfect method for anything, but the above strikes a good balance… It avoids costly extra requests for small assets, while at the same time leaves larger assets alone so they can be cached on the browser ’cause that’s what makes more sense for these files.
  
  Assuming an FSE theme, a simple page with paragraphs, headings, quotes etc will be able to get all styles in a single request. In a single round-trip the browser has the htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. & css it needs and it will be rendered lightning-fast since the small size of all these styles is less than 20k in total.
  If I add cover blocks, galleries etc, then the “simple” block styles will be inlined since they fit nicely in the 1st packet we send with the page contents, while the cover block’s stylesheet will be added as an external asset and not inlined because adding it would make the total size of inlined styles exceed the defined threshold.
  
  Caching plugins and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors can tweak these behaviors and raise or lower the threshold as desired.
  
  Note: apologies for any typos, my finger are ill-suited to small phone keyboards.
  - mrwweb 10:44 pm on March 9, 2021
    
    Thanks for the reply, @aristath. I can mostly follow that, although I’m still a little confused about what happens to the styles that aren’t inlined. Do those end up creating a unique stylesheet per page based on exactly the list of blocks that aren’t inlined, or are they just covered by a default blocks stylesheet that also includes whatever styles were inlined?
    
    One other thought: I imagine this might have been considered, but this feels really similar to—but also different from—inlining critical styles that appear at the top of the page. Was there any consideration of incorporating the order/position of blocks in this determination (maybe with a kind of weighted score for position vs. size). For instance, it would seem wasteful to include any styles that are only required for a “footer area”, though I don’t know if it’s even possible to determine what’s a footer in FSE.
    
    Just thoughts. Thanks for engaging 🙂
    - Ari Stathopoulos 6:49 am on March 10, 2021
      
      I’m still a little confused about what happens to the styles that aren’t inlined.
      
      Nothing happens to them. They get loaded normally – just like before.
      Remember, there are 2 pieces to this puzzle:
      1. Each blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. now has an individual stylesheet which gets loaded separately when the block gets rendered
      2. Inlining small assets
      So there is no “default blocks stylesheet that also includes whatever styles were inlined”, some get inlined some get loaded normally.
      
      Was there any consideration of incorporating the order/position of blocks in this determination (maybe with a kind of weighted score for position vs. size). For instance, it would seem wasteful to include any styles that are only required for a “footer area”, though I don’t know if it’s even possible to determine what’s a footer in FSE.
      
      Unfortunately at this stage, this was not technically feasible. Maybe we can look into that for a future implementation, but right now it was not possible.
      - mrwweb 4:27 pm on March 10, 2021
        
        Thanks! I finally get it!

/wp-includes/css/dist/block-library/style.min.css?ver=5.6.2

Size: 9.4 KB

/wp-includes/css/dist/block-library/style.min.css?ver=5.7

Size: 10.3 kb
Result: More heavy weight.

And, It still load whole library. 🙁

<link rel='stylesheet' id='wp-block-library-css'  href='https://www.example.com/wp-includes/css/dist/block-library/style.min.css?ver=5.7' media='all' />

Comments are closed.

WordPress.org

Welcome!

Communication

Core Editor Improvement: Need for (page/post) Speed

WordPress.org

Welcome!

Communication

Share this: