My Blog Just Got Faster: Cloudflare Workers and AVIF Support

Matthias Endler

ブログがさらに高速化:Cloudflare WorkersとAVIF対応

原文は Matthias Endler により に公開されました。 このブログを購読する

このサイトが速いって話はしたっけ? ああ、したとも何度もね

理由をいくつか挙げてみよう(普通のものから、徐々に狂気がにじみ出てくるものまで):

  • 📄 静的サイト
  • ☁️ Cloudflare CDNでキャッシュ
  • 🔗 HTTP/2とHTTP/3に対応
  • 🚫 Webフォントなし(残念ながら)
  • Edge Workerによる解析(Google Analyticsは使わない)
  • 🌸 可能な限りJavaScriptを避けている。やりたいことの90%はCSSでまかなえる。
  • 🖼️ ページのリフローを防ぐため、画像の幅と高さはHTMLで指定
  • 👍🏻 インライン化された、最適化されたSVGグラフィックと手書きのCSS
  • 🚅 静的なWASM検索(遅延読み込み)
  • 🏎️ ホームページ全体で10KB未満(brotli圧縮、画像込み)。だから最初のHTTPラウンドトリップに収まるはずだ。
  • 💟 なんと、ファビコンまでサイズを最適化している。追記:こちらの記事のおかげで今はSVGアイコンを使っている。

とはいえ、もう2020年だ。みんなファビコンくらい最適化してるよね?…だよね!?

ところが、他のほとんどのサイトは僕ほどユーザーのデータ通信量のことを考えていないらしい。いや、控えめに言いすぎた。まったく気にしていないのだ。でも僕にとっては、身軽であることは美しい

ところで、画像はどうなの?

図やイラストにはSVGを好んで使っている。写真のときだけJPEGかWebPを使う。

正直、僕はWebPがあまり好きではなかった。ざっくり言えば、MozJPEGで圧縮したJPEGより小さくならない可能性すらあるのだ。詳しく読みたいなら、Mozillaのバグトラッカーでの長い議論をどうぞ。今日に至るまで、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サポートはまだない。でも今すぐ欲しい! そこで(例によって)古いJPEGやPNGからAVIF画像を生成する汚いRustスクリプトをちゃちゃっと書いた。念のため元のファイルは残してある。

内部ではKornel Lesiński氏によるcavifを呼び出している。

データ削減量

ブログでAVIFを試した結果は、驚異的としか言いようがなかった:

endler.dev/2020/sponsorsの合計画像サイズ
endler.dev/2020/sponsorsの合計画像サイズ

お使いのブラウザを確認してみよう

でも、ちょっと待って。あなたのブラウザはそもそもAVIFを表示できるだろうか?

もし「yup」と表示されていれば問題なし。
もし「nope」と表示されていれば、選択肢はいくつかある:

  • Firefoxの場合:アドレスバーからabout:configを開き、avifを検索しよう。
  • Chromeの場合:最新バージョンにアップデートしておこう。
  • Safariの場合:人生で何をやっているのかわからないけど、まともなブラウザを使ってみたらどうだろう。😏

回避策その1:古いブラウザ用のフォールバック

HTMLの素晴らしいところは、ブラウザが知らない新しい構文を無視してくれることだ。だから<picture>要素を使って、適切なフォーマットを配信できる。(見て、ママ、JavaScriptなしだよ!)

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

本物はもう少し複雑だが、言いたいことは伝わるだろう。

回避策その2:GitHub Pagesでの誤ったContent-Type

ただ、GitHubとAVIFには厄介な問題が一つあった。サーバーがContent-Type: application/octet-streamヘッダーを返してくるのだ。

そのせいで、Firefoxでは画像が読み込まれなかった

ページはGitHubにホストされているので、僕の側ではどうしようもなかった。……今までは! ずっとCloudflareのWorkers Sitesを試してみたかったのだが、このバグがついに乗り換えのきっかけになった。基本的に、サイト全体をCDN上のEdge Workerとして動かしているので、自前のウェブサーバーは不要だ。素晴らしいのは、サイトがどこからでも速くなったことだ。辺鄙な場所からでもサーバーへの往復が不要になった。

Edge Workerを動かすことで、リクエストやレスポンスオブジェクトも完全に制御できるようになった。Workerのレスポンスを横取りするために、こんな素敵なスニペットを追加した:

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

これで一発解決。Firefoxもご機嫌だ。レスポンスオブジェクトの変更について詳しくはこちらを読んでほしい。

Workers Sitesのもう一つの副次効果として、本番デプロイが今では1分で終わるようになった。

Cloudflare移行後のパフォーマンス結果

移行前のウェブサイト応答時間
移行前のウェブサイト応答時間
出典: KeyCDN
移行後のウェブサイト応答時間
移行後のウェブサイト応答時間
出典: KeyCDN
移行前のページサイズと評価
移行前のページサイズと評価
出典: Pingdom.com
移行後のページサイズと評価
移行後のページサイズと評価
出典: Pingdom.com

有名サイトとの比較でも引けを取ることはない:

自分が読んでいる他のブログとの比較
自分が読んでいる他のブログとの比較
出典: Speedcurve

さらに読む

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント