WordPress 的性能团队本周召开了会议，明确目的是响应 Matt Mullenweg 最近提出的停止向Performance Lab插件添加功能的请求，否则该插件可以作为独立插件使用。
2022 年 12 月底，性能团队发布了有关如何测试新 SQLite 实现的说明，该实现作为一个模块捆绑到Performance Lab插件中。Mullenweg 对该帖子发表了评论，表示他认为 SQLite 功能更适合成为一个独立的社区插件：
我们能不能把它做成自己的社区插件，希望成为一个规范的插件，并停止将像这样的额外东西放到 Performance Lab 中——感觉我们把东西塞进 Performance Lab 是不必要的。
在 10 月中旬，我要求我们停止这种不必要的捆绑，之前与 @tweetythierry 围绕 WebP 进行了捆绑，它被放入了 Performance Lab，因此令人失望的是另一个像 SQLite 这样的大型函数被捆绑到 Performance Lab 插件中。
为了激发一批测试人员使用即将推出的性能功能，性能团队倾向于将与性能相关的新功能捆绑到插件中。尽管它们已经作为独立模块开发，因此可以作为单独的插件轻松提取，但担心的是它们的可见性会大大降低。Performance Lab 插件有超过 30,000 个活跃安装。任何独立的插件都需要时间来建立用户群，而添加到 Performance Lab 的功能会立即吸引用户。
“同意独立插件肯定有有效的用例，仍然注意单个集线器插件的一些优势，例如开发/维护、采用、推广、开发人员入职/贡献等，Performance Lab 今天很好地促进了这些优势一个以性能为中心的社区中心插件，”Performance Team 贡献者 Thierry Muller在回应分拆请求时说。
Muller 概述了本周绩效团队会议上讨论的三个不同的选项贡献者：
- 选项 1：保持 Performance Lab不变，但另外将模块部署为单独的插件
- 选项 2：让 Performance Lab 成为一个“包装器”，专注于中央基础设施和个别插件的推荐
- 选项 3：完全弃用 Performance Lab 以支持单个插件
对于参与本周讨论的人来说，选项 3 似乎是最没有吸引力的，因为它为可发现性引入了更多障碍。Performance Team 贡献者 Felix Arntz 指出，选项 1 的一个好处是该插件将继续按原样为当前安装它的 30,000 人工作，而选项 2“将需要用户可能不理解的复杂迁移。”
WordPress 开发人员 Jonny Harris 建议将每个功能都放在自己的插件中有助于测试，但也询问了模块的定义。
“例如，当前的站点健康检查是否会全部在一起？” 哈里斯问道。“SQLite 和 WebP 显然是它们自己的模块，但是更小的东西呢？”
Arntz 建议贡献者继续讨论当前模块如何作为插件分发的范围。他建议每个模块都可以成为自己的插件，其中一些模块成为独立的插件，而其他模块将组合在一起成为一些“特定主题”的插件。
贡献者正在 GitHub 问题上更详细地讨论不同的方法，并将投票选出最佳方法。投票将持续到 2023 年 1 月 20 日星期五。
