Performance Chat Summary: 25 April 2023

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


  • Updated the cadence of bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 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 Plugin Directory or can be cost-based plugin from a third-party 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 deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 adminadmin (and super 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 MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. / 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
    • I hope to get comment meta in the next week. – Code review welcome
    • Related to term meta, 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 – (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 blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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

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. & CSSCSS Cascading Style Sheets.

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @10upsimon Regarding “Enhancing the WP Scripts 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”:
    • 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 JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. & 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 tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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 UIUI User interface of the PL plugin going forward (in which it controls certain plugins as well as the Site Health modules), and for a smooth migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. 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