Title: Core Editor Improvement: Need for (page/post) Speed
Author: annezazu
Published: March 4, 2021

---

 [  ](https://profiles.wordpress.org/annezazu/) [annezazu](https://profiles.wordpress.org/annezazu/)
8:51 pm _on_ March 4, 2021     
Tags: [core-editor ( 761 )](https://make.wordpress.org/core/tag/core-editor/),
[core-editor-improvement ( 35 )](https://make.wordpress.org/core/tag/core-editor-improvement/)

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

_Thank you to [@aristath](https://profiles.wordpress.org/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](https://make.wordpress.org/core/2021/03/02/whats-new-in-gutenberg-10-1-3-march/)!

**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](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](https://github.com/WordPress/gutenberg/pull/28358),
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/](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](https://github.com/WordPress/gutenberg/pull/25220),
an [additional PR was merged for Gutenberg 10.1](https://github.com/WordPress/gutenberg/pull/28358)
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](https://developers.google.com/search/blog/2020/11/timing-for-page-experience#:~:text=Today%20we're%20announcing%20that,security%2C%20and%20intrusive%20interstitial%20guidelines.)
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](https://wordpress.slack.com/archives/C02QB2JS7),
check out the [current focuses](https://make.wordpress.org/core/tag/gutenberg-next/),
and attend the [Core Editor weekly meeting Wednesday @ 14:00 UTC](https://make.wordpress.org/core/tag/core-editor-agenda/).

[#core-editor](https://make.wordpress.org/core/tag/core-editor/), [#core-editor-improvement](https://make.wordpress.org/core/tag/core-editor-improvement/)

### Share this:

 * [  Threads ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=threads)
 * [  Mastodon ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=mastodon)
 * [  Bluesky ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=bluesky)
 * [  X ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=x)
 * [  Facebook ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=facebook)
 * [  LinkedIn ](https://make.wordpress.org/core/2021/03/04/core-editor-improvement-need-for-page-post-speed/?share=linkedin)

 1.  ![](https://secure.gravatar.com/avatar/97d5803dc15d4c86651484ae482e6b7a1d10fda8d6beb1e087b565ac2fe4c12b?
     s=32&d=mm&r=g)
 2.   [curtiskessler](https://profiles.wordpress.org/curtiskessler/)  1:20 am _on_ 
     March 5, 2021
 3.  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.
 4.  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.
 5.   * ![](https://secure.gravatar.com/avatar/471c510b2590bce99d5e41cc9b817f0c0d420f08d0930e70b18299f993ffa965?
        s=32&d=mm&r=g)
      *  [Ari Stathopoulos](https://profiles.wordpress.org/aristath/)  7:48 am _on_
        March 5, 2021
      * I’ve actually been discussing the emojis thing with [@jonoaldersonwp](https://profiles.wordpress.org/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.
 6.  ![](https://secure.gravatar.com/avatar/ccaa88499ddddbbb1c5112a92e6b2f4e695ae1bf78135a548dda049c5025ef93?
     s=32&d=mm&r=g)
 7.   [Sami Keijonen](https://profiles.wordpress.org/samikeijonen/)  8:56 am _on_ March
     5, 2021
 8.  Is there a documentation (or pointing to source code) how custom blocks can leverage
     the same technique?
 9.  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.
 10.  * ![](https://secure.gravatar.com/avatar/a61af5cd9a78137214c3f0b276a3d07bdb931397f4d7861ce6b818fd062b542d?
        s=32&d=mm&r=g)
      *  [Greg Ziółkowski](https://profiles.wordpress.org/gziolo/)  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/](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/](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](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
      *  - ![](https://secure.gravatar.com/avatar/ccaa88499ddddbbb1c5112a92e6b2f4e695ae1bf78135a548dda049c5025ef93?
           s=32&d=mm&r=g)
         -  [Sami Keijonen](https://profiles.wordpress.org/samikeijonen/)  1:16 pm 
           _on_ March 5, 2021
         - Thanks!
 11. ![](https://secure.gravatar.com/avatar/807c709d4142e246c32a82d4f675a7d88ada930e468525567a32806e0746e870?
     s=32&d=mm&r=g)
 12.  [titsmaker](https://profiles.wordpress.org/titsmaker/)  3:35 pm _on_ March 6,
     2021
 13. Kudos fot this change!
 14. ![](https://secure.gravatar.com/avatar/5612a0b1e26e958b7cb153ad8d69325be61525b2bba4819361bb69f127ec34b4?
     s=32&d=mm&r=g)
 15.  [mrwweb](https://profiles.wordpress.org/mrwweb/)  6:40 pm _on_ March 8, 2021
 16. This is a really neat change, but I do have a question about whether it’s unambiguously
     good for performance.
 17. 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.
 18. I did see that there was a filterFilter Filters are one of the two types of Hooks
     [https://codex.wordpress.org/Plugin_API/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.
 19. 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.
 20.  * ![](https://secure.gravatar.com/avatar/471c510b2590bce99d5e41cc9b817f0c0d420f08d0930e70b18299f993ffa965?
        s=32&d=mm&r=g)
      *  [Ari Stathopoulos](https://profiles.wordpress.org/aristath/)  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](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/](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.
         - ![](https://secure.gravatar.com/avatar/5612a0b1e26e958b7cb153ad8d69325be61525b2bba4819361bb69f127ec34b4?
           s=32&d=mm&r=g)
         -  [mrwweb](https://profiles.wordpress.org/mrwweb/)  10:44 pm _on_ March 9,
           2021
         - Thanks for the reply, [@aristath](https://profiles.wordpress.org/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 🙂
            * ![](https://secure.gravatar.com/avatar/471c510b2590bce99d5e41cc9b817f0c0d420f08d0930e70b18299f993ffa965?
              s=32&d=mm&r=g)
            *  [Ari Stathopoulos](https://profiles.wordpress.org/aristath/)  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.
               - ![](https://secure.gravatar.com/avatar/5612a0b1e26e958b7cb153ad8d69325be61525b2bba4819361bb69f127ec34b4?
                 s=32&d=mm&r=g)
               -  [mrwweb](https://profiles.wordpress.org/mrwweb/)  4:27 pm _on_ March
                 10, 2021
               - Thanks! I finally get it!
 21. ![](https://secure.gravatar.com/avatar/f5bcb0b183b67586e10f7445d22cd543c1dfa05ea3992dcdac543429532177b6?
     s=32&d=mm&r=g)
 22.  [Gulshan Kumar](https://profiles.wordpress.org/thegulshankumar/)  5:50 pm _on_
     March 10, 2021
 23.     ```notranslate
         /wp-includes/css/dist/block-library/style.min.css?ver=5.6.2
         ```
     
 24. Size: 9.4 KB
 25.     ```notranslate
         /wp-includes/css/dist/block-library/style.min.css?ver=5.7
         ```
     
 26. Size: 10.3 kb
      Result: More heavy weight.
 27. And, It still load whole library. 🙁
 28.     ```notranslate
         <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.

# Post navigation

[← CSS Chat Agenda: March 4, 2021](https://make.wordpress.org/core/2021/03/04/css-chat-agenda-march-4-2021/)

[Test scrub for WordPress 5.7 Release Candidate 2 and office hours →](https://make.wordpress.org/core/2021/03/05/test-scrub-for-wordpress-5-7-release-candidate-2-and-office-hours/)