该材料的作者（我们今天将其翻译发表）说，他在2019年9月中旬终于完成了他从事了一年的项目。 该项目的目标是减小初始化Wikipedia异步JavaScript管道所需的清单的大小。 即，清单大小为36 Kb。 它必须小于28 Kb，这对应于Internet数据包序列的两个14 KB片段。
该项目的结果是每天节省4.3 TB的流量。
最初，清单大小超过36 Kb，经过优化后，其大小变得小于28 Kb该图显示清单大小逐渐减小。 我们谈论的是压缩数据（即网络上的净负载，这会导致从服务器到浏览器的数据传输）。
优化过程
初始化清单由不容易优化的数据表示。 他的大部分代码都不是可以通过传统方式优化的功能逻辑。 相反，几乎整个清单都由纯数据表示。 该数据由
ResourceLoader内容传送系统自动生成。 它们是模块捆绑软件的注册表。 Wikipedia使用ResourceLoader系统来处理JavaScript，CSS和文本资源。
该注册表包括Wikipedia上部署的所有前端功能的元数据。 清单列出了包的名称，它们的当前版本，它们对其他类似包的依赖关系。
我从寻找实际上从未使用过的代码开始（
T202154 ）。 这包括查找与遗留功能相关的不完整或被遗忘的代码段。 立即删除了未使用的代码，以确保与不再通过我们测试的浏览器兼容，从而确保将它们包含在现代浏览器组（
A级 ）中。 我还准备了有关页面加载性能的
文档 。 本文档作为参考，使开发人员可以了解各种类型的更改对页面加载过程各个阶段的影响。
减少模块数量
下一步是与Wikimedia Foundation和Wikimedia Deutschland的工程团队合作。 我们需要找出系统的哪些功能使用了过多的模块。 例如，已经了解了这一点，就有可能将先前分散的束组合在一起，从而从中构建某种功能。 这样的束即使在分散状态下也总是一起装载。 这将导致以下事实：系统中的终结点应较少，其元数据应存储在ResourceLoader形成的注册表中。
以下是有关应用此优化方法的一些有趣的观点：
- WikiEditor扩展现在比以前少了11个模块。 从UploadWizard中删除了另外31个模块。
- 优化ContentTranslation程序时，组合了24个模块。
- MobileFrontend项目包含25个模块。
- 从RevisionSlider和TwoColConflict中删除了20个模块。
优化用于Wikipedia的Wikidata客户端也非常重要。 这部分工作本身就是一个史诗般的项目（
T203696 ）。 最初，有248个单独的模块负责实施此功能。 在我们设法摆脱了200多个模块之后，只有42个模块。
上图显示了一年中对该项目进行的小改进。 所有这些使我们更加接近目标。 我尤其要注意清单的大小有两大下降。 这样的下降发生在八月的第一周。 那时就是部署了Wikidata的改进版本。 在图表的最末端可以看到第二个尺寸下降。 它发生在9月中旬。 现在，我想向您介绍一下他。
减少元数据大小
9月中旬发生的宣言方面的改进是由旨在针对更智能的数据组织的两项全局更改实现的。
第一个改进是，以前，
EventLogging扩展架构元数据是主要清单的一部分。 对该机制进行了重构，使其成为架构元数据，现在将其包含在EventLogging客户端的JS捆绑包中。 结果，EventLogging对早期清单大小的贡献减少了90％以上。 这意味着关键路径现在减少了2 KB的数据！ 此外，这意味着扩展EventLogging的功能不再导致清单大小的增加。 组装此类捆绑包时，使用了ResourceLoader的新功能，即
Package Files 。 此功能于2019年2月引入，引起人们兴趣的原因之一是它可以帮助减少注册表中的模块数量。 打包文件极大地简化了在单个模块中合并生成的数据和JavaScript代码的过程。
当我们减小每个注册表项的平均大小时，会发生第二个改进（
T229245 ）。 清单包含每个模块的两个条目。 这是模块的名称及其版本的标识符（ID）。 版本标识符以前需要7个字节的数据。 在考虑了ResourceLoader上下文中
的生日悖论之后，我们决定将版本ID的概率谱可以安全地从780亿降低到“仅” 6000万。 有关详细信息，请参见代码
注释 。 但是，总结这一改进，可以说，这使我们在仍在注册表中的1,100个模块的每个描述中节省了2个字节。 结果，清单的大小又减少了2-3 Kb。
下面是该图的放大片段，显示了操作的最后几天（这些指标取自综合监控系统，此处使用了未压缩的数据）。
在项目的最后阶段调整大小更改是由ResourceLoader监视系统捕获的。 屏幕快照显示了位于Grafana的公共实例中的“
启动清单”大小面板。 在这里，您可以看到未压缩数据流的大小减少了2.8 Kb。
该系统的部署于9月中旬进行，最终实现了最初的目标，即将清单压缩到不超过28 Kb的大小。 该大型项目的实施导致以下事实：初始化清单减少了9 Kb（我们正在谈论压缩数据）。 一年前，这个大小是36.2 Kb，在项目完成之后，它已经是27.2 Kb。
维基百科和相关项目每分钟产生约363,000个页面浏览量。 一小时内-2100万和80万。 每日-5.23亿（
这是网页浏览量
的统计信息）。 该版本的系统已于9月中旬部署，导致每天节省约1.4 TB的流量。 并且，如果将今天的情况与一年前的情况进行比较，可以发现现在每天可以节省4.3 TB的流量。
接下来是什么？
我们设法适合28 Kb Wikipedia初始化清单。 选择该大小是因为它是最小大小（14 Kb的倍数）的事实。 可以将这种大小的数据放在传输到浏览器
的 Internet数据包
序列的片段中。
现在，我们面临一项新任务：不放弃职位。 去年，我一直在密切关注
宣言 。 我这样做是为了确保我们的成功并发现使我们退缩的潜在问题。 最后，我使用公共
Grafana仪表板自动化了此过程。
如果您相信这个专家组，那么我们仍然有很多机会来改进代码的包装，并解决比现在更强大的问题，从而促进捆绑的创建。 我希望这些即将到来的改进对我们有用，但是到目前为止，我们正在努力开发系统的新功能，同时努力满足项目绩效水平的要求。
亲爱的读者们！ 您是否曾经参与过大型Internet项目的优化？
