WordPress’ Performance Team met this week with the express purpose of responding to Matt Mullenweg’s recent request to stop adding functionality to the Performance Lab plugin which could otherwise work as a standalone plugin.
At the end of December 2022, the Performance Team published instructions for how to test the new SQLite implementation, which was bundled into the Performance Lab plugin as a module. Mullenweg commented on the post, indicating he saw the SQLite functionality as better suited to becoming a standalone community plugin:
Can we please make this its own community plugin, hopefully to become a canonical one, and stop putting additional things like this into Performance Lab — it feels like we’re stuffing things into PL unnecessarily.
In mid-October I have requested that we stop this unnecessary bundling before with @tweetythierry around WebP, which was put into Performance Lab, so it is disappointing that another large function like SQLite was bundled into Performance Lab plugin.
In an effort to galvanize a base of testers for upcoming performance features, the Performance Team has leaned towards bundling new performance-related functionality into the plugin. Although they are already developed as self-contained modules so they can be easily extracted as individual plugins, the concern is that their visibility would be greatly reduced. The Performance Lab plugin has more than 30,000 active installs. Any standalone plugin would take time to build up to a user base, whereas functionality added to Performance Lab has an instant audience.
“Agreed that there are definitely valid use cases for stand alone plugins, remaining mindful of some of the advantages of a single hub plugin such as development/maintenance, adoption, promotion, developer onboarding/contribution etc. which the Performance Lab facilitates well today as a central performance focus community hub plugin,” Performance Team contributor Thierry Muller said in response to the unbundling request.
Muller outlined three different options contributors discussed in this week’s Performance Team meeting:
- Option 1: Keep PL as is, but additionally deploy modules as individual plugins
- Option 2: Make PL a “wrapper” focused on central infrastructure and recommendation of individual plugins
- Option 3: Deprecate PL completely in favor of individual plugins
Option 3 seems to be the least attractive to those who participated in this week’s discussion, as it introduces more hurdles for discoverability. Performance Team contributor Felix Arntz noted that one benefit of option 1 is the plugin would continue to work as-is for the 30K people who currently have it installed and that option 2 “would require a complex migration that users likely would not understand.”
WordPress developer Jonny Harris suggested that having each functionality in its own plugin helps with testing but also asked what defines a module.
“Would the current Site Health checks all be together, for example?” Harris asked. “SQLite and WebP are clearly their own modules, but what about smaller things?”
Arntz suggested contributors continue the discussion regarding the scope of how the current modules could be distributed as plugins. He suggested every module could become its own plugin where some modules become standalone plugins and others would be grouped together into a few “topic specific” plugins.
Contributors are discussing the different approaches in more detail on a GitHub issue and will be voting on the best approach. The vote will be open until Friday, January 20, 2023.