【テクニカル・上級編】フォント読み込みとレンダリングへの影響 – Webブラウザの仕組み実践ガイド

フォントは「描画のプライド」を捨てろ：Webフォントの非同期地獄と戦うレンダリング戦略

Webサイトのパフォーマンスを計測していて、こんな経験はないだろうか。「LCP（Largest Contentful Paint）は悪くないのに、ページが表示された瞬間にテキストがガタガタとレイアウトシフト（CLS）を起こす」。

犯人はほぼ間違いなくWebフォントだ。ブラウザの内部構造を知るエンジニアなら当然理解しているはずだが、Webフォントの読み込みは、ブラウザにとって「レンダリングパイプラインを一時停止させる極めてリスキーなイベント」である。今回は、なぜWebフォントがあなたのUIを破壊するのか、そしてそれをどう制御すべきか、アーキテクトの視点で紐解いていく。

1. フォント読み込みという「非同期の罠」

ブラウザのレンダリングエンジン（BlinkやWebKit）にとって、フォントファイルはHTMLパースやCSSOM構築の過程で発見される「後発の外部リソース」だ。

1. DOM構築: HTMLをパースし、DOMツリーを作る。
2. CSSOM構築: CSSをパースし、スタイルを計算する。ここで`@font-face`に出会う。
3. フォントリクエスト: 使用箇所が確定した時点で、ブラウザはフォントファイルを非同期で取得しに行く。

問題はここからだ。ブラウザのレンダリングエンジンは、「フォントがダウンロードされるまで、テキストを描画すべきか否か」という苦渋の決断を迫られる。

FOIT (Flash of Invisible Text)

多くのブラウザのデフォルト挙動。フォントが落ちてくるまでテキストを不可視にする。低速回線では「真っ白な画面」が数秒続く。UXとしては最悪だ。

FOUT (Flash of Unstyled Text)

フォントが落ちてくるまで、代替フォント（システムフォント）で表示し、フォントが準備でき次第、差し替える。ユーザーは即座に情報を得られるが、フォントの字幅の違いにより、レイアウトがガクッと動く。

2. font-display による「ブラウザへの指示書」

この挙動を制御するための強力なプロパティが `font-display` だ。これを使いこなすことは、レンダリングエンジンのハンドリングを最適化することに他ならない。

/ 現場で最も推奨される設定の一つ /
@font-face {
font-family: ‘Inter-Optimized’;
src: url(‘/fonts/inter.woff2’) format(‘woff2’);
/
1. swap: FOUTを許容し、ユーザーへの体験を優先。
2. ブロック期間を0にすることで、不可視状態を回避。
/
font-display: swap;
}

ただし、`swap` を多用すると、後からフォントが適用された瞬間に、ブラウザは「リフロー（再レイアウト）」を強制される。これがCLS（Cumulative Layout Shift）を悪化させる最大の要因だ。

3. レイアウトシフトを根絶する「Font Metrics Override」の極意

「フォントが変わるからレイアウトが動く」。ならば、「代替フォントとWebフォントの占有領域を数学的に一致させる」という力技が有効だ。

Webフォントが読み込まれる前（システムフォント使用時）のボックスサイズを、CSSの `size-adjust` でWebフォントの挙動に強制的に合わせるのだ。

/
システムフォントとWebフォントの字幅・高さを合わせる技術
これにより、FOUTが発生してもレイアウトは微動だにしない。
/
@font-face {
font-family: ‘Fallback’;
src: local(‘Arial’); / システムフォントを模倣 /
size-adjust: 95%; / Webフォントにサイズを寄せる /
ascent-override: 90%;
descent-override: 20%;
}

この手法は、レンダリングエンジン側で発生する「フォント差し替えによるリレイアウト負荷」を物理的にゼロにする。上級エンジニアなら、Google FontsのCSS出力をただコピペするのではなく、Webフォントのメトリクスを計測し、このオーバーライド値を手動で調整すべきだ。

4. チーフアーキテクトからの提言：フォント読み込みの優先順位

ブラウザのリソースヒント（Resource Hints）を適切に使うことで、レンダリング負荷を先読みで最適化できる。

`rel=”preload”`: 非常に重要だが、ページ全体で2つまでに絞ること。無闇にpreloadすると、ネットワーク帯域がフォントで埋め尽くされ、メインコンテンツのHTML/JSの取得が遅れる。
`font-display: fallback`: 「最初の0.1秒は不可視、その後は3秒間だけ待つ。それでもダメならシステムフォントで固定」という、非常に厳格かつ現実的な制御が可能。

戦略的な実装コード

結論：ブラウザを「制御」する感覚を持て

フォント読み込みの最適化は、単なる「デザインのこだわり」ではない。ブラウザのレンダリングパイプラインのメモリ効率、CPUの再描画負荷、そしてネットワークのリソース競合を考慮した「システムアーキテクチャそのもの」だ。

「とりあえずWebフォントを読み込んで、`swap`にしておこう」という思考停止を卒業せよ。代替フォントのメトリクスを調整し、プリロードの優先順位をコードで定義し、レンダリングの挙動を完全に制御下に置く。そこまでやって初めて、真に堅牢でストレスのないWeb体験を構築できるのだ。

あなたのWebサイトは、フォント一枚で崩れるほどヤワではないはずだ。さあ、ブラウザの内部挙動を愛でながら、コードを書き直してほしい。