本番環境のバリアブルフォント：誰も教えてくれないトレードオフ

バリアブルフォントは魔法のフォント圧縮ではない

バリアブルフォントは、Webタイポグラフィへの整った答えとして紹介されることがよくあります。1つのファイルで、多くのウェイトに対応し、リクエストを減らし、より滑らかなデザインシステムを実現する、という説明です。その方向性は正しいものの、完全ではありません。

本番環境では、バリアブルフォントは6つのファイルを1つのファイルに置き換えるというより、新しいタイポグラフィランタイムを採用することに近いものです。ウェイト、幅、傾き、光学サイズ、場合によってはカスタム軸まで表現を制御できるようになります。その一方で、ファイルサイズ、ブラウザのレンダリング、フォールバック挙動、デザインガバナンス、パフォーマンス計測に関する新しい判断も引き受けることになります。

結果は非常に良いものになることがあります。同時に、置き換える前の静的フォント構成より悪くなることもあります。

現在のサイトが同じファミリーの5つのウェイトを配信しているなら、適切にサブセット化されたバリアブルフォントによってリクエストを減らし、CSSを簡素化できるかもしれません。一方、通常ウェイトと太字ウェイトだけを配信しているサイトでは、ユーザーがまったく恩恵を受けない柔軟性のためにバイト数を増やすことになる可能性があります。これが、人々が見落としがちな本番環境でのトレードオフです。

フォント読み込み戦略のより広い基礎については、Webフォントはいまでも多くのサイトで最も簡単なパフォーマンス改善策である理由に関するガイドも参考になります。バリアブルフォントは基本を変えるものではありません。配信するバイト数を減らし、レンダリング遅延を抑え、フォールバックテキストを許容できるものにすることが重要です。

明らかな利点：ファイル数を減らし、より表現力のある書体へ

従来の静的フォント構成は、通常このようになります。

• Regular 400
• Italic 400
• Medium 500
• Semibold 600
• Bold 700
• 場合によっては別のディスプレイ用書体

各ファイルは個別にダウンロードされ、キャッシュされ、レンダリングされます。ページのファーストビューで複数のウェイトを使う場合、リクエストはすぐに積み上がります。

バリアブルフォントは、そうした複数のウェイトを1つのファイルにまとめることができます。Inter-Regular.woff2、Inter-Medium.woff2、Inter-Bold.woff2を読み込む代わりに、1つのバリアブルファイルを読み込み、連続した範囲でfont-weight: 400 700を使います。

これにより、実際の利点が生まれます。

• 管理すべきフォントファイルが少なくなる
• ウェイト間の補間がより一貫する
• 細かく調整できるレスポンシブタイポグラフィ
• テーマシステムを作りやすくなる
• デザイントークンとの整合性が高まる

デザインシステムでは、この制御が特に有用です。ボタンラベルは500か600に押し込められるのではなく、580を使えます。狭いカードタイトルでは、そのフォントが対応していれば、幅軸を少し凝縮できます。ディスプレイ見出しでは、利用可能であれば光学サイズを使えます。

ただし、そうした制御が存在するからといって、すべて使うべきだという意味ではありません。

最初の隠れたトレードオフ：1つのファイルが、実際に必要なファイルより大きいことがある

バリアブルフォントには、デザイン空間の補間データが含まれます。そのデザイン空間にはコストがあります。単一のバリアブルフォントファイルが、1つまたは2つの静的フォントファイルより大きくなることがあります。

多くのファイルを置き換える場合、それは問題ではありません。抑制されたスタックを置き換える場合には問題になります。

よくある2つのケースを考えてみましょう。

ケースA：多くのウェイトを使うマーケティングサイト

そのサイトでは、ページ全体で300、400、500、600、700、そしてイタリックを使っています。慎重にサブセット化したバリアブルフォントは、おそらく役に立ちます。リクエストのオーバーヘッドを減らし、将来のメンテナンスも簡素化できます。

ケースB：通常と太字だけを使うプロダクトアプリ

インターフェイスでは400と700を使い、フォールバックにはシステムフォントを使っています。バリアブルフォントは不要なバイトを追加する可能性があります。Figmaでは柔軟性が魅力的でも、ブラウザ上で常に有用とは限りません。

誤りは、「1つのバリアブルファイル」を「理論上あり得る多数の静的ファイル」と比較することです。比較すべきなのは、実際のページが現在使っているファイルです。

主要テンプレートで実際に読み込まれるフォントバイト数を計測してください。そのうえで、同じ文字サブセットと同じプリロード戦略でバリアブル版をテストします。バリアブル版が勝つと決めつけてはいけません。

2つ目のトレードオフ：サブセット化は重要性が下がるのではなく、上がる

バリアブルフォントでは、ベースファイルに多くのものが含まれ得るため、サブセット化の価値が高まります。グリフ、言語サポート、OpenType機能、複数の軸、メタデータなどです。

ほとんどの本番サイトは、フォント内のすべてのグリフを必要としません。英語だけを提供しているなら、汎ヨーロッパ全域の文字、キリル文字、ギリシャ文字、ベトナム語、そしてあらゆる記号ブロックまではおそらく不要です。複数言語を提供している場合でも、1つのユニバーサルファイルではなく、言語別のサブセットを使いたいことがあります。

実務上のアプローチは、通常次のようになります。

1. ほとんどのユーザー向けに中核となるLatinサブセットを維持する。
2. コンテンツが必要とする場合にのみ拡張サブセットを追加する。
3. unicode-rangeを使って、ブラウザが適切なファイルを選べるようにする。
4. 必要に応じて、まれな文字体系には静的フォールバックを残す。

ここで、バリアブルフォントは扱いにくくなることがあります。一部のフォントパイプラインは静的フォントのサブセット化は簡単にできても、バリアブル軸、ヒンティング、メタデータを適切に扱えないことがあります。出力されたフォントが、使う予定の軸範囲全体で正しく動作することを必ず確認してください。

壊れたサブセットは、大きなフォントより悪いものです。奇妙なレンダリング、欠落したグリフ、一貫しないウェイト、特定のロケールでだけ現れるレイアウト変化など、静かに失敗します。

3つ目のトレードオフ：CSSが賢くなりすぎることがある

バリアブルフォントは、CSSを通じて軸を公開します。ウェイトや幅のような標準軸は、font-weightやfont-stretchのようなプロパティに自然に対応します。カスタム軸では、多くの場合font-variation-settingsを使います。

その力は、チームを巧妙さへ誘惑します。

.card-title {
  font-variation-settings: "wght" 623, "wdth" 92;
}

これは技術的には有効かもしれませんが、デザインシステムのインターフェイスとして良いことはほとんどありません。ランダムな軸値がCSS全体に広がると、レビューが難しく、リファクタリングも難しく、誤用されやすくなります。

デザイントークンや名前付きユーティリティを優先してください。

:root {
  --font-weight-body: 400;
  --font-weight-heading: 680;
  --font-width-compact: 94;
}

.card-title {
  font-weight: var(--font-weight-heading);
  font-stretch: var(--font-width-compact);
}

可能な限り標準のCSSプロパティを使ってください。font-variation-settingsは、より高レベルのプロパティが存在しない軸に限定します。

アニメーションにも注意が必要です。ウェイトや幅のアニメーションは、控えめに使えば上品になり得ますが、リフロー、視覚的な不安定さ、低性能デバイスでの不要な処理を引き起こすこともあります。フォントが許すからといって、タイポグラフィをモーションの遊び場にするべきではありません。

4つ目のトレードオフ：レンダリングの違いは依然として存在する

現代のブラウザにおけるバリアブルフォント対応は強力ですが、レンダリングはどこでも同一ではありません。OSのテキストラスタライザー、ブラウザエンジン、アンチエイリアシング、フォントヒンティングはすべて結果に影響します。

バリアブルフォントのウェイト500は、同じファミリーの静的な500ファイルとまったく同じ見た目にならないことがあります。一部のファミリーでは、静的インスタンスが手作業で調整されている一方、補間されたバリアブルインスタンスは数学的に生成されています。小さなサイズでは、その差が重要になることがあります。

これは、本文、ナビゲーション、密なテーブル、UIラベルで特に関係します。インターフェイスにテキストが多いほど、ヒーロータイポグラフィだけでなく、実際の読書条件でテストするべきです。

バリアブルフォントへの移行に合わせてタイプシステムを見直すなら、目新しさではなく読みやすさから始めてください。現代のWebにおける読みやすい文字組みの実践ガイドでは、行長、サイズ、コントラスト、間隔といった、利用可能な1,000種類のフォントウェイトよりもたいてい重要な、地味な選択を扱っています。

5つ目のトレードオフ：キャッシュは良くも悪くも働く

単一のバリアブルフォントファイルは、一度キャッシュされればページ間で再利用できます。これは良い点です。

しかし、そのファイルが大きく、レンダリングをブロックする場合、初回訪問では最初に全コストを支払うことになります。静的フォントでは、より選択的に読み込めることがあります。本文用の通常ウェイトを先に、太字は後で、ディスプレイ用は必要なページだけ、という具合です。

普遍的な答えはありません。適切な構成はトラフィックのパターンによって異なります。

• ユーザーは1セッションで多くのページを訪問するか。共有バリアブルファイルが報われるかもしれません。
• ユーザーは1本の記事に着地して離脱するか。より小さな静的ファイルのほうが良いかもしれません。
• ホームページは1つのウェイトだけを必要としているか。将来のページのために大きなデザイン空間をプリロードしてはいけません。
• アプリはログイン後にあり、頻繁な再訪問があるか。キャッシュ再利用の価値が高まります。

プリロードにも抑制が必要です。ファーストビューのテキストに必要なフォントをプリロードし、あり得るすべてのフォントをプリロードしないでください。プリロードは優先度の主張です。優先度の主張が多すぎるとノイズになります。

6つ目のトレードオフ：Lighthouseは全体像を説明してくれない

パフォーマンスツールは、未使用のフォントバイト、レンダリングをブロックするリクエスト、レイアウトシフト、ネットワークコストを示すことができます。しかし、視覚的な柔軟性がペイロードに見合うかどうかは教えてくれません。

バリアブルフォントへの移行は、複数のシグナルで判断するべきです。

• 初回表示で転送されたフォント総バイト数
• フォントリクエスト数
• Largest Contentful Paintへの影響
• フォント差し替えによるCumulative Layout Shift
• 再訪問時のキャッシュ挙動
• 承認済みデザインとの視覚的な一致
• 一般的なサイズでの読みやすさ

フォント移行後にレポートが赤くなっても、慌てないでください。問題はバリアブルフォント自体ではなく、プリロード順序、フォールバックメトリクス、サブセットの不一致かもしれません。慌てずにLighthouseレポートを読む方法に関するガイドがここでも役立ちます。ラボスコアは判決ではなく、診断の手がかりとして扱ってください。

実務的な本番チェックリスト

バリアブルフォントを出荷する前に、次の質問に答えてください。

1. どの静的ファイルを置き換えるのか？

デザインシステムが理論上サポートしているものではなく、本番環境で実際に使われているファイルを列挙してください。ウェイト、スタイル、文字セット、ページテンプレートを含めます。

2. どの軸を公開するのか？

ほとんどのチームはウェイトを公開し、場合によって幅を公開し、それ以上はまれにするべきです。光学サイズは、そのフォントが適切に対応していれば有用ですが、テストしてください。カスタム軸には明確なプロダクト上の目的が必要です。

3. 安全にサブセット化できるか？

サブセット化後に視覚回帰チェックを実行してください。アクセント付き文字、句読点、通貨記号、含まれている場合はアイコン、そしてサポート対象のすべての言語をテストします。

4. フォールバックメトリクスは設定されているか？

適切な場合は、size-adjust、ascent-override、descent-override、line-gap-overrideなどの現代的なCSSツールを使ってください。良いフォールバックメトリクスは、フォント読み込み中のレイアウトシフトを減らします。

5. font-displayは意図的に設定されているか？

font-display: swapは一般的ですが、常に完璧とは限りません。テキストの可視性は改善しますが、フォールバックメトリクスが悪いと目立つ差し替えが発生することがあります。optionalは、確実なブランドタイポグラフィよりも中断の回避が重要な、非クリティカルなフォントに向いている場合があります。

6. 低性能デバイスでテストしたか？

開発者のノートPCでは問題なく感じるフォントでも、低価格のAndroidハードウェアではレンダリングが遅いことがあります。少なくとも1台の低性能デバイス、またはスロットリングされたプロファイルでテストしてください。

7. ロールバック計画はあるか？

フォントの変更はすべてのページに影響します。レンダリング、ローカライゼーション、パフォーマンスの問題が発生した場合にすばやく戻せるよう、古い静的構成を十分な期間残しておいてください。

バリアブルフォントが本番環境で良い選択になる場合

バリアブルフォントは、通常次のような場合に検討する価値があります。

• 同じファミリーから3つ以上のウェイトを使っている。
• 多くのテンプレートにまたがるデザインシステムを維持している。
• 幅や光学サイズを制御するレスポンシブタイポグラフィが必要である。
• ユーザーが1セッションで複数ページを閲覧することが多い。
• フォントパイプラインを適切にサブセット化し、テストできる。

次のような場合は、あまり魅力的ではありません。

• 必要なのが通常と太字だけである。
• バリアブルファイルが現在の構成より大幅に大きい。
• そのフォントが本文サイズでの補間に弱い。
• チームがCSS全体に任意の軸値を散らばらせる可能性がある。
• ローカライゼーションとフォールバック挙動をテストできない。

冷静に見るなら、こうです。バリアブルフォントは能力であり、デフォルトの最適化ではありません。すでにフォントを慎重に管理しているチームには報います。タイポグラフィを装飾として扱い、フォント読み込みを後回しにするチームには不利に働きます。

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

💡 お試しください: 本番環境向けに可変フォントをサブセット化してパッケージ化する際、Webfont Generator は対応するCSS付きのWOFF2出力を生成します。

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

本番環境での経験則

複雑さを減らす、または明確なデザイン成果を実現する場合に、バリアブルフォントを使ってください。「1つのファイル」のほうがきれいに聞こえるから、という理由で使ってはいけません。

優れた本番実装は、たいてい退屈です。慎重にサブセット化された1つのバリアブルフォント、承認された少数の軸値、妥当なフォールバック、抑制されたプリロード、そして実機テスト。無限のタイポグラフィの可能性ほど刺激的ではありませんが、サイトを良くする可能性ははるかに高いものです。