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

Announcements

• Updated the cadence of bug scrubs to be every 2 weeks – next one scheduled for April 26, 2023 at 15:00 UTC.
• @flixos90 Also briefly sharing that I just published a performance retrospective post on WP 6.2 that I had been working on over the past few weeks: https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/
  It highlights some of the key aspects which changed in 6.2 in how we dealt with performance and also summarizes high level numbers. It can be seen as somewhat complementing https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/, at a higher level however without looking as much at specific improvements.
• Discussion regarding the decoupling of the SQLite plugin from the performance lab work. In reference to this conversation that came up in a previous performance chat. Would love to have an open discussion about peoples preferences here and whether we do decouple this?
  • @olliejones I favor that approach. It will usually be deployed independently of the stuff in PL.
  • @10upsimon I tend to lean more toward an agreement with @rmccue in that SQLite is not necessarily performance improvements focused (or at least that is not the primary goal), and probably belongs outside of the realm of the performance lab work.
  • @spacedmonkey To be clear, I think that performance team should continue to support SQlite getting into core, to much sure it done in a performant way. But SQlite is not a performance benefit on the face of it, so it is confusing why we part of performance lab plugin.
  • @rmccue Yeah, that was basically my thought; I think it’s beneficial all-round to separate it out (but with performance still consulting as @spacedmonkey says)
  • @olliejones yes, having SQLite headed for core is good. I believe the issue is about monorepo and multifunction plugins on the one hand and a separate repo and plugin on the other.
  • @aristath I agree with what was mentioned above 100%. SQLite can be related to performance, but is not in itself a “performance” module/plugin. It should be developed in collaboration with the performance team since it can have a big impact, but I’d vote to decouple it from the performance-lab plugin
  • @olliejones Maybe in a parallel universe or another year, there can be a separate database team. But for now the perf. team has the talent.
  • @spacedmonkey If you want to setup a meeting for a database team, that could work. Many component meetings have less than 5 people.
  • @flixos90 To clarify, this conversation is slightly different and mostly unrelated to the “unbundling Performance Lab plugin” effort. While we are publishing other PL modules as standalone plugins, those standalone plugins will still be directly associated with the performance team, developed in the monorepo, referenced from the PL main plugin etc. Removing / decoupling SQLite from PL would be different: We would still support getting the plugin towards WP core of course, but it wouldn’t be in any way connected to PL anymore. Maybe that was clear, but just in case.
  • Next steps clarification:
    • @aristath I think the only thing to do here would be to remove the module from PL, and add a notice so in case the user previously had the module activated, they’ll be prompted to install the standalone plugin
    • @joemcgill I assume we’ll remove the module from the performance lab plugin in the same release where we remove other modules. How we handle the transition so as to not break any active sites, is not clear to me at the moment.
    • @olliejones Do we have any usage telemetry to help guide that decision?
    • @flixos90 Potentially. As mentioned, I think this conversation is decoupled from the general PL unbundling effort, so we could do it at the same time, but also sooner. I would love to find a way to make the transition smooth though. For sites that already have the SQLite module active, we should probably recommend activating the SQLite plugin before deactivating the feature.
    • @aristath That’s a good idea…
    • @flixos90 Has anyone tried yet to activate the SQLite standalone plugin on a site where the PL SQLite module is already active? We need to make sure it doesn’t throw fatal errors
      • @aristath Adding it on my TODO list for tomorrow, though from what I recall I tried it last month and I there were no issues. I’ll need to test that again just to be sure, it’s been a long time
    • @10upsimon I feel strongly about not intentionally breaking users sites, however few are using it. Perhaps we need to defer the removal to 2 versions from now, and raise a notice or similar in the admin making it very clear that from version n it will no longer be supported as a core PL module.
      • @flixos90 agreed @10upsimon adding though that for a smooth transition the plugin should be activated before deactivating the PL module, so we have to make sure that that is actually possible
    • @joemcgill A similar transition plan will be good for all of the modules, to be honest, even though SQLite is the most critical due to potential breakage.
    • @flixos90 @joemcgill I think for the other modules we’ll handle that in a central effort as part of unbundling, but with SQLite it will now be bit different, since that plugin will not be referenced directly from PL in the future. But I agree it’s most critical there to have a smooth transition since switching back to a MySQL / MariaDB database accidentally will break any site that actually relies on SQLite right now

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

• @spacedmonkey I landed lazy loading term meta
  https://github.com/WordPress/wordpress-develop/commit/2c6bf77a9e7532c6ac3a03502b44d108cae86179
  • I hope to get comment meta in the next week.
    https://github.com/WordPress/wordpress-develop/pull/4128 – Code review welcome
  • Related to term meta, https://github.com/WordPress/wordpress-develop/pull/4259 also need code review
  • This saves around 15k calls to sanitise term function per page load
  • TLDR, there was no need to call get_term , we already had the term id, so just remove that
  • I also reviewed this – https://github.com/WordPress/wordpress-develop/pull/4097 (amazing work @oandregal)
  • @joemcgill This is a huge one that I had noticed in my profiling research, so nice to see this already addressed!
  • @10upsimon Call me cheesy, but 15% server time alone across many WP hosts is a positive contribution to the environment alone
  • @mukesh27 With all this improvement, 6.3 is faster than 6.2
    • @flixos90 Yeah, this alone will make block theme performance in 6.3 almost as much faster as it got faster in 6.2
  • @flixos90 Certainly the highest performance improvement in a single PR that I’ve seen so far
  • @joemcgill Worth noting that the 15% improvement on that PR is compared against WP 6.1.1, not the commit prior to that one, so it would be interesting to A/B against the commit prior (if I’m reading the workflow correctly)
    • @flixos90 No, the 15% is against today’s trunk. The original metrics on the PR are incorrect, but then I measured it against trunk and that’s where the 15% come from

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

• @olliejones I’ve been on the SQLite Object Cache, making it more useful for @spacedmonkey hopefully – Nothing on the bigger SQLite project.
• @spacedmonkey Not related to database, but object caching. I have been working WP CLI support new functionality object cache
  • https://github.com/wp-cli/cache-command/issues/79
  • https://github.com/wp-cli/cache-command/issues/80

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

• @10upsimon Regarding “Enhancing the WP Scripts API with a Loading Strategy”:
  • We’ve had a good amount of feedback and iteration on our draft PR
  • We’ve had some valuable feedback come in this week, so we’ll be addressing that with the goal of opening a PR against core later this week. Thanks @joemcgill @adamsilverstein and @westonruter for the invaluable feedback thus far (and to @spacedmonkey)
  • We’ve established a mostly approved documentation plan/roadmap, with slight ongoing tweaks thereto. Draft documentation and documentation updates can commence soon
• @flixos90 One more thing regarding JS & CSS, last week I opened https://github.com/WordPress/gutenberg/issues/49927 to optimize how block CSS is loaded in classic themes (it’s great in block themes, but not so much for classic themes, and we can probably improve that). There have been some great conversations on that. @aristath has pointed out a detailed code example with how we could improve this by printing inline styles per block type right before the first block of each type is rendered
  • @aristath If you have some capacity to work on a PR, I think that would be a great next step
  • @flixos90 If we can find a solution that works reliably, maybe we can eventually even change the default behavior so that it’s no longer opt-in but just works out of the box 
  • @spacedmonkey I have a PR for the above –  https://github.com/spacedmonkey/wordpress-develop/tree/try/inline-styles It might be useful in discovery

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

• No updates this week

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

• @joemcgill I’ve been working to prioritize a set of “next steps” for automated performance testing. For me, the “next step” is to turn these tasks into trac tickets that we can address as capacity allows.
  • One of the big ones is to improve the stability of the results and make them more atomic, so we can use them to evaluate specific PRs (like the discussion we had earlier about the get_block_templates PR)

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

• @joegrainger We’re still progressing through the issues raised in the Plugin Checker Milestone 1 Review/QA and will continue to be working on these over the coming weeks. You can follow the progress on the GitHub repo and any thoughts/ideas/comments are welcome. Thanks!
• @spacedmonkey Got some feedback from the community – https://github.com/10up/plugin-check/issues/153

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

• @flixos90 We’re still waiting to get the Fetchpriority standalone plugin approved, beyond that and then the same for Dominant Color, we have basically completed the work for “Milestone 1” in https://github.com/WordPress/performance/issues/656
  • We should probably close https://github.com/WordPress/performance/issues/661 following the conversation earlier, or we can break it out as another issue to discuss how to remove SQLite from PL
• @flixos90 Separately, we need to explore what we want the user experience for “Milestone 2” to look like, both in terms of the regular UI of the PL plugin going forward (in which it controls certain plugins as well as the Site Health modules), and for a smooth migration from the modules to remove to their standalone plugins

New Projects / Proposals

• @spacedmonkey I would love feedback on – https://github.com/WordPress/performance/issues/718 a new module proposal for adding object caching information to site health
  • I want to make it easier for users to understand what kind of object cache they are using and what features it supports.
  • Specially if your object cache drop in supports multiple gets. I got a lot of questions after this article was published.

Open Floor

• No updates

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

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