日本語GoogleFontsの読み込みを改善したい
miyaoka
Next.jsのv10.0.4からexperimentalで実装されたoptimizeFontsという機能を使うと、GoogleFontsの読み込みが最適化される、という有益情報。このzennで既に使われている。
実際に点数も向上していて喜ばしいが、自分の場合は特に日本語のGoogleFontsのパフォーマンスの悪さをどうにかしたいと思っているので、それについて書き留めていきたい。
そもそも日本語GoogleFontsを使うとどうなるか？
Noto Sans JPのweight400と700の2書体を追加するだけで評価が壊滅的になる。
何が起きているのか？
なぜパフォーマンスが下がるかというとcss（紫色のやつ）を取得している間、レンダリングブロックが発生するから
どんなCSS内容か？
CSS自体はフォントの実体ではなく、フォントファイルの在り処を定義するものになっている。
- font-family
- font-style
- font-weight
- font-display
- src（これがフォントファイル（.woff）のパス）
- unicode-range
この6項目から成るfont-face情報。日本語は文字が多いので、100個以上のfont-faceに分割されているのだが、各font-face毎にどの文字が対象なのかというunicode-rangeの内容が大量に書かれている（スクロールバーで感じて欲しい）。これだけで数百KBになるほどでかい。
nextのoptimizeFontsは何をするのか？
build時に上記のCSS内容を取得し、inline化して書き出してくれる。
CSS内容の分、HTMLが重くなるが、レンダリング時にgoogleのサーバーに取りに行かなくて済む。
cssは必要なフォントをパラメータで指定する形式のため、動的な分レスポンスが遅いんじゃないかと思う。なのでビルド時にキャッシュしてしまうほうが向上が見込める。
miyaokaちなみにoptimizeFontsを有効にしたらビルドエラーになってしまいしばらく悩んだけど、react v17を使っていたのでv16に下げたら解決しました
miyaokaやってみた…が、
改善してない…。どころか下がってしまっている。
PageSpeed Insightsでのスコア測定については正直よくわからないところがある。
点数自体は下がってるけど、レンダリングブロックに5.13秒かかっていたのが解消されているので改善はされているはず。ただその分FCPが遅くなってしまっているのが大きく減点要素になっているようだ。
ちなみにchromeのDevToolsのLighthouseから計測したときはTTIを除いて全体的に向上している。
DCLからFCPまで速くなってる。
なんでPageSpeed Insightsで低評価なのか？
- PageSpeed Insightsはgoogleだからgoogleサーバーにあるリソースの読み込みが速い？
- 「googleのCSS + vercelのhtml」よりも 「vercelのhtml + inlineCSS」のほうがgoogle的に遅くなってしまう？
miyaoka気になりどころ
- 静的書き出ししちゃってるけど、font-faceのsrcとかunicode-rangeって変わらないもの？
- googleFonts側のsrcが新しくなるとして、古いsrcは消されずそのまま残されるのかどうか