Webフォントは、今でも多くのサイトで最も手軽なパフォーマンス改善策です

繰り返し現れるパターン

今日、任意の本番サイトを10件監査すると、その多くでほぼ同じフォント事情が見つかります:

• ホームページで6〜10個のフォントファイルを読み込んでいる
• すべてWOFF2である（良い）が、font-display 戦略がない（悪い）
• ページ内のどこでも使われていないウェイトやスタイルが複数ある
• スタック全体がサードパーティドメイン（たいていはGoogle Fonts）から配信されており、それに伴うDNS、TLS、プライバシーのコストを負っている
• unicode-range によるサブセット化がないため、ページが英語であっても訪問者全員がキリル文字やギリシャ文字のグリフをダウンロードしている

これは小規模サイトだけの問題ではありません。十分な予算があるマーケティングページでも、最初の段落が描画可能になる前に600 KBのフォントを読み込んでいる例は少なくありません。一度このパターンに気づくと、もう見過ごせなくなります。

修正は特殊なものではありません。何年も前からブラウザに備わっている、よく理解された手法をいくつか使うだけです。

6つの静的フォントではなく、1つの可変フォントを使う

Inter Regular、Inter Medium、Inter SemiBold、Inter Bold および それぞれのイタリックを読み込んでいるなら、必要な量のおよそ6倍のバイトをダウンロードしていることになります。単一のInter可変フォントなら、ウェイト軸全体（ビルドによっては傾きも）を1つのファイルでカバーでき、そのサイズは静的ウェイト2つ分よりわずかに大きい程度です。

ブラウザ対応については何年も前に決着しています。可変フォントは、重要な環境ではどこでも動作します。残っているためらいの多くは、静的フォント時代からの習慣にすぎません。

実用的な目安はこうです: ファミリーごと、文字体系ごとに、可変フォントファイルを1つ。ラテン文字を1ファイル、キリル文字を別ファイル、ギリシャ文字をさらに別ファイルにし、unicode-range で条件付きに読み込む。それだけです。

適切な font-display を設定する

カスタムフォントがまだ読み込み中のときのデフォルト挙動は、最大3秒間、何も表示しない ことです。つまり不可視のテキストです。これは最悪のデフォルトです。ユーザーには空白のページが見え、何か壊れていると思われます。

すべての @font-face ルールにこれを追加します:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

swap はフォールバックフォントを即座に表示し、カスタムフォントの読み込みが完了した時点で差し替えます。ユーザーは0ミリ秒目からページを読めます。トレードオフは、差し替え時に短いレイアウトシフトが起きることです。これは次の手法で軽減できます。

フォールバックのメトリクスを合わせる

スタイル未適用テキストの一瞬の表示が不快に感じられるのは、フォールバックフォントとカスタムフォントのメトリクスが大きく異なる場合だけです。現代のCSSでは、size-adjust、ascent-override などでこれを修正できます:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

フォールバックのメトリクスを調整しておくと、差し替えはほとんど知覚できません。カスタムフォントが届く前後で、単語が占める横幅が同じになるからです。

Googleの --allow-fallback-font-metrics に関する取り組みは、今ではベースラインのブラウザサポートになっています。また、fontaine ライブラリなど、適切な数値を数秒で計算してくれるツールチェーンもあります。

セルフホストする

Google Fontsは便利で無料ですが、実際に2つのコストを伴います:

1. 2回目のTLSハンドシェイク。 HTTP/3やコネクションの集約があっても、追加のオリジンが無料になることはまれです。
2. プライバシーとコンプライアンスの問題。 複数の欧州裁判所は、fonts.gstatic.com からGoogle Fontsを読み込むことは個人データ（IPアドレス）を第三者に送信する行為にあたると判断しています。セルフホストすれば、この問題自体を完全に取り除けます。

ダウンロードしてホストする流れは次のとおりです:

1. WOFF2ファイルを取得する（存在するなら可変フォントビルド）
2. 実際の読者が使う文字体系にサブセット化する
3. サイトの他の部分と同じオリジンから配信し、長い Cache-Control: max-age=31536000, immutable を付ける
4. 最も重要なウェイトをプリロードする: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

これがパイプライン全体です。既存サイトでも午後いっぱいあれば終わり、ほとんどの場合、元に戻すことはありません。

カスタムフォントを完全に省くべき場合

はっきり言っておく価値があります。すべてのサイトにカスタムフォントが必要なわけではありません。システムフォントスタックは、今ではすべてのOSで本当に美しくなっています:

font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Inter, sans-serif;

ウェイトは適切で、メトリクスも合っており、レンダリングはデバイス向けに調整され、ネットワーク上のバイトコストは正確にゼロです。ツール系サイト、社内アプリ、コンテンツを優先するポートフォリオ、あるいは低速ネットワークのユーザーを対象にするものなら、システムスタックが正解です。

<!-- tool-cta:start -->

💡 試してみてください: Webfont Generator を使って、TTF または OTF ファイルを、この記事が推奨する形式変更である、すぐに使える CSS 付きの最新の WOFF2 に変換しましょう。

<!-- tool-cta:end -->

正直なまとめ

典型的な小規模サイトなら、Webフォントのパフォーマンス対策は次の4ステップでほぼ網羅できます:

1. ファミリーごと、文字体系ごとに 1つの可変フォント
2. font-display: swap と メトリクスを合わせたフォールバック
3. 長いキャッシュヘッダーと重要ウェイトの preload を使った セルフホスト
4. またはフォントを完全に省き、システムスタックを使う

これを一度行えば、ホームページから数百キロバイトを取り戻し、体感パフォーマンスを数百ミリ秒改善し、その過程でサードパーティ依存も取り除けます。労力に対する見返りがこれほど大きい変更は、そう多くありません。