Performance Chat Summary: 25 April 2023

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


  • 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: 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,
    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

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

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


Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • No updates this week


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

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
  • @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 – 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

Leave a Reply

Your email address will not be published. Required fields are marked *