Performance Chat Summary: 23 May 2023
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- 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
Contributors: @joemcgill @spacedmonkey @aristath
- @joemcgill I had hoped to have a summary of my performance analysis published last week, but a few people from whom I wanted to get feedback were out last week, so I expect to publish it in the next few days. In the mean time, it’s been nice to see that many of my observations already have related Trac tickets with progress being made to improve things.
- @spacedmonkey I have spent sometime mapping out server response time tickets to action, this is my list so far
- Files exists
- https://core.trac.wordpress.org/ticket/58342
- https://core.trac.wordpress.org/ticket/58319
- https://core.trac.wordpress.org/ticket/58196
- https://github.com/WordPress/gutenberg/pull/50636
- https://core.trac.wordpress.org/ticket/58384
- https://core.trac.wordpress.org/ticket/58385
- Term sanitization
- https://core.trac.wordpress.org/ticket/58329
- https://core.trac.wordpress.org/ticket/58327
- This is a pretty simple PR- https://github.com/WordPress/gutenberg/pull/50636 that halfs the number of calls to
get_block_theme_folders - If anyone is interesting to work on the above, feel free
Database Optimization
Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii
- @spacedmonkey Been looking into options.
- Need of code review
- https://core.trac.wordpress.org/ticket/55270
- https://core.trac.wordpress.org/ticket/58277
- So simple fixes to improve performance of options
- I also committed a number of allow on things to things I committed before, nothing major
JavaScript & CSS
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
@coversin 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: https://core.trac.wordpress.org/ticket/12009
- 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: https://github.com/10up/wordpress-develop/issues/63
Images
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 https://github.com/WordPress/wordpress-develop/pull/4439 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!
Measurement
Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27
- @joemcgill I created several tickets at the end of last week for improving the automated performance tesing workflow that we landed during the WP 6.2 release cycle:
- https://core.trac.wordpress.org/ticket/58358
- https://core.trac.wordpress.org/ticket/58359
- https://core.trac.wordpress.org/ticket/58360
- Since these are related to build/test tools, they can be done at any time and do not have to go in before the release cutoff. Also, the Gutenberg team is working on related improvements to their performance metrics, so there may be some opportunity to collaborate here: https://github.com/WordPress/gutenberg/issues/33645
Ecosystem Tools
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
Contributors: @flixos90 @mukesh27 @10upsimon
- No updates this week
Open Floor
- @spacedmonkey Going to re-share from last week – This discussion has been very active – https://github.com/WordPress/performance/issues/403
- 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 https://github.com/stuttter/ludicrousdb 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 – https://github.com/WordPress/performance/issues/526
- 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.
