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 core 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
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 Gutenberg 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 block 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.