I've been thinking about Matt's pushback on webp and SQLite. I think he's right (not that it matters much what I think). Here's an approach that might work.
Problems to solve
- Matt objects to Performance Lab's approach of bundling various proof-of-concept experiments in a single plugin. He has stated that he prefers "canonical plugins" for such things as webp support and SQLite database support.
- It's not clear what "canonical plugin" means. The Classic Editor plugin might be an example of that, but it's not called that.
- Techniques for performance improvement exist that don't apply uniformly to all WordPress installs. Therefore, there may be ways to add value to the overall ecosystem without insisting that all @core-performance work be destined for core inclusion.
- Hosting providers' site reliability teams likely want features and hooks in performance-oriented code.
- There's a lot of great work in Performance Lab, which should not be lost.
Observations
Matt seems to favor limited-scope plugins that do one thing well, rather than kitchen-sink plugins that do a lot of things. That is a viable approach. But there's one hazard: each plugin has overhead, so there's a performance cost to having multiple plugins.
The present Performance Lab plugin has a lot of stuff in it. Much of it adds sophisticated Site Health checks, but it also has a variety of operational features.
Suggested course of action
- Define "canonical performance plugin" and socialize that definition -- get at least some buy-in from the Plugins team, other teams and Matt.
- Work out, test, and publish guidelines for plugins themselves, to reduce the many-plugins performance penalties.
- Adapt the Module Proposal process to serve as a Canonical Performance Plugin Proposal process.
- Create a canonical plugin for webp handling
- Create a canonical plugin for @aristath's SQLite compatibility work.
- Refocus Performance Lab on Site Health.
Benefits, issues
- Benefit: These Canonical Performance Plugins can be completed and published, saving regression-test effort.
- Benefit: Hosting providers may see benefits from sponsoring developers to work on these plugins.
- Issue: Is it worthwhile to broaden the scope from "Canonical Performance Plugins" to "Canonical Plugins"?
I've been thinking about Matt's pushback on webp and SQLite. I think he's right (not that it matters much what I think). Here's an approach that might work.
Problems to solve
Observations
Matt seems to favor limited-scope plugins that do one thing well, rather than kitchen-sink plugins that do a lot of things. That is a viable approach. But there's one hazard: each plugin has overhead, so there's a performance cost to having multiple plugins.
The present Performance Lab plugin has a lot of stuff in it. Much of it adds sophisticated Site Health checks, but it also has a variety of operational features.
Suggested course of action
Benefits, issues