Performance Chat Summary: 21 November 2023
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- Welcome to our new members of #core-performance
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-
register_block_core_template_part
accounts for~7%
of load time~80ms
. The function calls- build_template_part_block_variations, which accounts for
99%
of the function time. This function is called in almost every page. The root reason for this is deep down in the call stack it callsWP_Theme_JSON_Resolver::get_merged_data
, which callsWP_Theme_JSON::__construct
for parsing theme json. - Another interesting thing we found is that by disabling
build_template_part_block_variations
, for pages that don’t require it, we found there is an improvement of ~80ms which align to the total time needed for register_block_core_template_part. - Disabling change that was made – https://github.com/WordPress/gutenberg/issues/45601#issuecomment-1516214955 tested on default homepage of TT4
- Before Change – https://blackfire.io/profiles/933e16a5-0932-41e3-8fb7-a21c10dc3811/graph
- After Change- https://blackfire.io/profiles/c225c202-974c-4a9c-886f-ef731273461c/graph
- The challenge is how to tell apart pages that have variations from pages that don’t
- @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
- @clarkeemily we are intending to reach out to the plugin review team again today to continue the remaining roadmap to v1.0.0 here https://github.com/WordPress/plugin-check/issues/283
Creating Standalone Plugins
Contributors: @flixos90 @mukesh27 @10upsimon
- @10upsimon PR 864 IRO Update PL settings screen with new UI to manage standalone plugins and built-in modules (651) has finally been merged into the feature branch
- Implement migration logic and UI from old PL modules to new standalone plugins in PL settings screen (652) has been re-visited from a requirements POV and is currently work in progress, thanks to @flixos90 for detailing these out.
- This work will be merged into the common feature branch for the creating standalone plugins work
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
- Retrospective sharing field data for the cumulative performance impact of the performance team’s work in 2023
Our next chat will be held on Tuesday, November 28, 2023 at 16:00 UTC in the #core-performance channel in Slack.