My Blog Just Got Faster: Cloudflare Workers and AVIF Support

Matthias Endler

我的部落格變更快了:Cloudflare Workers 與 AVIF 支援

我有提過這個網站很快嗎?喔有啊,提過了還提過很多次

幾個原因(從平凡到開始出現偏執的跡象):

  • 📄 靜態網站
  • ☁️ 透過 Cloudflare CDN 快取
  • 🔗 支援 HTTP/2 與 HTTP/3
  • 🚫 無網頁字型(可惜)
  • 由 Edge-worker 驅動的分析(無 Google Analytics)
  • 🌸 盡可能避免使用 JavaScript;CSS 已能涵蓋我 90% 的使用情境。
  • 🖼️ 在 HTML 中指定圖片的寬與高,以避免版面重排。
  • 👍🏻 內嵌、最佳化的 SVG 圖形與手刻 CSS
  • 🚅 靜態 WASM 搜尋(延遲載入)
  • 🏎️ 整個首頁包含圖形在內,經 brotli 壓縮後不到 10K,因此應該能塞進首次 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 影像。原始檔我還是留著,以備不時之需。

底層是呼叫了由 Kornel Lesiński(科爾內爾·萊辛斯基) 開發的 cavif

資料量節省成果

AVIF 在部落格上的成果令人印象深刻:

endler.dev/2020/sponsors 的總圖片大小
endler.dev/2020/sponsors 的總圖片大小

檢查你的瀏覽器

不過先等一下……你的瀏覽器真的能顯示 AVIF 嗎?

如果上面顯示「yup」,那就沒問題了。
如果顯示「nope」,你可以試試以下幾種方法:

  • 在 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 上以 edge worker 的形式執行整個網站;不需要自己的網頁伺服器。最棒的是,網站現在在任何地方都很快——即使在偏遠地區——不再需要來回連線到伺服器。

透過執行 edge worker,我也完全掌控了 request 與 response 物件。我加入了這段精華程式碼片段來攔截 worker 的回應:

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

就這樣,輕鬆搞定。Firefox 也開心了。你可以在這裡閱讀更多關於修改 response 物件的資訊。

Workers Sites 的另一個副作用是,現在正式環境的部署只需一分鐘

搬遷至 Cloudflare 後的效能成果

搬遷前的網站回應時間
搬遷前的網站回應時間
來源:KeyCDN
搬遷後的網站回應時間
搬遷後的網站回應時間
來源:KeyCDN
搬遷前的頁面大小與評分
搬遷前的頁面大小與評分
來源:Pingdom.com
搬遷後的頁面大小與評分
搬遷後的頁面大小與評分
來源:Pingdom.com

我也不怕拿來跟知名網站比較:

與我平常閱讀的其他幾個部落格的比較
與我平常閱讀的其他幾個部落格的比較
來源:Speedcurve

延伸閱讀

原文由 Matthias Endler 發布

本文章由 muse-spark-1.2-contributor 進行翻譯