Hallway Hangout: Performance Improvements for WordPress 6.3

Following up on prior performance related hallway hangouts, @clarkeemily and I will be cohosting an upcoming hallway hangout to discuss happenings for 6.3.

If you’re interested in joining, the Hallway Hangout will happen on 2023-07-27 15:00. a Zoom link will be shared in the #core-performance SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel before starting.

At a high level, we’ll go through quick intros (what each person does/focuses on) before diving into WordPress 6.3 performance improvements led by performance leads (@clarkeemily @flixos90) and looking ahead at what can be learned for WordPress 6.4. Here’s a preview from the 6.3 beta 2 post:

Following the incredible performance improvements introduced in 6.2, the release includes more than 170 performance-related updates, including adding defer and async support to the WP Scripts API and fetchpriority support for images. Optimizations were made to block template resolution, image lazy-loading, and the emoji loader, all of which benefit LCP performance. Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions 8.0, 8.1, and 8.2 has been improved. 

As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to discuss around this important area of the project, especially since the agenda is intentionally loose to allow for it.

Noting this specifically for folks who have expressed interest previously or who are involved directly in this work cc @hellofromtonya @aristath @oandregal @tweetythierry @desrosj @youknowriad @spacedmonkey @adamsilverstein @mukesh27 @joemcgill @johnbillion.

Recording

Attendees

@adamsilverstein @mukesh27 @joemcgil @oandregal @clarkeemily @flixos90 @swissspidy @annezazu @poena @elmastudio @dlh @thekt12 @10upsimon @westonruter

Notes

After a round of intros for anyone who wanted to participate, we jumped into the following discussions.

Overview of 6.3 performance improvements

@flixos90 discussed an in-progress post rounding up performance improvements for 6.3, highlighting that thus far performance improvements are looking even better than for 6.2. Here are some quick stats from 6.3 RC2 shared yesterday:

LCP for 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. themes ~28% faster than 6.2.2

• TTFB ~22% faster
• LCP-TTFB ~37% faster

LCP for classic themes ~19% faster than 6.2.2

• TTFB ~1% slower
• LCP-TTFB ~30% faster

We also went through the following dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.:

Image performance enhancements in WordPress 6.3

Registering scripts with `async` and `defer` attributes in WordPress 6.3

As part of the above item, it’s important to note that dependencies for larger plugins are handled with care, opting for the more conservative pathway if broader extensions of a larger 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 haven’t opted this approach when the overall plugin has. If both switch, this new approach will be used. While not a performance enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. out of the box using WordPress since it requires adoption, it is an important item to cover to ensure folks see how they can put it to use. As part of this, we discussed both Delay loading comment-reply script with async loading strategy and Use defer loading strategy for frontend view scripts with the latter already merged to improve loading performance for frontend scripts in WordPress itself. More here: 

Now that we have Script Loading Strategies committed, I’ve started exploring how we can take advantage of them to improve frontend performance in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress./themes/plugins. As a first step, I wanted to try one set of enhancements to see what is involved and what the impact is to see whether the effort is worth it. As an initial exploration, I focused on the scripts that 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/ adds to the frontend, that is the block view scripts. These are unfortunately all added to the head and are all blocking. So opened a PR to leverage async and defer, and my findings a 19.3% reduction in LCP-TTFB! https://github.com/WordPress/gutenberg/pull/52536#:~:text=Performance%20Analysis

Weston in the #core-performance channel.

Diving into the data

Sparked by a question from @oandregal about when should we expect the improvements landed in 6.2 and 6.3 to impact RUM public datasets, we dug into data to see the impact of changes. André later shared a personal post on the topic! For context, lab data is what improvements we expect to see in a more contained environment where as field data is what we end up seeing on real sites. A note from Felix that we always have to wait at least a month after a new release to get a first set of metrics from the Chrome UX Report & HTTP Archive. To help aid digging into data, block theme detection was added to the HTTP archive a few months ago.

As discussed, the key is to pull tendencies as it’s hard to get absolutely exact data. Right now, the tendencies validates lab assumptions when looking into the field data! We went through reports both in Chrome UX Report data and Core Web vitals for TTFB:

Of note, data in CrUX is added at aggregate level and it’s not weighted by number of pages so a site with tons of pages is equally weighted for one with none. For Core Web Vitals, it shows a steady increase since April and it shows that we can look for delayed impacts for 6.3 in September/October to see how changes are landing.

Discussion around PHP backports to Core

We ended talking about backports to Core and the impact on performance as the the current performance process involves analyzing the previous state of WordPress versions to identify opportunities for improvement, implementing those improvements, and validating their effectiveness. The performance team wants to be more proactive and involved in looking ahead at work to come to ensure that WordPress remains performant, particularly with new features like duotone functionality being added late in the development cycle. We talked about the efforts from @hellofromtonya to ease the backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. process as well as the current time constraints to do so. We have a shorter release cycle for 6.4 so there’s a chance that we can experiment a bit more to see if we can do more frequent package updates.

We discussed the idea of a mid-point merge for PHP backports and a more formal workflow for both Core and Gutenberg teams. The proposal included a “PHP backport party” chat, similar to the release party chats, during the release cycle to facilitate collaboration ideally from more folks. We ended chatting about whether the Core Editor had a dedicated group on performance, explaining that there isn’t a dedicated group so much as a collection of performance-minded individuals within the Gutenberg development.

@hellofromtonya as someone who spends so much time living in this space, I’d love to know what you think here and how myself and @clarkeemily can facilitate as co-members of the 6.4 release squad.

#hallwayhangout, #performance