Performance Chat Summary: 24 January 2023

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


  • None this week

Focus area updates


@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein not much to update from my end this week. I have been mostly thinking about/planning for WordCamp Asia & contributor day, coming up with a plan for that. I’d love feedback about good ways to engage new contributors on performance

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested



GitHub project

  • @joegrainger: been away for a few days but have been making progress on the Plugin Checker infrastructure. Still more to be done, but you can see the work carried out here (we’re developing the project here, but will be eventually moved to the WordPress organisation).
  • The plugin checker will be run through both the CLI and the WP Admin. Feel free to take a look at the issues and leave thoughts/ideas you may have

Feedback requested


@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested



GitHub project

  • @aristath Last week, SQLite was released as a stand-alone plugin. No announcement action etc was taken. I left that TBD so we can coordinate our policy and strategy as a performance team. The submission was done early to get a head-start with the plugin review process etc – which made sense since this was a direct request from Matt.
  • The repo for the stand-alone plugin was moved to the WordPress organization on GitHub
  • The call-for testing post was updated to include links both to the PL plugin as well as the stand-alone plugin.
  • @olliejones Ari released the SQLite DBMS engine integration as a standalone plugin   … And I assume we’ll take up during the open-floor time
  • @olliejones The SQLite DBMS project is going to require large-scale testing to get to beta status
  • @spacedmonkey asked where is the best place to provide feedback for this plugin – best course of action to create an issue here
    • @flixos90 Note that we now have both the separate GitHub repo and the module in the PL GitHub repo, so we need to figure out how to handle that. The duplicate code between those 2 repos is certainly not good
    • @spacedmonkey noticed that cache values were not being set

Feedback requested



GitHub project

  • @flixos90 No recent updates, however I opened yesterday. What I’m proposing in that issue is to bump the minimum version requirement of Performance Lab to WordPress 6.1. This will allow us to remove the two Site Health cache modules that were already launched in WordPress 6.1, which at this point are a bit of unnecessary baggage to still have in there
  • Note that per our version support policy our commitment is to only support the latest WordPress release anyway, so this should be okay
  • Discussion around plugin versioning:
    • @flixos90 I see there’s a suggestion by @joemcgill to potentially have a 1.10.0 with that code being deprecated first. I don’t think that would help here. FWIW, the modules are already not loaded today when you have WP 6.1. So nothing changes for you either way when they’re removed:

Feedback requested

Open Floor

  • @olliejones discussed the module proposal for SQLite Persistent Object Cache
    • It’s a standalone plugin. Does it make sense to build it into PL, to put it onto a track to go into core?
    • @spacedmonkey I think it needs to live as a plugin for a while
    • @flixos90 A bit of a tricky question. Of course we are working towards unbundling the PL plugin. But we’re still pending a decision on how exactly, and at this point it may make sense in the PL plugin. Is it already published on or not?
    • @olliejones Absolutely live as a plugin.  There’s no other way to get decent field experience. And this kind of thing requires field experience.
    • @spacedmonkey I want to test it on bigger sites, multisite, ensure cache invalidation works, support wp_cache_get_multiple and some other stuff
    • @olliejones
    • Yes, published, If it goes into PL, we’ll need to sort out the use of the object-cache.php drop-in module.
    • @flixos90 Okay, we should definitely keep it published like that then. I think at this point, let’s just keep it like that? We could potentially add it as a PL module too, but depending on the path decided on for unbundling the PL plugin, that would just be unnecessary work – so probably most efficient (until we have a decision) to work in its own repo for now
  • @spacedmonkey discussed the Trac ticket for making php 7.2 the minimum version of support php in WordPress and asked if this is something we should be pushing for as the performance team
    • @olliejones I say yes, smaller QA matrices are always good
    • @joemcgill It could certainly have some positive performance implications, though I’m not sure how much impact we would have since the process for bumping versions is pretty well established (unless I’m wrong). It would be nice to help support that effort with some evidence about the performance benefits from any automated testing we do against different versions.

Our next chat will be held on Tuesday, January 31, 2023 at 16:00 UTC in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#core-performance, #meta

Leave a Reply

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