My Blog Just Got Faster: Cloudflare Workers and AVIF Support

2020-09-14

Matthias Endler

我的博客又变快了：Cloudflare Workers 与 AVIF 支持

我提过这个网站很快吗？当然提过，提过一次，还不止一次。

原因有几个（从普通做法到开始有点走火入魔）：

📄 静态网站
☁️ 缓存在 Cloudflare CDN 上
🔗 支持 HTTP/2 和 HTTP/3
🚫 不使用网页字体（遗憾）
✅ 使用边缘 Worker 驱动的分析（不用 Google Analytics）
🌸 尽可能避免使用 JavaScript；CSS 已经覆盖了我 90% 的使用场景。
🖼️ 在 HTML 中指定图像的宽度和高度，避免页面重排。
👍🏻 内联且经过优化的 SVG 图形，以及手写的 CSS
🚅 静态 WASM 搜索（延迟加载）
🏎️ 整个首页小于 10K（经过 brotli 压缩），包括图形在内，因此应该能在第一次 HTTP 往返中完成传输。
💟 甚至连 favicon 都针对体积进行了优化。更新：多亏了这篇文章，我现在使用 SVG 图标了。

话说回来，现在可是 2020 年：所有人都在优化自己的 favicon，对吧？……对吧！？

不过，事实证明，大多数其他网站并不像我这样在意用户的数据流量套餐。其实这么说还是保守了：他们根本不在乎。但对我来说，精简就是美！

等等，那图像怎么办？

图表和插图我更喜欢使用 SVG。只有在图像是照片时，我才会使用 JPEG 或 WebP。

说实话，我从来都不太喜欢 WebP。简单来说，它的体积甚至可能不比使用 MozJPEG 压缩的 JPEG 更小。如果你想了解更多，可以看看 Mozilla bug tracker 上那场漫长的争论。直到今天，Safari 仍不支持 WebP。

你好，AVIF 👋

认识一下 AVIF，这是一种新一代图像压缩格式。看看这个：

[ReachLightSpeed.com](https://reachlightspeed.com/blog/using-the-new-high-performance-avif-image-format-on-the-web-today/) — 来源：ReachLightSpeed.com

Chrome 85 和 Firefox 80 已经支持它了。
然后我突然恍然大悟 🌪️：

😲 天哪，现在主流浏览器都支持 AVIF 了！？
我想让我的博客也用上它！

可以，也不完全可以。

我的博客使用 Zola，而 Zola 对 AVIF 的支持还没有实现，但我现在就想用！于是我快速写了一个丑陋的 Rust 脚本（你懂的），用旧的 JPEG 和 PNG 图像生成 AVIF 图像。原始文件我也留着，以防万一。

在底层，它调用的是由 Original Name（中文译名）Kornel Lesiński（科内尔·莱辛斯基）编写的 cavif。

节省流量

AVIF 在博客上的效果简直令人印象深刻：

[endler.dev/2020/sponsors](https://endler.dev/2020/sponsors) 的图像总大小 — endler.dev/2020/sponsors 的图像总大小

检查你的浏览器

不过先等一下……你的浏览器到底能不能显示 AVIF？

如果显示“可以”，那你就准备好了。
如果显示“不行”，你还有几个选择：

Firefox：在地址栏打开 about:config，然后搜索 avif。
Chrome：确保更新到最新版本。
Safari：我不太确定你的人生到底在做什么。换个真正的浏览器试试吧。😏

变通方案一：为旧版浏览器提供回退

HTML 的好处在于，浏览器会忽略不认识的新语法。因此我可以使用 <picture> 元素，为你提供合适的格式。（看到了吧，完全不用 JavaScript！）

<picture>
  <source srcset="fancy_browser.avif" />
  <source srcset="decent_browser.webp" />
  <img src="meh_browser.jpg" />
</picture>

实际代码稍微复杂一些，但你明白这个思路就行了。

变通方案二：Github Pages 上错误的 Content-Type

不过，Github 和 AVIF 之间有一个棘手的问题：它们的服务器返回了 Content-Type: application/octet-stream 标头。

这意味着图像在 Firefox 上无法加载。

由于 Github 托管着我的页面，我这边没办法修复这个问题。直到现在！我很久以前就想试试 Cloudflare 的 Workers Sites，而这个 bug 最终促使我做出了切换。基本上，我直接在 CDN 上将整个网站作为一个边缘 Worker（edge worker）运行；不需要自己的 Web 服务器。好处是，现在网站在任何地方都很快——即使在偏远地区也是如此——不再需要与服务器进行额外的往返。

通过运行边缘 Worker，我还获得了对请求对象和响应对象的完全控制。我加上了这段精妙的代码片段，用于拦截 Worker 响应：

if (/\.avif$/.test(url)) {
  response.headers.set("Content-Type", "image/avif");
  response.headers.set("Content-Disposition", "inline");
}

然后就搞定了。Firefox 很满意。你可以在这里进一步了解如何修改响应对象。

Workers Sites 的另一个副作用是，现在生产环境部署只需要一分钟。

迁移到 Cloudflare 后的性能结果

我也完全不怕和那些知名网站比较：