ということをやってる公式のサンプルを見つけたので、なるほど?って思いながら見てた。
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からリクエストして返す
- フォントのキャッシュはしてなかった
ということ。
これによって、
つまりWebフォントが速くなるぜ!ってことだった。
やってみた
オリジンありでWorkerを利用してるプロジェクトがなかったので、代わりにCloudflare Pagesで静的にビルドしてるやつで試した。
- Google FontsのCSSは、ビルド時にインライン化してしまう
- サブセットのURLは、自身のWorkerへ書き換える
- サブセットへのリクエストは、同じドメインのWorkerからリクエストして返す
というように、結果的なアウトプットは同じになるようにした。
前提条件も数値も載せてないので信憑性がないかもしれないけど、手元のLighthouseで適当に見てみた感じ、
- ちょっとだけ速くなった
- 最大で0.5sとかそういうレベル
- インライン化は効いてそう
- サブセットをWorker経由にするのはそこまで効いてなさそう
Edge Workerでネットワーキングまわりをなんとかする系の作戦、狭くて回線の良い日本だとあんま効果出ませんな・・。
そもそも
CSSをインライン化するだけなら、別にWorkerなくてもできる。ビルド時に動的にやらんでも、普通にブラウザで開いてコピペすればいい。
ただしCSSをインライン化するにしても、埋め込まれる容量の問題は変わらない。日本語フォントの場合、1つのファミリーの1つのウェイトってだけでも、gzipされてて約30KBの文字列っていう。
結局のところ、Webフォント(日本語)の問題点である、
- ファイルサイズのデカさ
- マニフェストは元より、必要になるサブセットの数も
- `rel="preload"`したくても対象が読めない
- レイアウトシフトが不可避
- `font-display: swap`しても画面中の文字がチラつく
っていうのを解決できない限り、一見さん向けのファーストビューはチューニングしようがないんよね。
というわけで、引き続き†覚悟†のある人だけが日本語Webフォントを使ってくださいってとこは変わらないかなー。
いや、気持ちはわかりますよ、気持ちは。