Performance Chat Summary: 23 May 2023

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


  • The Performance Lab plugin reached 70k active installations this week
  • Decision on whether to hold the meeting June 6 ahead of travel around WordCamp Europe
    • Agreed to keep the June 6 meeting

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @10upsimon Enhancing the Script API with a loading strategy:
    • Merged @westonruters PR which massively improves how we handle inline script loading
    • Hoping to merge @westonruters PR for removal of $args normalization and flattening of that data, hopefully today
    • Looking for review on adding @covers  in this PR@spacedmonkey if you have a min that would be great
    • Ongoing smaller iterations to the PR as we work through some comms around async handling
    • No further updates at this stage
  • @joemcgill That mostly covers it, I think. I’m seeing lots of progress on this effort over the last few weeks. We’ve got lots of great feedback and continue to discuss specifics about the proposal on the Trac ticket:
    • As @10upsimon said, one of the last remaining issue that we’re trying resolve is making sure we’re all on the same page about how to best handle inline scripts, as there has been some disagreement about the best path forward there. Conversation about that topic is happening in this issue:


Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @joemcgill Nothing from me either, though I know I’ve seen some updates to improving lazy loading landing over last week.
  • @flixos90 I committed the 4th out of 5 lazy-loading fixes for 6.3 yesterday, and the last PR looks like it’s close as well. @Jonny Harris You previously requested changes, could you give it another look please?
    • Also anybody else’s feedback would be much appreciated!


Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger For the Plugin Checker, we are working on the final issue that came out of the Review/QA. Once done, we’ll be doing some testing to make sure everything is working as expected and start working towards an initial release. You can follow the progress on the GitHub repo here. Thanks!

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

  • No updates this week

Open Floor

  • @spacedmonkey Going to re-share from last week – This discussion has been very active –
    • Worth looking into as team ^
    • @joemcgill Is this something that could be handled in a performance lab module (or other plugin), or does this need to be a direct to core proposal?
    • @spacedmonkey I think this one would directly in core. If you want to do this, you can already do it in a plugin…
    • @joemcgill Got it. So, it seems we either need to decide if it’s worth us pursuing a “canonical” version of this plugin that is supported by this team. If not, I think it would be better for this conversation to move from the performance repo and directly to the related Trac ticket. (Also, this is just like, my opinion)
    • @spacedmonkey Personally I am not sure if we should do this in core.
    • This plugin will do the functionality they ask for It is a “canonical” plugin for a lot of advanced database functionality.
    • @johnbillion I can’t see any performance figures anywhere in that ticket, are there any? Lots of theoretical discussion but no numbers
    • @spacedmonkey good point
    • @joemcgill I don’t want to discourage the folks who want to work on this, but if it’s not something this team wants to commit to supporting, then we should politely close the proposal and redirect them to other channels, like Trac or a standalone plugin.
    • @spacedmonkey We need number to validate and an updated patch. Without that, it will have to go to the backlog
  • @westonruter I know there is a problem of orphaned autoloaded options, where plugins add options but don’t clean up after themselves upon uninstall. I know we also have an Autoloaded options Site Health test.
    • Maybe this has already been discussed, but what if the test were extended to check for autoloaded options that aren’t being used anymore?
    • Granted, this wouldn’t need to be a Site Health test and could instead be a cron job.
    • Consider a job that runs once a week which hits the homepage and the most recently-published post, and when running pass a query arg to capture all calls to get_option()
    • @spacedmonkey I am currently writing a document, where I suggest this.
    • @spacedmonkey Have you read this –
    • TDLR, this hooks into get_option and tracks what is used on a page load. It when stores an array of used options and then can be used to reset options that are autoloaded but not used.
    • There is a possible of setting autoload no to options that are needed for other parts of WordPress, like sitemaps, rss feeds, rest apis, or the cms
    • There is a chance we could tank performance on some page types and improve it on others.
    • @westonruter Yeah, would need to hit the important endpoints and capture the used options for each
  • @joemcgill I wanted to note that the submission deadline for WCUS is later this week, and it would be great to have good representation from this team. Curious if anyone else is planning to submit anything and if so, I’d be happy to support folks with feedback or idea development this week.

Our next chat will be held on Tuesday, May 30, 2023 at 15: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 *