Hallway Hangout: Performance End of Year Review 2023

Following up on the prior performance related hallway hangout for WordPress 6.3, and hallway hangout for WordPress 6.4, @flixos90 @joemcgill and @clarkeemily co-hosted an end of year hallway hangout to review the WordPress performance enhancements from 2023, and a look ahead to 2024!

The Hallway Hangout took place at 2023-12-07 16:00 and the Zoom link was 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 went through the following agenda:

  • Quick intros (what each person does/focuses on)
  • Review of WordPress performance improvements throughout 2023
  • Retrospective sharing field data for the cumulative performance impact of the team’s work in 2023
  • Discussion around interpretation of metrics
  • A look ahead to 2024 plans

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

Noting this specifically for folks who expressed interest previously or who are involved directly in this work cc @hellofromtonya @aristath @oandregal @annezazu @tweetythierry @desrosj @youknowriad @dmsnell @pbearne @swissspidy @westonruter @adamsilverstein @mukesh27 @joemcgill @johnbillion @10upsimon @thekt12 @linsoftware @pereirinha

Recording

Attendees:

@pbearne @joemcgill @clarkeemily @flixos90 @thekt12 @swissspidy @adamsilverstein @westonruter 

Notes

@flixos90 presented the WordPress Performance 2023 CWV Impact Retrospective slide deck, thank you very much for pulling this together Felix.

Please click the image above to view the slide deck

INP Discussion

@adamsilverstein @flixos90 @pbearne were discussing whether INP mobile scores are due to lower powered mobile devices. The team discussed whether there may be an answer we can find. Mobile passing rate is more of a problem with INP (high chance it’s because of low powered devices). It could be networknetwork (versus site, blog) conditions as well, but lower powered devices likely to be the cause. @pbearne did raise: what would be the fix, low res images? How could we support under-powered devices? @flixos90 commented that for INP specifically it’s about 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/.. The amount, and how it’s executed, i.e. using a worker thread comes to mind that can improve INP. WordPress doesn’t have support for worker thread. This could be a good opportunity. More about the actual JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. code, reduction of JS code and optimizing JS code. 

It was suggested that the 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 Checker tool could help with? Are there any optimization tools to help here? General consensus is that folks are just not sure. @adamsilverstein mentioned that it’s not just static analysis, these INP issues don’t tend to come up, it’s more in the field when there’s a lot of JS interacting on the page simultaneously. Complicated layouts also contribute to low INP, DOM layouts — but unsure if this is our problem. Maybe likely to be in the front end, themes. Also in the combination of things, animations, app providers, tracking etc, these things add up and compete for resources on a low powered device. @westonruter shared How to diagnose slow INP in the lab: https://web.dev/articles/manually-diagnose-slow-interactions-in-the-lab.

@flixos90 highlighted the Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (very new and not publicly available) this is the first WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. own JS API that is just starting to be rolled out. This would allow plugins to use an API allowed by core, htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. directives, could we improve INP through the interactivity API — great potential opportunity for the future. Static analysis in the plugin checker, could look to pointing plugin checker to interactivity API. Prevalence of cookie consent policies, are these contributing to low INP scores? The team feel this is potentially low hanging fruit as 90% of sites need one now.

@joemcgill mentioned the tricky part here is the big services that provide cookie consent provide their own JS code to drop in the page, integrations would be more challenging. @pbearne mentioned a simple basic one that works would be great. Could it be done in a way where you don’t get penalized in the stats. The team agree this is worth looking into. @pbearne asked if this could this be the case of analyzing the top 20 cookie consent plugins and see if they can be made into a canonical plugin and build from the ground up? However the potentially, tricky thing is building something into core will require extensibility similar to how the privacy policy feature was built, driven by legal requirements that are different in all places. If the extensibility is made too flexible, it may cause more INP problems.

Cost Analysis

@pbearne highlighted that there’s no tie back to numbers, costs etc in the presentation from @flixos90 — cost of search engines crawling the save in value, cost saving of hosting companies etc — wondered if there’s a way we can obtain any dollar values against what these performance improvements actually mean. @flixos90 advised that we can try to draw general conclusions but mostly to get real numbers is do individual case studies, maybe there are hosting providers that are happy to share how much LCP improved and what this means for revenue / cost, specific case studies would be the way forward here, it would be difficult to establish this more widely. Maybe there’s a call we can put out to ask any hosting providers if they’re willing to do a case study

TTFB Improvements

@joemcgill went on to discuss the second to last slide, idea that we can get more benefit from focusing on FE LCP improvements, the underlying TTFB improvements — this was Joe’s initial gut instinct, websites that care about performance fix TTFB by not hitting WP application at all, using aggressive page caching etc. However, mindful at the fact that WP 6.3 we had 2 big opportunities that had a big impact on client slide: removal of emoji loading script and image loading improvements (the addition of fetchpriority and the lazy loading improvements). Whilst focusing on FE LCP improvements are easier, do we have opportunities of similar scale that would make sense, or are we just driving server side?

@flixos90 added that the difference is that most of client side improvements that we have done are larger efforts, whereas improving server side cut off milliseconds that add up over time. There may be a point where we have no idea what to improve on the client side, but there are a few things mentioned on image sizes attribute is one of them, optimizing how large images are loaded, continuing to optimize fetchpriority and lazy loading are applied, will drive up the passing rate more. Felix added, the main indicator is when we look at mobile, this is where the big difference is happening, when you look at LCP and TTFB together, but LCP in 6.3 was a lot more (probably came from client side improvements predominantly). Desktop TTFB was more visible than mobile. We always benchmark on a desktop machine, so mobile devices are lower powered. Maybe it’s just because for mobile specifically TTFB improvements have a lower role, and it’s more about the device configuration.

@joemcgill went on to ask whether we’re just looking at the % that are getting good scores, rather than the value of TTFB or change in TTFB metric. Could we have made the same amount of improvement as desktop, but not a big enough value to go over the threshold of the passing rate. Felix mentioned he has looked at these numbers as he has assumed the same thing. When you look at aggregated data, there weren’t major improvements in similar ways. Overall scale is still not visible. 

2024 Suggestions

@pbearne suggested images, do the amounts of images in the media library impact going through file numbers, orphan image sizes left around — should we have a tool to help clean this up? Some images are left behind from changing themes etc, does this bloat the number of images in the file system? If it does, would a simple tool help remove images that are not current. Here, @adamsilverstein suggested that some regenerate thumbnails plugins, URLs still point to old images if they’re removed. Thinks everyone has things in folders, if people have them in one giant directory it would impact. File loading may not be an image, but one place to look at was maybe the attachments in posts database, when doing lookups etc, maybe there are places we can eliminate here — but suspect this is a small improvement. The remaining images are mostly about storage space wasted and incurring costs. For performance on end users, doubt this has a notable impact.

@pbearne also added that the interactivity API would be a great place to investigate. @flixos90 added we should think for next year what can we do to improve interactivity, facilitate WP sites having more responsive interactions. The new metrics means this is more significant. Load time performance, but split this more to cover interactivity. The team discussed any other intentional research what leads to lower INP passing rate, hypotheses have been created but could do with having confidence in knowing where the problems lie. More research is definitely needed.

@flixos90 continued, what do the TTFB numbers mean for us? This year we have been focused on improving TTFB in core, but thinking about mobile representation, are there other ways we should try to move forward TTFB — what about enhancing APIs to provide more guardrails to plugins, there are a lot of other components to this, could argue that small changes don’t cover lower powered — something core can do better to facilitate caching for more people. Can we unlock caching for sites that have hosts that don’t provide this feature etc. @joemcgill added that we had talked about trying to use the SQLite Database as an object cache for sites that don’t have a better option — could we think on this again?

@flixos90 liked this idea, worth exploring — this would be for object caching, could we use it for page caching? Persistent object cache avoids using database requests, not that significant for overall performance. Full page caching would be more beneficial to focus on. Avoiding hitting application altogether could be better. Was looking at full page caching in the CWV dashboard, surprised that the popular caching plugins their TTFB scores are not beating the general WP TTFB numbers, seems counter intuitive. Could we dive into this more? Were these plugins specific to having the full page caching, could not be turned on. @adamsilverstein added that we can get a geographical bias, if the plugin is popular in a region with slower internet, it’s not their problem its the users. @adamsilverstein highlighted that you can breakdown on the settings page of the CWV report by geographical region. Could query this in HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Archive to see if there are patterns. Other considerations are all WP plugins that offer full page caching offer this at the application level, not as good as having the layer at the hosting level.

Concluding Statements

@pbearne raised that as a plugin developer, having good tests or validations that I’m doing it right, i.e. plugin checker, improving this and helping you recognise where improvements should be made, is something that can improve overall performance. More work in this field would benefit overall, especially if we can do themes as well.

@joemcgill concluded that the team are thankful to Felix for pulling these numbers together, easy to not be able to see the big picture. But really great to see the impact the performance team has made is great to see!

Props to @joemcgill for proof-reading and to @flixos90 for the excellent presentation.

#core-performance, #hallwayhangout, #performance

Hallway Hangout: Let’s explore WordPress 6.5

This hallway hangout is a continuation of prior hallway hangouts in the FSE Outreach Program about release specific updates. In this session, we’ll talk through some of what’s to come in the next WordPress release with a proposed schedule for March 26th. This is being shared early to help encourage more folks to tune in and to build some excitement for this next release.

How to join

If you’re interested in joining, the Hallway Hangout will happen on  2024-01-16 21:00 . A Zoom link will be shared in the core-editor 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 and all are welcome to join, whether to listen or participate, for as long or as little as you’d like. This will be recorded and recapped.

Agenda

At a high level, expect this to take the form of a free flowing demo/presentation going through as many release priorities as possible. @annezazu and @saxonafletcher will take point to demo and share what’s being worked on. Others might jump in to share as well depending on the roadmap post for 6.5 and where work stands by that point in the release cycle.

As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind. Depending on how large the session is, we may not get to all questions live on the call but we can always include follow up in the recap.

#6-5, #hallwayhangout

Hallway Hangout: Recap of working session on consolidating navigation modes

This is a summary of a Hallway Hangout that was wrangled in the #accessibility channel after a prior hallway hangout on improving accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) in the Site Editor and took the new form of a concrete working session to address a specific problem. It was first announced on October 1st and was open to all.

Attendees:

@alexstine @joedolson @richtabor @annezazu @jerryj @afercia @elblakeo31 @peteringersoll

Video Recording:

Notes/Links:

After some quick intros, we dove into talking about the problem before exploring possible next steps, approaches, and current issues. 

Related issues:

Difference between modes

To kick off, Joe asked Alex to talk through the current pain points and differences between modes. As Alex said, navigation mode is a hackedhacked together feature. The biggest problem we have, the navigation mode is a dynamically updating button. Everytime you press your arrow key or tab key when you’re in navigation mode, it dynamically re-renders. This is a challenging problem to handle with screen readers because it’ll ignore this. For Windows, there’s also a longstanding issue where the arrow keys don’t actually send the keyboard events through the browser so tab is the only viable key. Conversely, List View is much simpler in the way you can navigate with keys and it’s wrapped in a navigation role. You are able to expand rows, have control over what you’re looking at, etc. Another current problem with navigation mode, it’s not entirely clear when there are inner blocks. Alex started to work on this but stopped to focus on list view. 

What are the consequences if we stripped out navigation mode and used list view as the primary way of browsing through blocks?

To date, there has been no modal, tips, etc for keyboard users in the editor. People who are used to this would have no idea it has changed and we need a way to communicate that change, perhaps using a similar approach to the change in template parts to the patterns section. 

Andrea, who helped implement navigation mode, offered some historical context. He shared that if we are going to use navigation mode, we’re going to reintroduce a major issue that existed before introducing the two modes. Imagine that a post contains dozens of blocks. If you want to navigate these blocks in the post content area with the tab key, you are going to have to go through all of the dozens of blocks including the interface of 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. (dozens of tab stops). Nav mode was originally meant to reduce the number of tab stops when navigating through the blocks in a way that each block was only one tab stop rather than multiple then pressing enter gives the ability to switch the block to edit mode where you can navigate inside the block. This was the original implementation and it made sense when there were no inner blocks. 

Joe noted that List View works the same way where you can go block to block. When you use the tab key you are going through all of these elements. However, there are still a lot fewer elements than going through the blocks themselves. We should be willing to compromise to some degree. Arrow key navigation in List View also does work. It’s 100% accessibility and there are a total of three tabbable elements in list view: tab panel, close button, and list view area itself. 

Alex would like to find a better way to manage focus between block editor and block sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. but that’s a broader discussion. Jerry and Alex have worked on this but it’s a long battle. 

Trying List View + Focus Mode for container blocks as an experiment

Anne pitched trying getting rid of navigation mode and use list view + focus mode as an experiment in 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/. We could then do a call for testing and get a sense of what the experience might be like more practically. Folks were very much onboard with trying this out, especially since in the long run this would reduce the number of mechanisms to maintain. 

The question of how many people are used to using navigation mode came up though, especially since the feedback folks are worried about is more about non screen reader users. Anne is going to try to get some initial data from 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/.

Mobile concerns

Rich chimed in that the current primary use for that view is on mobile devices as this makes it easier to select child first nested blocks so it’s easy to tap onto. We never really got to the bottom of this on the call as we all pulled out our phones to investigate and couldn’t figure out how to even evoke the mode. 

Locked blocks and inert

We discussed how to explain disabled blocks in List View which relates to a broader discussion on alternatives to inert. There’s no good way to explain to a blind user what a template looks like when editing a smaller portion like a page. Anne showed an option to toggle on/off a template preview when editing a page in the Site Editor and we discussed a few ways we could enhance that feature to save it as a preference/have it be persistent in some way. 

Focus mode concerns

We discussed Focus Mode and adding it to Container Blocks. A big piece to figure out is how the back button works and ensuring it returns you to where you’d expect in the Site Editor experience.

Gutenberg as a framework concerns

Alex brought up an excellent point around Gutenberg being used as a framework, like with Blocks Everywhere, and how navigation mode is built into it as a package. We need to consider this in removing the navigation mode and it might be that it remains for third party usage. 

Next steps:

@annezazu will follow up on the following: 

  • Open issue around “show template” rather than “template preview”. 
  • Open issue around persistence of “template preview” option and make it a user setting. 
  • Try to get data around usage for navigation mode from WordPress.com 
  • Open issue around where back button goes after focus mode and returning you exactly to edit button ideally. 
  • Add recap of this discussion to the overall discussion issues, including noting how this might impact gutenberg as a framework. 

Known issues:

Finally, @annezazu will create an issue to pitch this as an experiment to try in the Gutenberg repo as a next step. 

#accessibility, #core-editor-3, #gutenberg, #hallwayhangout

Hallway Hangout: Working session on consolidating various navigation modes

This hallway hangout is a follow-up to our previous discussion about improving the Site Editor’s accessibility. In this session, we’ll work together to explore what streamlining the navigation modes might look like, including considering the use of List View and evolving Focus Mode for container blocks.

To provide context, when navigation and edit mode were initially introduced in 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/ 6.3, nested blocks and the Site Editor did not exist. We now face the challenge of finding a more efficient way to navigate between content.

There’s currently an async discussion and open issue on this topic that anyone is welcome to chime in on ahead and after this working group.

How to join

If you’re interested in joining, the Hallway Hangout will happen on 2023-11-15 16:00. A Zoom link will be shared in the #accessibility 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 and all are welcome to join, whether to listen or participate, for as long or as little as you’d like.

Agenda

At a high level, we’ll start with some intros to get familiar with who has joined us on the call before diving into the topic in practical terms: How does everything work today? How might deprecation work? What accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements or fixes are needed for this to be viable?

As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind. Because this will be more of a working session, we’ll be solely focused on the topic prepared so please keep that in mind when considering whether to join.

#accessibility, #hallwayhangout, #site-editor

Hallway Hangout: Performance Improvements for WordPress 6.4

Following up on the prior performance related hallway hangout for WordPress 6.3, @flixos90 @joemcgill and @clarkeemily will be co-hosting an upcoming hallway hangout to discuss happenings for 6.4.

If you’re interested in joining, the Hallway Hangout will happen on 2023-10-19 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 will go through quick intros (what each person does/focuses on) before reviewing WordPress 6.3 performance impact in the field, diving into WordPress 6.4 performance improvements and looking ahead at what can be learned for WordPress 6.5. 

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 @swissspidy @westonruter @adamsilverstein @mukesh27 @joemcgill @johnbillion @10upsimon @thekt12 @linsoftware @pereirinha

Recording

Attendees

@mukesh27 @joemcgill @thekt12 @flixos90 @clarkeemily @adamsilverstein @westonruter @pbearne @swissspidy @10upsimon

Notes

Overview of 6.4 performance improvements

During the call, @joemcgill discussed the benchmark results from WordPress 6.4 where we have identified good improvements for classic themes in particular, and a hypothesis for where those improvements came from was discussed. Currently, it’s difficult to identify where the improvements to classic themes in WordPress 6.4 comes from, but the team are planning to spend additional time investigating this.

@adamsilverstein discussed whether we can start to identify these differences using automated testing, but the variance is difficult to assess. @adamsilverstein suggested having the data in Opentelemetry or Grafana where you can map a trendline with all the data. However, the set up that you use for testing makes a large difference to results.

@flixos90 mentioned that the old approach for benchmarking provided different results compared to the new approach. @joemcgill discussed important considerations for benchmarking, saying that lab results are instructive, however this does not necessarily translate to what we see in the field. @pbearne suggested a query string switch and for people to disable a range of variables, and potentially we could build in A/B testing, this could be a headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. This could point towards a third method, lab in the field benchmarking!

@flixos90 shared this spreadsheet where benchmarks were compared from previous WordPress versions to WordPress 6.4, as we know so far. This contains only one negative number which is a great result! The results from the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ actions workflow built by @swissspidy are relatively consistent. @pbearne discussed diminished returns as we do the benchmarks, and discussed how best we set expectations around these improvements.

@flixos90 one thing the performance team needs to work on is consistency in benchmarks. The WordPress 6.3 in the field post was discussed. It was great to see lazy loading and fetchpriority contributed to these improvement and improvements to LCP were discussed. The CWV tech report which looks at overall WordPress, using all sites that are listed in the httpHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. archive dataset, was also shared and discussed at length. Between July this year, and September this year, the CWV passing rate went from 39% to 41.5% passing rate which is a significant improvement in a short space of time.

Performance 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. for WordPress 6.4

Upcoming Improvements in WordPress 6.5

@joemcgill took us through some upcoming improvements for WordPress 6.5, including:

  • Sever Timing
    • Performant translations 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 (see #59656)
    • Template loading (includes WP_Theme_JSON improvements)
    • 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. HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. follow-up
  • Review Fonts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
  • Image optimizations
    • Better sizes calculations (to be completed after 6.5)
    • Block template image optimizations (#59464, #59577)
    • Continue improving LCP heuristics (fetchpriority, lazy-loading)
  • Database optimization
    • Auto-loaded options next steps
  • Measurement

The future of WebP images was discussed at length towards the end of the meeting.

#hallwayhangout, #performance

Hallway Hangout: What’s new for developers in WordPress 6.4

Next month, @greenshady, @welcher, and I will host a casual conversation about the most important and exciting developer-related changes coming soon in WordPress 6.4. From 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. HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and the Font Library to improved Editor flows and the new Twenty Twenty-Four theme, there is just so much to talk about.

The Hangout will begin with a brief overview of the major changes, and then we’ll open it up for group discussion and Q&A.

This event will be held on Thursday, October 12, 2023, at 1:00 PM CST (18:00 UTC), which is right before WordPress 6.4 RC1. The meeting link will be shared through the Learn WordPress MeetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. group. RSVP for the event to access the link. We hope to see you there!

Props to @greenshady for review.

Recording

Notes

The Hallway Hangout was attended by 55 community members, including facilitators @greenshady@welcher, and @ndiego

The following resources were shared during the event:

#hallwayhangout

Hallway Hangout: Improving accessibility in the Site Editor

To ensure the Site Editor can be used by everyone, this hallway hangout aims to dive deep into the current accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) of this new experience with the aim to iterate and improve.

How to join

If you’re interested in joining, the Hallway Hangout will happen on 2023-09-14 15:00. A Zoom link will be shared in the #accessibility 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 and all are welcome to join, whether to listen or participate, for as long or as little as you’d like.

Agenda

At a high level, we’ll go through the following:

  • Quick intros.
  • Discussions around current concerns.
  • Demos of pain points from @alexstine and @joedolson.
  • Discussion about ways to resolve/address current, known issues.

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. Outside of the time for demos, we’ll intentionally have space for open discussion.

#accessibility, #hallwayhangout, #site-editor

Hallway Hangout: Let’s explore the power of block variations

Join Ryan Welcher (@welcher) and me next month for a casual conversation about 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. variations and how you can use them to enhance the editing experience in WordPress. An often overlooked feature, variations are a great way to extend existing blocks and can be as simple or complex as you like. Many WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks you use daily are variations!

To kick off the discussion, we will provide a brief overview of what variations are and how they work. Ryan will then share how he built the Advanced Query Loop 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 and why he opted for a variation of the Query block instead of building a custom block from scratch. And if you have built any variations or are using them in interesting ways, we encourage you to share them with the group. 

While block variations tend to be a more developer-focused topic, this Hallway Hangout will be accessible to everyone. The event will be held on Thursday, September 14, 2023, at 1:00 PM CST (18:00 UTC). The meeting link will be shared through the Learn WordPress MeetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. group. RSVP for the event to access the link. 

Recording

Notes

The Hallway Hangout was attended by 34 community members, including facilitators @ndiego and @welcher

Nick gave a brief overview of what Block Variations are and how to use them. Ryan then discussed how and why you might want to build more advanced variations and demoed his Advanced Query LoopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. plugin. Questions were asked and answered throughout. The following resources were shared during the event:

Props to @welcher for review.

#block-api, #blocks, #hallwayhangout

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 resolutionimage 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.08.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.:

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 ReportHTTP 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

Hallway Hangout: Performance Improvements for WordPress 6.2

Following up on the prior hallway hangout on Performance Considerations for Block Themes, @flixos90 and I are running an additional one on performance improvements in WordPress 6.2. @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. 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) and what performance work has been done with WordPress 6.2, with a likely specific focus on enhancements to theme.json. 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 @aristath @oandregal @tweetythierry @desrosj @youknowriad @spacedmonkey @adamsilverstein

Recording

Attendees: @flixos90 @spacedmonkey @tweetythierry @oandregal  @annezazu @mukesh27 @joemcgill @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 and is a new role for the 6.2 cycle, requiring some level of creating a new path.
  • @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). 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.
  • 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 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  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 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 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 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 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 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. 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/ or can be cost-based plugin from a third-party and theme authors for example.
  • @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/ measuring more frontend metrics

  • @flixos90 asked @oandregal about the work being done in Gutenberg to add more frontend rendering metrics.
  • 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 shared the web vitals GitHub repo that is supposed to be very close to how core web vitals are measured.
  • @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

#hallwayhangout, #performance