Google chrome 用于静态资源的Brotli

我最近在我们使用的一个CDN平台上启用了Brotli压缩。由于资源大小减少了15-30%，因此我希望性能会有所提高，但令我惊讶的是，性能仍然保持不变

我确实检查了各种指标，除了ttfb，所有指标看起来都一样，我看到每个资源增加了10-15毫秒

---

以前有人见过这个问题吗？如果有，解决这个问题的最佳方法是什么？我还怀疑当chrome的brotli版本比Gzip版本解压资源所需的时间更长，但不幸的是，我没有任何方法来衡量这段时间。

没有足够的细节来回答这个问题。性能是相对的，因此Brotli带来的收益可能会被网站更大的性能问题所淹没

有些问题需要你自己回答：

• Brotli的设置是否正确且有效？您能否将

  br

  视为开发人员工具网络选项卡中的内容编码？注意：您可能需要添加内容编码列
• 您是否在站点上使用HTTPS（所有浏览器都需要使用Brotli）？您是否在迁移过程中迁移到HTTPS
• 启用Brotli后，站点的总体大小是否降低了？如果是的话，增加多少？如果您的站点上有大量10Mb打印质量的图像，并且您已经将HTML从50kb更改为45kb，那么您可能看不到整体差异
• 生成页面需要多长时间？如果您的页面需要30秒才能生成，因为HTML是动态的，而您的后端（应用程序服务器、数据服务器等）速度很慢，那么29.5秒似乎不会太长
• 你有很多渲染块CSS和JavaScript吗。这些都是文本，所以希望现在可以更快地交付，但是如果它们非常复杂，并且客户端的处理时间很长，那么下载时间可能是其中微不足道的一部分
• 您是否坐在距离数据中心50米的地方，通过高速1000Mbps以太网连接（基本上直接与web服务器通信）在公司办公室进行测试？如果是这样的话，无论下载量有多大，下载速度都可以忽略不计

Brotli应该将文本压缩得更小。与gzip相比，进行压缩可能需要更长/更多的处理能力，但相对于CPU成本而言，网络收益通常是值得的

---

然而，这并不是魔术，也无法弥补网站上的其他性能问题。

感谢@barry pollard的回答——是的，brotli设置正确，我可以看到br作为内容编码——每个资源的总体大小平均下降了约15-20%。-我有来自世界各地的用户在使用该应用程序，数据中心的延迟也各不相同，因此我肯定会为坐在远处的用户带来一些收益。对于其余的建议，我将看一看，并在这里再次发布我的发现