Performance Chat Summary: 21 November 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

  • @thekt12 I was working on template loading research for – https://github.com/WordPress/gutenberg/issues/45601 this were the findings-
  • @thekt12 In short – we can get some improvement for pages if we disable variations for pages we don’t need it. Root cause is however parsing of theme json.
  • @joemcgill Interesting! It sounds like the ongoing work to add improved caching to WP_Theme_JSON data is still the most promising improvement, if we can come up with a good strategy for doing so. #57789 Is that your read?
  • @thekt12 Yes, improving WP_Theme_JSON is the most promising improvement. In addition we can also disable variations for pages that don’t need them to be loaded.
  • @joemcgill So the question then is how to know when a variation needs to be loaded and when not?
    • @thekt12 Yes this is something I am trying to figureout.
  • @thekt12 A snapshot of before and after. And the change improve ~80ms in total load time too [link to image]
  • @joemcgill I think creating a Trac ticket for further exploration would be the best next step, since this was originally only being discussed in the GB repo, but will require core changes, I believe.
  • @joemcgill Related to the above, I’ve been working on #59719 some this week, with hopes of having something sharable this week.

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

  • @pbearne I have refreshed #42441 and fixed an issue with update_options function. Does it need a proposal for core, or can it just get merged? Do we need/want an upgrade routine/CLI command to remove all the oversized options from autoload list?
    • @joemcgill When we last looked at that issue, my understanding was that we weren’t totally sold that the approach to change the DB values was ready, or at least needed some broader consensus and testing. Not sure if @flixos90 had a different opinion. Regardless, having this refreshed and looked over with fresh eyes is wonderful!
    • @flixos90
    • Thanks for iterating on this. I’m planning to take another look at this today or tomorrow. We still have to indeed decide on what to do with the database value, but there were other issues in the original PR, so having an update is great.
    • @joemcgill At minimum, I would love to see the approach written up on the ticket rather than just in the PR so the DB changes being proposed are clear.

JavaScript & CSS

Link to roadmap project and link to the GitHub project board

Contributors: @mukesh27 @10upsimon @westonruter @flixos90

  • @joemcgill This effort is worth keeping an eye on: https://make.wordpress.org/core/2023/11/21/exploration-to-support-modules-and-import-maps/
  • @flixos90 I have continued iterating on https://github.com/WordPress/performance/pull/733, which is that new Speculation Rules module. I created a feature branch for it yesterday, as this definitely shouldn’t ship until January or so, whenever that browser feature becomes generally available
    • Currently thinking about what would be the customization needs there and how that could be exposed via a simple API. The Speculation Rules API is very bespoke in that it allows all sorts of nesting with “and” and “or” and “not” conditions, so I feel making that entire API e.g. a filter would be too error-prone. And maybe it’s too low-level to expose at that degree entirely. But there are definitely certain more specific aspects that need to be customizable per site
    • I’m also in contact with some of the Chromium folks working on this on the browser side, to get a better sense of some of those implications

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill @pereirinha @westonruter

  • @joemcgill I’ve been working on some initial explorations for improving the way WP calculates the sizes attribute with some success. Working on wrapping up some initial exploration and writing up some options we may be able to pursue there.
  • @flixos90 Weston is OOO as mentioned above, but he has made a lot of progress on the image loading optimization efforts (using client-side detection). For example, https://github.com/WordPress/performance/pull/878 was merged into the feature branch last week

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

  • @joemcgill Nothing new from me this week, but I do have on my to do list to do a broader profiling report of 6.4 to identify any additional server timing opportunities for the 6.5 cycle.
  • @swissspidy On #59900 I shared some initial thoughts on using a proper test matrix for the core performance tests
    • @joemcgill Is there any specific feedback you’re looking for?
    • @swissspidy Maybe some thoughts on how we’d like the summary to look like on GH (there’s an example link in my comment), and how important it would be to be able to run the same matrix locally as well.

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo

Contributors: @mukesh27 @swissspidy @westonruter

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

Open Floor

  • @luisherranz Well, I was about to say that following up on last week’s mention of the exploration of a Modules API, I had just published this post in Make Core to make people aware of the initiative and collect feedback. But the same link just popped up in the middle of the conversation (I published it an hour ago) 
  • @clarkeemily The performance have suggested organising an ‘End of Year Hallway Hangout‘ with the intention of having the following as a loose agenda:
    • Retrospective sharing field data for the cumulative performance impact of the performance team’s work in 2023
      • Potential questions/discussion/interpretation on metrics
    • Talking about 2024 plans
    • There are 2 options here if folks could vote:
      • Thursday December 7 – won with 4 votes
      • Thursday December 14

Our next chat will be held on Tuesday, November 28, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-performance, #performance, #performance-chat, #summary

Leave a Reply

Your email address will not be published. Required fields are marked *