As more is being done to work on performance as it relates to 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, a hallway hangout has been planned to bring together folks from various backgrounds to see what else can be worked on, unblocked, and better understood. This is meant to be both a knowledge sharing and alignment creating session between folks from various areas including but not limited to @flixos90 @adamsilverstein @spacedmonkey @youknowriad @desrosj @tweetythierry @oandregal @aristath.

If you’re interested in joining, the Hallway Hangout will happen on 2023-01-10 14:30. 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 general intros (what each person does/focuses on), current work underway to address performance, what work is being done specifically for block themes, and general open Q&A. 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 demo/discuss.

Recording

Attendees:

@flixos90 @adamsilverstein @spacedmonkey @tweetythierry @oandregal @priethor @clarkeemily @daisyo @greenshady @annezazu @scruffian @josephscott @mihai2u @joegrainger @delawski @sergiomdgomes @luminuu @hellofromtonya mukesh27 Felix Arnes, Didier Mahaux, and Simon (didn’t catch a last name).

Notes

Overall themes to the conversation:

• There’s difficulty in this work partially due to how backports happen from 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/ to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. both for finding and fixing regressions.
• There’s still a big need to have solid measurements and track them in some level of granularity for both Core and Gutenberg.
• There’s great potential in Block theme performance because of how they are built to improve performance.
• Some level of changes in performance is okay but we need to avoid major regressions and not let perfect get in the way of good enough.
• A Performance role for the upcoming 6.2 release squad should be considered to improve coordination between various teams and focuses.

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. performance & avoiding major performance regressions with merging Gutenberg into Core 

• We kicked the call off discussing issues in 6.1 around caching data in theme.json, which led to a broader discussion around merging Gutenberg into Core in a way that avoids regressions.
• Andre shared how performance is measured in Gutenberg (typing, time it takes to load a big post, etc) for each release. You can see the results of each test in the various release posts under “Performance Benchmark”.
• Some performance concerns for 6.1 happened only via manual testing. How can we automatically find this rather than needing to manually manage much of this work?
• Testing needs to happen both in Gutenberg and with Core.
• It’s not always easy to spot performance concerns in the 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 for a variety of reasons:
  • How code is ported from Gutenberg to Core making it hard to track problems down with this example shared of the kind of large backports that happen.
  • Iteration happens much faster on the Gutenberg side than Core.
  • Inconsistencies in results depending on the tool used.
• A question was raised around whether there is load time performance tracking on the front end for Gutenberg. This currently doesn’t exist but it was agreed that it should be explored.
• Tonya shared how iteration happens much faster on the GB side with Core happening less frequently so when we think about performance, we want to think about strategies for how we can do it on a faster basis. Let’s not wait until we get into Core and let’s retest when it gets added to Core. 
  • Tonya’s team is working on improving the backporting process with sooner and smaller backports to Core to get them in throughout the development cycle. If it’s ready, 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. it rather than waiting. 
  • Part of this work is making sure Gutenberg back end code is Core ready (runs against same thing so when backports are ready to go, it’s Core ready). 
  • Tonya is going to do a Make post to cover what her team is working on.
• Jonny brought up confusion around where to make changes when performance concerns are found. This is a larger conversation and it was agreed to bring that discussion into a different space to preserve the conversation around performance.

Avoiding regressions in Classic themes & how performance is measured

• Adam brought up an example of a performance concern with Classic themes that has yet to be addressed: https://core.trac.wordpress.org/ticket/56990 
• Jonny is doing very manual testing to try to catch things as much as possible. Having automated tests would be huge along with being able to generate a spreadsheet comparing RCs, commits, etc.
• Database queries are usually a sign that something is loading that shouldn’t be loaded. It’s not always obvious but it can act as an early warning sign that something isn’t working.
• Joseph previously volunteered for the measurement side but got pulled into other things. It sounds like this is still a significant need to figure out, do measurements, and track them in some level of granularity (per day, per commit, per release) for both Core and the Gutenberg plugin. 
• Sergio shared more around the WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ side of things with lots of tooling being run tools for WordPress.com servers which wouldn’t apply well to this situation since they are not particularly suitable to ongoing development. 
• Felix discussed measuring server side performance by using server timing metrics to see how many ms certain processes take. In theory, you could have something that could receive server timing metrics. 
• The performance dashboard for Gutenberg was discussed as a spot to make more robust and port in more tracking: https://codehealth.vercel.app/ 
• The general topic of how to measure PRs to reflect real improvements in production came up with Andre sharing how depending on the tool used there are wildly different responses in performance impact. 
• Jonny brought up how complex this can get when you add in object caching, PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions, etc. Any performance metrics would need to have a matrix of configurations to cover cases. 
• In general, need to also look at regressions individually because they might be different to a different degree depending on environment. 
• An example was shared of how to use the server-timing api in wordpress/gutenberg with an implementation of it to the Performance Lab plugin: https://github.com/WordPress/performance/pull/553 
• Adam ended this section of the conversation with a great reminder that some level of small changes in performance in normal but we need to avoid major regressions. Let’s not let perfect get in the way of good enough.

Core web vitals and block themes. What parts of Core can be improved out of the box? What are we doing specifically around block themes? 

• Jonny shared that because of theme.json, Block themes are slower than Classic themes with work underway for them to be on par with Classic themes. There’s an amazing opportunity to do performance work with Block themes because everything is a block. You could prefetch image assets, ensure images above the fold are loaded, etc once you know entire markup of page before headers are sent.
• Joseph brought up an issue around lazy loading LCP images that was implemented in a previous release but didn’t make it to block themes (only made it to classic). This is pending for the next release. 
• Discussed various ways enhancements could happen with script and resource loading (CSSCSS Cascading Style Sheets. file loading, font loading, etc) as well as lazy loading things as well beyond just images (what about CSS?). For example, if a block is in the footer of the page, could load later on.

Thoughts around better ways teams can work together around improving block themes. 

• In particular, this refers to the Core Editor, Core, and the Performance teams since we’re all ultimately a part of broader WordPress efforts and we can use our unique expertise to be better together.
• Discussed having another hallway hangout specific for WordPress 6.2 items to have more practical, hands on things to go through.
• Anne threw out the idea of having a Performance related role for release squad and will follow up to more formerly propose.
• Jonny brought up ensuring folks are giving the time to respond during releases and 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.” early. At the same time, Tonya reminded us to avoid having bottlenecks and to practice reviewing something after it’s merged to still fix what’s found.

Next steps:

• @hellofromtonya will share a Make post about the work her team is doing at Automattic around more continually backporting items from Gutenberg into Core.
• @annezazu will suggest a performance role on release squad (with +1 from Tonya, Jonny, and Thierry).
• @annezazu will follow up with a 6.2 related performance hallway hangout once 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. 1 is released.
• @adamsilverstein will share a Make post on an automated testing environment and possible steps there.

#hallwayhangout, #performance