Speed Week 期间，我们已经讨论了优化性能的重要性。压缩可减小在互联网上传输的文件大小，发挥着至关重要的作用。压缩文件越少，下载速度越快，网站加载速度越快，用户体验更佳。
以家庭清洁产品为例。据估计，“一瓶典型的清洁剂中有 90% 的水，实际有价值的成分不到 10%。” 从典型的 500 毫升瓶装家庭清洁剂的的 90％，其重量从 600 克减少到 60 克。这样做意味着只需要发送一个 60 克的包裹，并附上重新添加水的说明。将这种削减扩大到加仑，很快就会为企业带来巨大的运输节省，更不用说对环境的影响了。
这就是压缩的工作原理。发送方将文件压缩到最小可能的大小，然后发送较小的文件并提供有关接收后如何处理它的说明。通过减小发送的文件大小，压缩确保发送文件所需的带宽量大大减少。如果文件存储于例如 AWS 的昂贵云服务提供商，减小发送的文件大小可以直接等同于节省带宽的显著成本节约。
较小的文件大小尤其有利于互联网连接有限的终端用户，例如在蜂窝网络上的移动设备或在网络速度较慢地区的用户。
Cloudflare一直支持 Gzip 压缩。Gzip 是一种广泛使用的压缩算法，自 1992 年以来一直存在，为所有 Cloudflare 用户提供文件压缩。然而，Google 在 2013 年推出了 Brotli，它支持更高的压缩级别，并且整体性能更好。从 Gzip 切换到 Brotli 会使网页文件更小、加载时间更快。我们自 2017 年起就支持在 Cloudflare 和客户端浏览器之间使用 Brotli。今天，我们宣布支持端到端 Brotli 压缩：支持从源服务器到客户端的最高级别 Brotli 压缩。
如果您的源服务器支持 Brotli，请打开它，提高压缩级别，并享受性能提升。
将 Brotli 压缩提高到 11 级
Brotli 有 12 个压缩级别，从 0 到 11，其中 0 提供最快的压缩速度但压缩比最低，而 11 提供最高的压缩比但需要更多的计算资源和时间。在 5 年前最初实施 Brotli 时，我们确定 4 级压缩 提供了节省字节和压缩时间的平衡，而不会影响性能。
自 2017 年以来，Cloudflare 针对所有可压缩的资产，根据最终用户的“accept-encoding”标头，使用最大 4 级 Brotli 压缩。然而，一个问题是 Cloudflare 仅从源请求 Gzip 压缩，即使源支持 Brotli。此外，Cloudflare 总是解压从源接收到的内容，然后将其压缩发送到最终用户，导致额外的处理时间。因此，客户无法充分利用 Brotli 压缩所提供的好处。
旧世界
现在，由于 Cloudflare 完全支持端到端的 Brotli 压缩，客户将开始看到我们更新的“accept-encoding”标头到达他们的源。一旦可用，客户可以直接将高度压缩(最高的 11 级)的 Brotli 文件传输、缓存和提供给我们。这将有助于减少延迟和带宽消耗。如果最终用户设备不支持 Brotli 压缩，我们将自动解压文件，以解压缩格式或 Gzip 压缩文件的形式提供，具体取决于 Accept-Encoding 标头。
完全端到端 Brotli 压缩支持
最终用户不支持 Brotli 压缩
客户可以通过参考适当的在线资料在其源上实现 Brotli 压缩。例如，使用 NGINX 的客户可以按照这个教程按如下方式在其`nginx.conf` 配置文件中设置 11 级压缩：
brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript text/xml
application/xml application/xml+rss text/javascript image/x-icon
image/vnd.microsoft.icon image/bmp image/svg+xml;
然后，Cloudflare 将以完全相同的压缩级别(11)为匹配文件 brotli_types 向客户端提供这些资产。这意味着任何 SVG 或 BMP 图像都将以 Brotli 11 级压缩发送到客户端。
测试
我们对一个简单的 CSS 文件应用了压缩，并测试了不同压缩算法和级别的影响。我们的目标是通过优化压缩技术来确定用户可能体验到的潜在改进。这些结果可以在以下表格中看到：
| 测试 | 大小(字节数) | 原文件的减少百分比(越高越好) |
|---|---|---|
| 未压缩的响应(未使用压缩) | 2,747 | - |
| Cloudflare 默认 Gzip 压缩 (8 级) | 1,121 | 59.21% |
| Cloudflare 默认 Brotli 压缩 (4 级) | 1,110 | 59.58% |
| 使用最大 Gzip 级别压缩(9 级) | 1,121 | 59.21% |
| 使用最大 Brotli 级别压缩(11 级) | 909 | 66.94% |
通过压缩到 Brotli 11 级，用户可以将文件大小比最佳 Gzip 压缩级别减少 19%。此外，最强的 Brotli 压缩级别比 Cloudflare 默认使用级别将文件大小减少约 18%。这凸显了利用 Brotli 压缩可显著减少文件大小，特别是在其最高级别下，从而提高网站性能、加快页面加载时间并减少总体出站费用。
为了利用更高的端到端压缩率，需要禁用以下 Cloudflare 代理功能。
- Email Obfuscation
- Rocket Loader
- 服务器端排除(SSE)
- Mirage
- HTML 最小化 — JavaScript 和 CSS 可继续启用。
- Automatic HTTPS Rewrites
这是因为 Cloudflare 需要解压缩并访问主体部分以应用请求的设置。或者，客户可以使用配置规则为特定路径禁用这些功能。
如果启用了这些重写功能之一，您的源仍然可以更高的级别发送 Brotli 压缩。但是，我们将实时解压、应用启用的 Cloudflare 功能，并使用 Cloudflare 的默认 Brotli 4级或 Gzip 8 级重新压缩，具体取决于用户的 accept-encoding 标头。
对于不接受 Brotli 压缩的浏览器，我们将继续解压缩并发送 Gzip 响应或未压缩的响应。
实施
要实现来自源的 Brotli 压缩，初始步骤涉及构建一个解压缩模块，该模块可以集成到 Cloudflare 软件堆栈中。它允许我们将从源接收到的压缩字节高效转换为原始、未压缩文件。这一步骤非常关键，因为许多功能 (例如 Email Obfuscation 和 Cloudflare Workers)都依赖于访问响应正文以应用自定义设置。
我们将解压器集成到 Cloudflare 核心反向 Web 代理中。这种集成确保所有 Cloudflare 产品和功能都可以轻松地访问 Brotli 解压缩。这也使我们的 Cloudflare Workers 团队能够直接将 Brotli 纳入 Cloudflare Workers 中，使我们的 Workers 客户能够与以 Brotli 返回的响应交互，或者直接传递给最终用户而不进行修改。
推出压缩规则 —— 精细化控制到最终用户的压缩
默认情况下，Cloudflare 根据文件的 Content-Type 标头压缩某些内容类型。今天，我们还宣布面向 Enterprise 客户的压缩规则，以允许您进一步控制 Cloudflare 将如何压缩和压缩什么内容。
今天，我们还宣布推出面向 Enterprise 客户的压缩规则。通过压缩规则，您可以获得对 Cloudflare 压缩能力的增强控制，使您能够自定义 Cloudflare 压缩哪些内容以及如何压缩，以优化网站的性能。
例如，通过使用 Cloudflare 针对 .ktx 文件的压缩规则，客户可以优化在 WebGL 应用程序中纹理的交付，从而增强整体用户体验。启用压缩可以最大限度地减少带宽使用，并确保 WebGL 应用程序快速流畅地加载，即使处理大型、详细纹理时也不例外。
客户也可以禁用压缩或指定有关我们如何压缩的偏好。另一个例子可能是，基础设施公司只想支持其物联网设备的 Gzip 压缩，但允许所有其他主机名使用 Brotli 压缩。
压缩规则使用我们其他规则产品所使用的过滤器，并增加了媒体类型和扩展类型字段。这允许用户可以轻松指定要压缩的内容。
弃用 Brotli 切换
自 2016 年以来，一些 Web 浏览器长期支持 Brotli，而 Cloudflare 自 2017 年开始支持 Brotli。与所有新的 Web 技术一样，当时 Brotli 是未知的，我们通过 API 和用户界面向客户提供了选择性启用或禁用 Brotli 的能力。
如今，Brotli 已经演变并得到了所有浏览器的支持，我们计划在未来几个月默认在所有区域启用 Brotli。这与我们当前支持的 Gzip 行为相同，并从我们的仪表板中删除了切换。如果浏览器不支持 Brotli，则 Cloudflare 将继续支持其接受的编码类型，例如 Gzip 或不压缩，企业客户仍将能够使用压缩规则，以精细化控制我们如何向其用户压缩数据。
Web 压缩的未来
我们已经看到 Brotli 作为新的 Web 压缩技术得到了广泛的采用，并具备优秀的性能。展望未来，我们正在密切关注趋势和新的压缩算法，例如 zstd，作为可能的下一代压缩算法。
与此同时，我们正在寻求直接改进 Brotli 的方法。我们特别关注的一个发展是与 Brotli 共享字典。无论何时压缩资源，都要使用“字典”来帮助提高压缩效率。一个简单的类比是在 iPhone 消息中输入 OMW。iPhone 会使用自己的内部词典自动将其翻译成 On My Way。
| O | M | W | ||||||
|---|---|---|---|---|---|---|---|---|
| O | n | M | y | W | a | y |
这个内部字典将3 个字符转换成 9 个字符(包括空格)。内部字典节省了 6 个字符，这为用户提供性能上的好处。
默认情况下，Brotli RFC 定义了一个客户端和原始服务器都使用的静态字典。静态字典被设计成通用的，适用于所有人。优化字典的大小，使其不会太大，同时能够产生最佳的压缩结果。然而，如果一个源可为某个特定网站生成一个定制字典呢？例如，Cloudflare 专用词典将允许我们压缩在网站上反复出现的单词和短语，例如 “Cloudflare”。定制的词典将被设计成尽可能地压缩这些内容，而使用相同词典的浏览器将能够把这些内容翻译回来。
Web Incubator CG 的一份新提案旨在做到这一点，允许您指定自己的字典，以便浏览器用来对网站做进一步的优化压缩。我们很高兴能为这个提案做出贡献，并计划不久后发表我们的研究。
马上试试吧
压缩规则现已可用！端到端 Brotli 压缩将在未来几周内推出。允许您提高性能，减少带宽，并精细地控制 Cloudflare 如何处理到最终用户的压缩。