Cloudflare WorkersでWebフォントの配信を最適化する

ということをやってる公式のサンプルを見つけたので、なるほど？って思いながら見てた。

https://github.com/cloudflare/worker-examples/tree/master/examples/fast-google-fonts

あと、そのままは流用できなかったけど、似たようなことを手元のGoogle Fontsを使ってるプロジェクトで試してもみた。

やってること

このサンプルでやってたのは、

• オリジンありでWorkerを使う
• HTML/CSSへのリクエストを仲介して、Google FontsのCSSをインライン化してしまう
  • `link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap"`みたいなやつ
  • 処理は`TransformStream`でストリーミングしながら返す
  • サブセットのURLは、自身のWorkerへ書き換え
  • CSS自体はキャッシュ
• サブセットへのリクエストを仲介して、Workerからリクエストして返す
  • フォントのキャッシュはしてなかった

ということ。

これによって、

• インライン化によって、CSSのロードとパースのステップが減る
• 同じドメインから返すことで、Googleのドメインとのコネクションまわりの無駄が減る

つまりWebフォントが速くなるぜ！ってことだった。

やってみた

オリジンありでWorkerを利用してるプロジェクトがなかったので、代わりにCloudflare Pagesで静的にビルドしてるやつで試した。

• Google FontsのCSSは、ビルド時にインライン化してしまう
  • サブセットのURLは、自身のWorkerへ書き換える
• サブセットへのリクエストは、同じドメインのWorkerからリクエストして返す

というように、結果的なアウトプットは同じになるようにした。

前提条件も数値も載せてないので信憑性がないかもしれないけど、手元のLighthouseで適当に見てみた感じ、

• ちょっとだけ速くなった
  • 最大で0.5sとかそういうレベル
• インライン化は効いてそう
  • ブロッキングなCSSのロードをスキップした分
• サブセットをWorker経由にするのはそこまで効いてなさそう
  • もともとのネットワークが速い（家Wi-Fi）と、直接GoogleのCDNから取っても誤差っぽい
  • ネットワークが遅い場合は、それなりに効果がありそう
  • サブセット自体もセルフホストして、同じドメインで（もちろんCDNで）返すとかすると、もう少しだけ攻めれそうではある

Edge Workerでネットワーキングまわりをなんとかする系の作戦、狭くて回線の良い日本だとあんま効果出ませんな・・。

そもそも

CSSをインライン化するだけなら、別にWorkerなくてもできる。ビルド時に動的にやらんでも、普通にブラウザで開いてコピペすればいい。

ただしCSSをインライン化するにしても、埋め込まれる容量の問題は変わらない。日本語フォントの場合、1つのファミリーの1つのウェイトってだけでも、gzipされてて約30KBの文字列っていう。

結局のところ、Webフォント（日本語）の問題点である、

• ファイルサイズのデカさ
  • マニフェストは元より、必要になるサブセットの数も
  • `rel="preload"`したくても対象が読めない
• レイアウトシフトが不可避
  • `font-display: swap`しても画面中の文字がチラつく

っていうのを解決できない限り、一見さん向けのファーストビューはチューニングしようがないんよね。

というわけで、引き続き†覚悟†のある人だけが日本語Webフォントを使ってくださいってとこは変わらないかなー。

いや、気持ちはわかりますよ、気持ちは。