WordPress性能团队正在努力实现Performance Lab插件的解绑

WordPress的性能团队本周开会，明确的目的是回应Matt Mullenweg最近提出的要求，即停止向Performance Lab插件添加功能，否则这些功能可以作为一个独立的插件使用。

在2022年12月底，性能团队发布了如何测试新的SQLite实现的说明，该功能作为一个模块被捆绑在Performance Lab插件中。Mullenweg对该帖子进行了评论，表示他认为SQLite功能更适合成为一个独立的社区插件。

我们能不能把它变成自己的社区插件，希望能成为一个规范的插件，而不要再把这样的额外东西放到Performance Lab中–感觉我们在不必要地把东西塞进PL。

10月中旬，我和@tweetythierry一起要求停止这种不必要的捆绑，因为WebP被放到了Performance Lab中，所以另一个像SQLite这样的大型功能被捆绑到Performance Lab插件中，这令人失望。

为了给即将到来的性能特征激励一批测试人员，性能团队倾向于将新的性能相关功能捆绑到插件中。尽管它们已经被开发成独立的模块，所以它们可以很容易地作为单独的插件被提取出来，但人们担心的是它们的可见度会被大大降低。Performance Lab插件有超过3万个活跃的安装。任何独立的插件都需要时间来建立用户群，而添加到Performance Lab中的功能则可以立即获得受众。

“性能团队的贡献者Thierry Muller在回应松绑请求时说：”我同意独立插件肯定有有效的用例，但仍然注意到单个中心插件的一些优势，如开发/维护、采用、推广、开发人员入职/贡献等，而Performance Lab作为一个关注性能的中央社区中心插件，今天很好地促进了这些优势。

Muller概述了贡献者在本周的性能团队会议上讨论的三种不同方案。

• 方案1：保持PL的原样，但另外将模块部署为单独的插件
• 方案2：将PL作为一个 “包装器”，专注于中央基础设施和单个插件的推荐。
• 方案3：完全废除PL，支持单独的插件

对于那些参与本周讨论的人来说，方案3似乎是最没有吸引力的，因为它为可发现性引入了更多障碍。性能团队的贡献者Felix Arntz指出，方案1的一个好处是，对于目前安装了该插件的30K人来说，该插件将继续按原样工作，而方案2 “将需要一个复杂的迁移，用户可能不会理解。”

WordPress开发人员Jonny Harris建议，将每个功能放在自己的插件中有助于测试，但也问到什么是模块的定义。

“比如说，目前的网站健康检查会不会都在一起？” 哈里斯问道。”SQLite和WebP显然是它们自己的模块，但更小的东西呢？”

Arntz建议贡献者继续讨论如何将目前的模块作为插件分发的范围。他建议每个模块都可以成为自己的插件，其中一些模块成为独立的插件，而另一些则被归纳为几个 “特定主题 “的插件。

贡献者们正在GitHub问题上更详细地讨论不同的方法，并将对最佳方法进行投票。投票将持续到2023年1月20日（星期五）。