和文フォントを入れたら 2.9MB 増えた ── preload の罠

和文フォントは文字数が多いので、ある程度大きくなるのは想定内でした。Core Web Vitalsに響く量ではあるものの、書体を入れる以上は避けられません。しかし 250 個は明らかに多い。調べたところ、こちらの指定の仕方が原因でした。

配信元は、和文フォントを文字の範囲ごとに細かく分割して配信しています。ひらがな、よく使う漢字、あまり使わない漢字、というように分かれています。ブラウザは、ページに出てくる文字に必要な範囲だけを取りに行く。この仕組み自体は無駄がありません。

問題は、こちらが subsets を指定したことでした。この指定を書くと、フォントを扱う仕組みが分割ファイル全部にプリロード（Preload）の指定を出します。ブラウザは「先に取っておけ」と言われたので、実際に使うかどうかに関わらず全部取りに行きます。

分割ファイルの数は、ウェイトの数に比例して増えます。4ウェイトなら約 480、3ウェイトなら約 360。だから使っていないウェイトを載せると、そのぶん丸ごと増えます。

そこで、サイト内で実際にどの太さが使われているかを数えました。

500 は 8 箇所、600 は 23 箇所しか使っていませんでした。しかも選んだ書体に 600 という太さは存在しません。指定していたつもりで、実際には読み込まれていなかったわけです。

ブラウザは、指定された太さが無ければ最も近いものを選びます。600 を指定した箇所は 700 で描画され、見た目は変わりません。8箇所や23箇所のために1ウェイト（約400KB）を払う理由はないと判断して落としました。

測り方も書いておきます。ブラウザの開発者ツールでも見られますが、自動で何度も測るなら、読み込みの記録から拾うほうが確実です。設定を変えるたびに同じ手順で測れます。

この設定は デザイントークン（Design Token）と同じで、1 か所にまとめて書いておくべき種類のものです。残る 1.19 MB も小さくはありません。ただし display: "swap" を指定してあるので、フォントの読み込みを待たずに文字は表示されます。まず端末の書体で表示され、届いた時点で差し替わる。

この指定が無いと、フォントが届くまで文字が出ません。LCP（Largest Contentful Paint）に直接響くので、和文フォントを使うなら必須です。

さらに削るなら、実際に使っている文字だけを含む専用のフォントを自分で作る方法があります。記事が静的なので理屈上は可能ですが、今回はそこまでやっていません。必要になったときの手段として記録に残すに留めました。

書体を1つ入れるだけで、転送量が 2.9 MB も動く。この事実自体が、非デザイナーには意外でした。デザインの判断が、そのまま表示速度の判断でもあるという感覚は、今回はじめて実感したことのひとつです。

そして、この 2.9 MB は入れた直後に測らなければ気づけませんでした。手元の回線では体感できず、見た目も意図どおりだったからです。変更したら測る、という手順を挟むかどうかだけの違いで、気づけるかどうかが決まります。

次回は、この「測って改善した」という話で私が犯した、もっと基本的な間違いを書きます。そもそも測る単位を間違えていました。