![All the way up to 11: Serve Brotli from origin and Introducing Compression Rules](https://blog.cloudflare.com/content/images/2023/06/image8-2.png)
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 压缩所提供的好处。
旧世界
![](https://blog.cloudflare.com/content/images/2023/06/Flow_how-CF-compresses_1.png)
现在,由于 Cloudflare 完全支持端到端的 Brotli 压缩,客户将开始看到我们更新的“accept-encoding”标头到达他们的源。一旦可用,客户可以直接将高度压缩(最高的 11 级)的 Brotli 文件传输、缓存和提供给我们。这将有助于减少延迟和带宽消耗。如果最终用户设备不支持 Brotli 压缩,我们将自动解压文件,以解压缩格式或 Gzip 压缩文件的形式提供,具体取决于 Accept-Encoding 标头。
完全端到端 Brotli 压缩支持
![](https://blog.cloudflare.com/content/images/2023/06/Flow_how-CF-compresses_2.png)
最终用户不支持 Brotli 压缩
![](https://blog.cloudflare.com/content/images/2023/06/Flow_how-CF-compresses_3.png)
客户可以通过参考适当的在线资料在其源上实现 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 需要解压缩并访问主体部分以应用请求的设置。或者,客户可以使用配置规则为特定路径禁用这些功能。
![](https://blog.cloudflare.com/content/images/2023/06/pasted-image-0-3.png)
如果启用了这些重写功能之一,您的源仍然可以更高的级别发送 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 应用程序快速流畅地加载,即使处理大型、详细纹理时也不例外。
![](https://blog.cloudflare.com/content/images/2023/06/pasted-image-0--1--2.png)
客户也可以禁用压缩或指定有关我们如何压缩的偏好。另一个例子可能是,基础设施公司只想支持其物联网设备的 Gzip 压缩,但允许所有其他主机名使用 Brotli 压缩。
![](https://blog.cloudflare.com/content/images/2023/06/pasted-image-0--2--1.png)
压缩规则使用我们其他规则产品所使用的过滤器,并增加了媒体类型和扩展类型字段。这允许用户可以轻松指定要压缩的内容。
![](https://blog.cloudflare.com/content/images/2023/06/pasted-image-0--3--1.png)
弃用 Brotli 切换
自 2016 年以来,一些 Web 浏览器长期支持 Brotli,而 Cloudflare 自 2017 年开始支持 Brotli。与所有新的 Web 技术一样,当时 Brotli 是未知的,我们通过 API 和用户界面向客户提供了选择性启用或禁用 Brotli 的能力。
![](https://blog.cloudflare.com/content/images/2023/06/pasted-image-0--4-.png)
如今,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 如何处理到最终用户的压缩。