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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe
  • Agreed to keep the June 6 meeting

Priority Projects

Server Response Time

Link to roadmap projects

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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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

Link to roadmap projects

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

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. & CSSCSS Cascading Style Sheets.

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

• @10upsimon Enhancing the Script APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 ticketticket Created for both bug reports and feature development on the bug tracker.: 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

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 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

Link to roadmap projects

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 GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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

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 – 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party), or does this need to be a direct to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.. 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 hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. 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