Title: Hallway Hangout: Performance Improvements for WordPress 6.2
Author: annezazu
Published: February 3, 2023
Last modified: February 13, 2023

---

 [  ](https://profiles.wordpress.org/annezazu/) [annezazu](https://profiles.wordpress.org/annezazu/)
6:21 pm _on_ February 3, 2023     
Tags: [hallwayhangout ( 15 )](https://make.wordpress.org/core/tag/hallwayhangout/),
[performance ( 419 )](https://make.wordpress.org/core/tag/performance/)   

# Hallway Hangout: Performance Improvements for WordPress 6.2

Following up on the prior hallway hangout on [Performance Considerations for Block Themes](https://make.wordpress.org/core/2022/12/16/hallway-hangout-performance-considerations-for-block-themes/),
[@flixos90](https://profiles.wordpress.org/flixos90/) and I are running an additional
one on performance improvements in WordPress 6.2. [@flixos90](https://profiles.wordpress.org/flixos90/)
is the performance lead for the WordPress 6.2 release (a new role!) and this is 
a chance to get a more behind the scenes look at what’s to come.

**If you’re interested in joining, the Hallway Hangout will happen on [2023-02-13 16:00](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230213T1600).
a Zoom link will be shared in the [#core-performance](https://wordpress.slack.com/archives/C02KGN5K076)
SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/).
The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/)
channel before starting.**

At a high level, we’ll go through quick intros (what each person does/focuses on)
and what performance work has been done with WordPress 6.2, [with a likely specific focus on enhancements to theme.json](https://core.trac.wordpress.org/ticket/56975).
Ultimately, 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.

Noting this specifically for folks who have expressed interest previously or who
are involved directly in this work, despite some of you going to WC Asia! cc [@hellofromtonya](https://profiles.wordpress.org/hellofromtonya/)
[@aristath](https://profiles.wordpress.org/aristath/) [@oandregal](https://profiles.wordpress.org/oandregal/)
[@tweetythierry](https://profiles.wordpress.org/tweetythierry/) [@desrosj](https://profiles.wordpress.org/desrosj/)
[@youknowriad](https://profiles.wordpress.org/youknowriad/) [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/)
[@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/)

**Recording**

**Attendees:** [@flixos90](https://profiles.wordpress.org/flixos90/) [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/)
[@tweetythierry](https://profiles.wordpress.org/tweetythierry/) [@oandregal](https://profiles.wordpress.org/oandregal/)
[@annezazu](https://profiles.wordpress.org/annezazu/) [@mukesh27](https://profiles.wordpress.org/mukesh27/)
[@joemcgill](https://profiles.wordpress.org/joemcgill/) [@johnbillion](https://profiles.wordpress.org/johnbillion/)

**Notes**

**Overall themes to the conversation:**

 * 6.2 improves performance, in particular 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.
 * Block themes are still slower with server response time than Classic themes due
   to higher configurability. Based on how block themes work they allow us to do
   more for client side performance than Classic themes.
 * Testing environments can be quite different, making it hard to replicate at times
   and important for folks to run across different environments before coming together
   to cross compare.
 * Performance regressions seem to be caused by a build up of PRs causing minor 
   changes rather than a few PRs. On the flip side, object cache improvements are
   responsible for most of the improvements though.
 * Some regressions are quite minor, a few ms, and it’s important to contextualize
   percentage changes with that in mind.
 * There’s a sense that there’s an opportunity with newer mechanisms, like theme.
   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., to bring bigger improvements in performance.
 * Education for developers is needed from a few angles: documentation, learn WP
   content, developer tools, automated testing.
 * We need to differentiate between consistency and variance coverage when it comes
   to performance testing. Start small and expand.
 * Consistency is critical to have when doing these tests. No matter how good this
   work gets, there will always be some variance in performance results and an inability
   to cover all of the real world cases.

**Overview of performance lead role**

 * Came about as [part of the last hallway hangout](https://make.wordpress.org/core/2022/12/16/hallway-hangout-performance-considerations-for-block-themes/)
   and is a new role for the 6.2 cycle, requiring some level of creating a new path.
 * [@flixos90](https://profiles.wordpress.org/flixos90/) has taken on this role 
   and shared about his experience thus far.
 * Responsibilities include: Prioritize performance enhancements, catch performance
   regressions and collaborate with relevant teams on fixing them, keep track of
   overall load time performance of WordPress coreCore Core is the set of software
   required to run WordPress. The Core Development Team builds WordPress. for the
   release.
 * More specifically, this work includes periodically reviewing tickets with performance
   focus keyword, assessing performance of different PRs, and conduct overall performance
   analysis of WordPress trunktrunk A directory in Subversion containing the latest
   development code in preparation for the next major release cycle. If you are 
   running "trunk", then you are on the latest revision. / BetaBeta A pre-release
   of software that is given out to a large group of users to trial under real conditions.
   Beta versions have gone through alpha testing in-house and are generally fairly
   close in look, feel and function to the final product; however, design changes
   often occur as part of the process. / RCrelease candidate One of the final stages
   in the version release cycle, this version signals the potential to be a final
   release to the public. Also see [alpha (beta)](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?output_format=md#alpha-beta).
   to identify notable wins and regressions. This latter task can hopefully become
   a lot simpler in the future, by relying on the [automated core testing environment](https://core.trac.wordpress.org/ticket/57687).
 * In the future, this role could expand for 6.3 to include general profiling to
   proactively identify bottlenecks to focus on.

**6.2 Improvements**

 * There’s been amazing work done to improve performance with block themes in particular
   for 6.2
 * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) brought up though
   that the numbers for block themes still aren’t comparable to classic themes. 
   Block themes are 2-3x slower.
 * It’s going to be difficult to keep the same level of performance with a classic
   theme because a block theme does more stuff to generate that page.
 * While the block themes have a slower server response time, it’s in part due to
   configurability which is higher.
 * Based on how block themes work they allow us to do more for client side performance
   than classic themes. Haven’t measured how much that offsets negative server side
   impact.

**Cause of regressions**

 * Lots of little things causing regressions rather than one main PR, making it 
   hard to address at times. On the flip side, the object cache work is responsible
   for most of the improvements though for 6.2.
 * Should we prioritize small fixes too rather than really big? We could prioritize
   smaller items and do lightning rounds of PRs. Little tweaks do add up but we 
   also do not want to get in the way of development. 
 * In systems that are newer, like theme.json, [@oandregal](https://profiles.wordpress.org/oandregal/)
   believes that there’s more space to improve things. For example, with theme.json
   caching the settings was obvious in retrospect. However, you don’t always anticipate
   how the call you write will be used. It’s likely that the newer systems will 
   have bigger spaces for improving and other ones will be more like little tweaks.

**More developer education**

 * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) spoke about how
   he wants to see more developer education done.
 * Helping folks write performant code or learn to use query monitor could help 
   the entire ecosystem improve.
 * There’s an opportunity to bake this into Learn WP work too cc [@psykro](https://profiles.wordpress.org/psykro/)
   for consideration (gave you a shout out in the call).
 * It’s critical to not just ship these improvements but to publicize them and get
   the word out.
 * If we start to notice consistent code patterns where people are repeatedly using
   certain functions in certain ways that could be optimized, we could work with
   other Make Teams to help reinforce best practices. 
 * [@tweetythierry](https://profiles.wordpress.org/tweetythierry/) brought up if
   there was more that could be done on the developer tools level, especially for
   core developers.

**Automated testing, testing environments, and variance vs consistency**

 * Don’t want an automated suite to dampen running our own tests and tweaking things.
 * Even small changes, like using a localeLocale A locale is a combination of language
   and regional dialect. Usually locales correspond to countries, as is the case
   with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales
   include Canadian English and U.S. English. or loading 30 posts rather than 10,
   can make a big difference.
 * It’s important to think about which environments we want to run tests in. A few
   sample environments – a little content, a lot of content, one without any language
   pack, one with a different locale, etc.
 * We can start small and expand as we will never be able to cover the real world.
   It’ll always be limited. Most important thing is that we test across consistent
   environments. No matter how good we make this, there will always be some variance
   in performance results.
 * [@tweetythierry](https://profiles.wordpress.org/tweetythierry/) brought up the
   need to differentiate between consistency and variance coverage. With automated
   testing, important to have consistency in setup but we shouldn’t just rely on
   one set of configuration forever. Should do it manually to increase variance 
   coverage. It’s super important to have consistency though at the end of the day.
 * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) brought up wanting
   to profile in different languages since 58% of sites aren’t running in English.
   There’s a solid chance that there’s low hanging fruit on translated strings that
   could really add up for majority of sites.

**Profilers and tooling**

 * Discussed Blackfire accounts for core contributorsCore Contributors Core contributors
   are those who have worked on a release of WordPress, by creating the functions
   or finding and patching bugs. These contributions are done through Trac. [https://core.trac.wordpress.org](https://core.trac.wordpress.org)
   as there’s been conversations with them in the past. It’s not open sourceOpen
   Source Open Source denotes software for which the original source code is made
   freely available and may be redistributed and modified. Open Source **must be**
   delivered via a licensing model, see GPL. though and couldn’t be used broadly
   for 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. and theme authors for example.
 * [@spacedmonkey](https://profiles.wordpress.org/spacedmonkey/) said to pingPing
   The act of sending a very small amount of data to an end point. Ping is used 
   in computer science to illicit a response from a target server to test it’s connection.
   Ping is also a term used by Slack users to @ someone or send them a direct message(
   DM). Users might say something along the lines of “Ping me when the meeting starts.”
   him if folks would like an account for testing and exploration.
 * This is another area that needs clear documentation on how to setup and what 
   to use.

**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/)
measuring more frontend metrics**

 * [@flixos90](https://profiles.wordpress.org/flixos90/) asked [@oandregal](https://profiles.wordpress.org/oandregal/)
   about the work being done in Gutenberg to [add more frontend rendering metrics](https://github.com/WordPress/gutenberg/issues/33645#top).
 * Currently, there aren’t many numbers yet for LCP since it just landed a few days
   ago.
 * Time to first byte doesn’t have much variance when comparing against something
   like typing that has a lot more variance.
 * With frontend measurements having less variance, it should be easier to find 
   regressions since they are more stable than the others. 
 * Thus far, not a ton of data but need to be mindful of the data because of the
   current setup. For example, we need the template we are using to use big images
   to spot other kinds of regressions.
 * [@flixos90](https://profiles.wordpress.org/flixos90/) shared the [web vitals GitHub repo](https://github.com/GoogleChrome/web-vitals)
   that is supposed to be very close to how core web vitals are measured.
 * [@oandregal](https://profiles.wordpress.org/oandregal/) shared that there are
   some things this library does that the tests he implemented don’t do. Especially
   as we grow and add more metrics, it would help to go with a library.

**Links Shared**

 * [Evolution of WordPress TTFB: 5.6 to 6.2](https://oandre.gal/evolution-of-wordpress-ttfb-5-6-to-6-2/)
   post from [@oandregal](https://profiles.wordpress.org/oandregal/).
 * [Performance regression in `wp_enqueue_global_styles()` for classic themes](https://core.trac.wordpress.org/ticket/57648).
 * [TTFB for WordPress 6.2](https://docs.google.com/spreadsheets/d/1jEUFtmkM_OyCAu2dBtylUKg1pcbkuLJNFxKDFyS80p8/edit#gid=47669135)
   from [@oandregal](https://profiles.wordpress.org/oandregal/).
 * [WordPress 6.2 server-side performance check](https://docs.google.com/spreadsheets/d/1p8Bw8Y_53NlZ8rHRmXn-a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=2025456764)
   from [@oandregal](https://profiles.wordpress.org/oandregal/).
 * [Add frontend rendering metrics in the performance tests](https://github.com/WordPress/gutenberg/issues/33645#top)
   for Gutenberg including a link to the performance test results: https://codehealth.
   vercel.app/project/1

[#hallwayhangout](https://make.wordpress.org/core/tag/hallwayhangout/), [#performance](https://make.wordpress.org/core/tag/performance/)

### Share this:

 * [  Threads ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=threads)
 * [  Mastodon ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=mastodon)
 * [  Bluesky ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=bluesky)
 * [  X ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=x)
 * [  Facebook ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=facebook)
 * [  LinkedIn ](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?share=linkedin)

 1. ![](https://secure.gravatar.com/avatar/d1206b2538cfce31db7cfe5cf02cc5913c44d6428cf218ea0e357faa23accb0c?
    s=32&d=mm&r=g)
 2.  [André](https://profiles.wordpress.org/oandregal/)  11:54 am _on_ February 10,
    2023
 3. I’d like to attend this hangout, though I don’t know if I’ll be able to. So I wanted
    to document some thoughts.
 4. In the last hangout, I raised the lack of metrics for front-end performance as 
    problematic. It was holding our conversations up and creating confusion about prioritization
    and even deciding what was impactful and what was not.
 5. I’d like to report 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/](https://wordpress.org/gutenberg/)
    has shipped a v1: it now tracks Time To First Byte and Largest Contentful Paint.
    See tracking issue [https://github.com/WordPress/gutenberg/issues/33645](https://github.com/WordPress/gutenberg/issues/33645)
 6. The rationale for them to be the v1 is that we need visibility in what happens 
    in the server and the browser.
 7. While tracking the time spent in the server is useful, it doesn’t directly correlate
    to user-perceived performance. We need to track client metrics as well. For example,
    WordPress processes the post to render, so it can identify the blocks in use. With
    that information, it enqueues only the CSSCSS Cascading Style Sheets. of those 
    blocks instead of the CSS of the whole 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. library. This certainly takes more
    time in the server, though we expect it to improve the perceived performance by
    the user. If we only tracked server metrics, they’d report this behavior as a regressionregression
    A software bug that breaks or degrades something that previously worked. Regressions
    are often treated as critical bugs or [blockers](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/?output_format=md#blocker).
    Recent regressions may be given higher priorities. A "3.6 regression" would be 
    a bug in 3.6 that worked as intended in 3.5., and we’d lack tools to understand
    how it impacted the actual user-perceived performance.

Comments are closed.

# Post navigation

[← Faster Updates Testing Complete](https://make.wordpress.org/core/2023/02/03/faster-updates-testing-complete/)

[Phase 2, Finale →](https://make.wordpress.org/core/2023/02/04/phase-2-finale/)