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

Announcements

• Welcome to our new members of #core-performance
• Thanks to everyone who visited the Performance table on Contributor Day at WordCamp US last week – here’s a round-up of some activity:
  • @westonruter I was working on removing unload event handlers from wp-admin (#55491) which relate to performance since they prevent bfcache. Got a mostly-complete patch ready for review. But ironically I found in 6.3 that bfcache was explicitly disabled via Cache-Control:
    no-store (#21938), so removing unload doesn’t have any effect. Maybe we want to revisit that.
  • @flixos90 I committed https://core.trac.wordpress.org/changeset/56445 at Contributor Day, that’s a big deal in terms of new API functions, with prime_options() and get_options() (the latter is probably what most WP devs will immediately understand what it does)
  • @mukesh27 One ticket that was committed at WCUS Contributor Day Performance optimization of register_block_script_handle() – This will improve improve Server side metric by ~1%
  • @joemcgill #58998 should help avoid DB stampedes when rewrites are flushed. I’m hoping @icaleb will be able to test this patch at VIP and let us know if there are any side effects that we need to be aware of.
  • @joemcgill We also had #52759 committed that adds a filter to avoid a potentially expensive DB query, but it’s currently reopened to consider a name change for the filter. Feel free to weigh in if you have opinions.
  • @flixos90 During Contributor Day @gziolo and myself worked through this, at the end came up with an idea for a solution, which I implemented yesterday, in https://github.com/WordPress/gutenberg/pull/49904 and https://github.com/WordPress/wordpress-develop/pull/5104 (the two are kind of related but separate problems)
• This week’s Performance Bug Scrub lead, request for volunteer please
  • @joemcgill happy to run this weeks bug scrub (thank you!)

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath @swissspidy

• @joemcgill I spent some time prior to WCUS looking at #57789 and plan to pick that back up later this week as a part of a general focus on improving template loading
• @flixos90 working on https://github.com/WordPress/wordpress-develop/pull/5069, starting at Contributor Day and iterated yesterday. Will make another iteration today and then it should be ready for another review
• @swissspidy I had some great discussions at WCUS regarding i18n performance, people are really interested in testing this new feature plugin. The great news is that the plugin just got approved, so I’ll push it to WordPress.org later today or so. Then we can spread the word and start looking into adding it to Performance Lab (once we have the standalone modules) etc.

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones

• No updates this week

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein @westonruter

• @westonruter I backported the use of defer for block view scripts from Gutenberg to WordPress core (#59115). I did some more perf analysis and found a 6.5% reduction in TTFB-LCP
  • @flixos90 What scenario was that tested with? TT3 or another theme / configuration? (Details are in the Trac comment)
• @westonruter I also analyzed moving Twenty Seventeen’s scripts from the footer to the head and adding defer, but I didn’t find there to be any improvement
• @westonruter On the non-JS front, I did some more analysis on the impacts of inlining stylesheets instead of loading them externally, especially when a CDN is involved. I found inlining to be more important when a CDN is involved, but when a CDN isn’t involved, then better not to inline. The findings don’t seem to be entirely conclusive, however
  • @flixos90 I think this is an important learning worth sharing with the broader community. It has come up numerous times in the past that folks suggest to inline certain assets based on an assumption that that would be faster. But seems that’s more complicated than that
• @joemcgill I noticed that #58634 has a PR that could use a review. Otherwise, that one doesn’t yet have an owner
• @joemcgill Also, https://github.com/WordPress/gutenberg/discussions/53260 is an interesting conversation going on in the Gutenberg repo about using JS modules to better load scripts and styles async. Worth looking into and giving feedback.

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

• @pereirinha I do have clarification for #58893, and asked for another round of feedback on #58892. If I didn’t get it back to the right track, I might need a call to clear it up
• @flixos90 Update from me that is kind of related to images but actually has nothing directly to do with images is that I opened a can of worms at contributor day finding several bugs with how the WordPress main query loop (“the loop”) is being handled incorrectly by block themes in general, which has been causing problems such as https://core.trac.wordpress.org/ticket/58027

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy

• @swissspidy Just before WCUS I merged r56399 so that we now track TTFB & LCP in WordPress core performance tests
• @swissspidy Another PR to improve the core performance tests output is currently in review
  • @joemcgill I’m particularly interested in how we can get this into the CI workflow sooner rather than later, since folks on the Gutenberg side are finding it extra helpful. I think it will reduce the amount of manual work we end up doing benchmarks on individual PRs as well
  • @swissspidy Yeah I might remove the PR comment part if that’s a blocker. Jonathan offered to review it once he’s back from WCUS
  • @flixos90 Agreed, though I am slightly concerned by posting the results in a comment on each PR at this point. Given that the metrics are still rather unstable, I am wary of people over-interpreting them, e.g. arguing that a change is particularly great or problematic just based on numbers which could come from variance. So not a technical problem with the PR at all, but I’d feel more confident about implementing everything but the PR message, so that the data is there, just not as “alarmist”
  • @joemcgill I agree. I would like for there to be a way to contextualize the change related to expected variance so folks don’t get super excited about a small change that could just be noise
  • @flixos90 We could pull the PR message logic out, and then create a separate ticket with PR for “Future Release”
  • @swissspidy Yeah, there’s still some variability with those results, but that’s just GitHub. Adding an explanation to the comment makes sense. I like the PR because it is easier to discover than the summary, but it does require setting up a secret token for it to work, which is also not ideal when working with forks. (NB I did experiment with running Playwright browsers within Docker, so in the future that might help reduce variance.)
  • @joemcgill We can also tie that to the trac ticket (I’ll find it and thread it) that is about posting results from workflows – https://core.trac.wordpress.org/ticket/56150

Ecosystem Tools

Link to roadmap projects

Contributors: @mukesh27 @swissspidy @westonruter

• @mukesh27 Some minor update for Plugin Checker:
  • Bump WPCS to 3.0.0 – Merged
  • Add Spell Check action – Merged

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

• @flixos90 I had something to share kind of related to ecosystem tools: At Contributor Day, @chriscct7 shared https://plugintests.com/ with a few of us, which he had discovered at some point, and it’s just a mind blowing tool nobody seems to know about, covering the whole plugin repository in a lot of detail. Not sure what we can do with that at this point, but it’s just something quite interesting to look at and be aware of. It has e.g. PHP compatibility information for every plugin, detailed data on e.g. which options or admin screens a plugin adds, whether there are PHP or JS errors etc.
  • @joemcgill This is very cool https://plugintests.com/plugins/wporg/performance-lab/latest
• @icaleb There were talks, once upon a time, of integrating that same tech into the .org repo. I think various acquisitions got in the way – but definitely would be interesting to see what might still be possible!

Open Floor

• Reviews of #59224 and #59226
  • @joemcgill Two issues that seem like they need early eyes on. I see Andrew and Jonny are already reviewing, but would be good for others to have visibility
• @johnbillion Quick item from me, I’m planning on opening a ticket for implementing a function to bulk add metadata (starting with users), mostly a narrower scope version of #34848. I’ve recently been looking at various performance issues when inserting data into WP, hoping to tackle a few – PR review would be good, I’ll add the performance focus when I open the ticket later today

Our next chat will be held on Tuesday, September 5, 2023 at 15:00 UTC in the #core-performance channel in Slack.

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