本番環境のバリアブルフォント:パフォーマンスを壊さずに出荷する方法

バリアブルフォントは、無限のウェイトを持つ1つのファイルです。正しく出荷しているチームはバイト数を節約し、表現力も手に入れています。間違って出荷しているチームは、誰も見ないアニメーションのために800キロバイトのフォントを読み込み、ファーストペイントをブロックしています。違いを生むのはフォントの選択ではありません。本番での戦略です。

バリアブルフォントは無限のウェイトを持つ1つのファイル

バリアブルフォントは、あらゆるウェイト、スラント、幅を、補間できる軸とともに1つのファイルに収めて出荷します。これが売りのすべてであり、同時にトレードオフのすべてでもあります。1回のネットワークリクエストが、4〜7回のスタティックフォントリクエストの代わりになります。ファイルは個々のスタティックウェイトより大きいものの、スタティックの全ウェイトを合計したものよりは小さくなります。それが取引内容です。

フォーマットは、バリエーションデータを埋め込んだOpenTypeです。ブラウザは描画時に軸の両端の間を補間するので、タイプファウンドリが用意した整数値だけでなく、font-weight: 350 や font-weight: 723 も無料で使えます。ホバーでウェイトが変わるアニメーションが可能になるのはこのおかげです。そして、不用意な実装が、2つのウェイトしか使わないサイトに600キロバイトのファイルを読み込ませる原因にもなります。

出荷する価値のある4つの軸

ウェイト、スラント、オプティカルサイズ、幅。本番サイトで必要なのはたいてい2〜3個で、使わない軸まで出荷するのは無駄なバイトです。

OpenType仕様は5つの登録済み軸を定義しています。ウェイト(wght)、幅(wdth)、スラント(slnt)、イタリック(ital)、オプティカルサイズ(opsz)です。それ以外にも、ファウンドリはグレードから表現力まで何でもカスタム軸として定義できます。カスタム軸は書体見本で見る分には楽しいものです。でも本番でファイルサイズに見合うことはほぼありません。デザイン上どうしても必要でない限り、登録済みの4つに絞りましょう。

ウェイトは働き者

ウェイト軸は、多くのサイトが出荷している4〜7個のスタティックウェイトファイルの代わりになり、それだけでバリアブルフォントの元が取れる軸です。Regular、Medium、SemiBold、Bold、ExtraBoldをスタティックファイルで出荷するサイトは、5回のフォントリクエストをしています。ウェイト軸を持つバリアブルフォントなら1回で済み、中間の値もすべて無料で手に入ります。

CSSは、どの要素でも font-weight: 300 から font-weight: 900 まで指定できます。font-weight: 450 のような中間値も有効で、正しく描画されます。バリアブルフォントが100〜900の全範囲をカバーしていると思い込む前に、ファウンドリの軸範囲のドキュメントを確認してください。一部のフォントはもっと狭い範囲で出荷されていて、黙ってクランプされます。その結果、滑らかな遷移ではなく、微妙にかつ見苦しい段差が出ます。

スラントが本物のイタリックを解放する

本物のスラント軸があれば、アップライトからイタリックまで任意の値で移行できます。ほとんどのスタティックフォントのペアでは、2つ目のファイルなしにこれはできません。slnt(スラント)と ital(イタリック)の違いは重要です。スラントはアップライトからオブリークまでの連続した範囲で、イタリックは、光学的に補正された別のイタリックデザインに切り替わる二値のトグルです。

本文では、きちんとしたオプティカルイタリックを備えたイタリック軸を使うのが、ほぼ常に正解です。アニメーションさせる予定の見出しには、スラント軸が適しています。CSSは font-style: oblique -10deg で、角度の値が軸の範囲に対応します。値を確定する前に、実際の見出しサイズでスラントをテストしてください。極端なスラント角は、ファウンドリの書体見本が示すより、小さいサイズでは見栄えが悪くなります。

オプティカルサイズがディスプレイ書体を生かす

オプティカルサイズは、描画サイズに応じてコントラスト、x-height、ディテールを調整します。ディスプレイ用の書体と本文用の書体の違いが、1つのフォントに組み込まれているわけです。12pxの本文用に設計された書体は、ディテールが簡素で、カウンターが開いていて、余白もゆったりしています。80pxのディスプレイカットは、コントラストが鋭く、字間が詰まり、ディテールがより洗練されています。オプティカルサイズなら、その両方が1つのファイルから手に入ります。

CSSプロパティは font-optical-sizing: auto で、宣言された font-size に基づいて、ブラウザが適切な光学設定を適用します。72pxの見出しなら、font-variation-settings: 'opsz' 72 で手動設定することもできます。この軸を正しくサポートするフォント、代表例はInter DisplayとInter Textですが、それらはオプティカルサイズを第一級の機能として設計されています。後付けで opsz 軸を足しただけのフォントは、意味のある見た目の違いをほとんど生みません。自分が何を買っているのか、見極めましょう。

幅はエディトリアルの軸

幅軸があれば、フォントを入れ替えずに、見出しを圧縮し、プルクォートを拡張できます。エディトリアルレイアウトを歌わせる一手です。CSSプロパティは font-stretch で、パーセンテージで指定します。コンデンスドなら font-stretch: 75%、エクスパンデッドなら font-stretch: 125% です。

この軸がファイルサイズに見合うのは、レスポンシブなエディトリアルレイアウトを持つサイトです。デスクトップで120pxの見出しを、375pxのモバイルのカラムに収めるにはコンデンスドにしたいことがあります。幅軸なら、2つ目のフォントを読み込まずに、1つの @media クエリで対応できます。Roboto Flexは、本番利用できるバリアブルフォントの中でも最も幅広い幅軸の範囲を備えており、この軸を本気で使うつもりなら研究する価値があります。固定幅のヘッダーを持つマーケティングサイトなら、まるごとスキップしてください。

バリアブルかスタティックか、判断ツリー

バリアブルフォントが勝つのは、3つ以上のウェイトを使う、タイプをアニメーションさせる、オプティカルサイズが必要、のいずれかの場合です。それ以外はスタティックのままにしましょう。損益分岐点は通常2〜3ウェイトで、計算は対応する言語の範囲によって変わります。

RegularとBoldだけを出荷するサイトなら、合計40〜60キロバイトの2つのスタティックファイルのほうが、120〜200キロバイトの1つのバリアブルフォントよりおそらく良い選択です。3ウェイトを超えるか、要件にアニメーションが加わった時点で、計算は決定的にバリアブルへ傾きます。

サブセット化でファイルは半分になる

サブセット化は使わないグリフを削ります。マーケティングサイトなら、600キロバイトのバリアブルフォントが、見た目の変化なしに200キロバイトになります。フルのバリアブルフォントには、ファウンドリがデザインしたすべてのグリフが入っています。ラテン文字、ラテン拡張、キリル文字、ギリシャ文字、数学記号、通貨記号、そして一生使わないリガチャまで。サブセット化したバリアブルフォントは、コンテンツに必要なものだけを出荷します。

そのためのツールが、fonttools ライブラリの pyftsubset です。基本的なラテン文字サブセットのコマンドはこちらです。

pyftsubset font.woff2 \ --output-file=font-subset.woff2 \ --flavor=woff2 \ --unicodes=U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD \ --layout-features="kern,liga,calt,rlig"

レイアウト機能の kern、liga、calt、rlig は残してください。デザインで明確に使っていない限り、それ以外はすべて削除します。ツールが圧縮を自動で処理しなかった場合は、出力をWOFF2コンプレッサーに通しましょう。

ラテン、ラテン拡張、言語ごとの範囲

正しいサブセット戦略は、ラテン文字のファイルを1つと、ロケールごとの言語拡張ファイルを1つずつ用意し、必要なときだけ読み込むことです。ほとんどのマーケティングサイトやプロダクトサイトは、主にラテン文字のコンテンツを配信しています。ラテン文字のサブセットをデフォルトとして出荷し、拡張文字セットは @font-face の unicode-range ディスクリプタで読み込みます。これは、ページ上で一致する文字に出会ったときだけファイルを取得するようブラウザに指示するものです。

@font-face { font-family: 'YourFont'; src: url('/fonts/yourfont-latin.woff2') format('woff2'); font-weight: 100 900; font-display: swap; unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'YourFont'; src: url('/fonts/yourfont-latin-ext.woff2') format('woff2'); font-weight: 100 900; font-display: swap; unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF; }

ブラウザは、現在のページ上の文字に一致するファイルだけをダウンロードします。フランス語のページはラテン拡張ファイルを読み込みます。英語のページは読み込みません。これがGoogle Fontsが大規模に配信している方法であり、自分のバリアブルフォントでも真似すべき正しいパターンです。

カクつきのない読み込み

первого描画のあとに読み込まれるバリアブルフォントはレイアウトをずらします。読み込みのレシピは、preloadにfont-displayのswap、そしてメトリクスを合わせたフォールバックです。これは任意ではありません。バリアブルフォントは単一のスタティックウェイトより大きく、届くまでに時間がかかります。つまり、レイアウトシフトが起こりうる時間の窓が広くなります。

preloadのlinkは、どのスタイルシートよりも前の <head> に置きます。

<link rel="preload" href="/fonts/yourfont-latin.woff2" as="font" type="font/woff2" crossorigin >

@font-face の font-display: swap 宣言は、まずフォールバックで即座に描画し、バリアブルフォントが届いたら差し替えるようブラウザに指示します。バリアブルフォントは無限のウェイトを持つ1つのファイルですが、間違った読み込み戦略だと、スタイルシートをまたいでpreloadとpreloadなしの宣言を混ぜた場合に、何の得もなく2回読み込んでしまいます。サブセットファイルごとにpreloadは1つ。ルールはそれだけです。

---

半分のバイト数で出荷され、ページを決してカクつかせないバリアブルフォントが欲しいですか?Brainyに依頼してください。適切な軸、適切なサブセット、そしてLighthouseをグリーンに保つ読み込みレシピを備えた、本番のタイポグラフィスタックを出荷します。

---

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

メトリクスを合わせたシステムフォールバックは、size-adjust、ascent-override、descent-override を使い、バリアブルフォントと同じリズムでフォールバックを描画させます。これがないと、font-display: swap は、見えないテキストをバリアブルフォント到着時のレイアウトシフトと引き換えにするだけです。メトリクスを合わせれば、差し替えは視覚的にまったく気づかれません。

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

正確な値は使うバリアブルフォントによって変わります。Fontaineや next/font のようなツールが、これらの値を自動生成してくれます。Next.jsで構築しているなら、next/font がフォールバックチェーン全体を処理します。そうでないなら、手計算せずに正しいオーバーライド値を得る最速の道がFontaineです。

バリアブルフォントが解放する4つのアニメーションパターン

ホバーウェイト、スクロールウェイト、ホバースラント、リビールウィズ。この4つのアニメーションはバリアブルフォントでしか実現できず、控えめに使えばファイルサイズに見合います。1ページに4つ全部を投入すると、デザインではなく技術デモに見えます。

ホバーウェイトは、ホバー時に font-weight を400から700へ遷移させます。軸のデータがフォントの中にあるので、補間は滑らかです。要素に transition: font-weight 0.15s ease と書くだけで、CSSはそれで全部です。ナビゲーションリンク、行動喚起のテキスト、インタラクティブなラベルで機能します。

スクロールウェイトは、scrollY を軸範囲の値にマップするJavaScriptのスクロールリスナーを使い、スクロール位置から font-weight を駆動します。範囲は狭く保ちましょう。300〜700なら意図的に見えますが、100〜900だとバグに見えます。ユーザーがコンテンツへスクロールするにつれて文字が太くなる、ヒーローセクションに向いています。

ホバースラントは、ホバー時に font-style: oblique 0deg から font-style: oblique -10deg へ遷移させます。ホバーウェイトより控えめな選択肢で、ナビゲーションリンクやインラインのインタラクティブ要素ではより洗練されて見えます。ホバーウェイトとの併用は、その書体が両方を同時にサポートするよう設計されている場合だけにしてください。

リビールウィズは、入場アニメーションの一部として font-stretch をアニメーションさせます。テキストは font-stretch: 75% で登場し、400msかけて font-stretch: 100% まで広がります。フェードインと組み合わせれば、最もクリーンなタイポグラフィの演出パターンの1つです。本文では使わないでください。ディスプレイタイプとヒーロー見出しだけのものです。

バリアブルフォントを大規模に出荷している7つのサイト

GitHub、Stripe Press、Vercel、Linear、The New York Times、Apple Music、Figmaは、いずれも本番でバリアブルフォントを出荷しており、彼らに共通するパターンこそ真似る価値があります。

GitHubは、Mona SansとHubot Sansを出荷しています。どちらもGitHubブランドのために作られたカスタムのバリアブルフォントです。ほとんどのUIの場面ではウェイト軸のみ。たまにあるマーケティングセクション以外ではアニメーションなし。言語グループごとに積極的にサブセット化しているので、ファイルサイズは引き締まっています。

Stripe Pressは、エディトリアルの見出しにカスタムのディスプレイ用バリアブルフォントを使っています。ウェイト軸を大胆に使い、ディスプレイの見出しは重いウェイト、キャプションは軽いウェイトを、1つのファイルから出しています。大きな見出しサイズではオプティカルサイジングがはっきり見て取れます。このリストの中で、エディトリアルとして最も野心的なバリアブルフォントの使い方です。

Vercelは、自社のバリアブルフォントGeistを、Geist SansとGeist Monoの両方で出荷しています。ウェイト軸は全範囲をカバーしています。フォントはオープンソースで、ラテン文字のサブセット化もきれいで、十分に速く読み込まれるため、本番のNext.jsアプリでうまく出荷されたバリアブルフォントがどういうものかの基準になります。

Linearは、Interをバリアブルフォントとして出荷しています。ウェイト軸はUI向けのウェイトの範囲にわたり、高密度なUIにふさわしい、より狭いオプティカルなウェイト範囲にとどまっています。このリストで最も保守的な使い方であり、アニメーションがノイズになるデータ密度の高いプロダクトUIとしては、最も正しい使い方の1つでもあります。

The New York Timesは、ディスプレイタイプにカスタムのバリアブルセリフ体を使っています。ウェイトとオプティカルサイズの両方の軸が有効で、ディスプレイと本文の間の遷移では、オプティカルサイズ軸を使って文字の描画の性格を切り替えています。エディトリアル規模のバリアブルフォントの本番利用として、これ以上洗練されたものはありません。

Apple Musicは、San Franciscoをバリアブル形式で出荷し、ウェイトとオプティカルサイズの両方の軸を有効にしています。大きな文字と小さな文字の間の軸の遷移は十分に滑らかで、ほとんどのユーザーはフォントがバリアブルだと気づきません。それが正しいゴールです。フォントは読書体験の中に消えるべきなのです。

Figmaは、アプリケーション全体でInter Displayをバリアブルフォントとして出荷しています。プロダクトUIのディスプレイ書体の選定をしているなら、Figmaが小さなUIウェイトのInterと、大きな見出しサイズのInter Displayをどうバランスさせているか研究してください。ウェイト範囲の規律は、そのまま真似る価値があります。

デプロイ前のバリアブルフォント チェックリスト

バリアブルフォントを出荷する前にこれを実行すれば、本番で牙をむくバグを捕まえられます。

• サブセット化を検証済み。 対象のUnicode範囲を指定して pyftsubset を実行する。ラテン文字のサブセットファイルが200KB未満であることを確認する。コンテンツで使う文字が出力に含まれているか、抜き取りで確かめる。
• 軸を文書化済み。 フォントがどの軸を持ち、それぞれの最小値と最大値が何かを把握する。軸の上限が700なら font-weight: 800 を宣言しない。黙ってクランプされ、デザインが狂う。
• preloadを設定済み。 サブセットファイルごとに <link rel="preload"> を1つ、<head> 内に、crossorigin 属性付きで、主要なラテン文字ファイルだけを指して置く。使わないファイルをpreloadすると帯域を無駄にする。
• font-displayを設定済み。 すべての @font-face ブロックに font-display: swap がある。DevToolsのNetworkタブで、フォントがクリティカルパスのリソースのレンダリングをブロックしていないことを確認する。
• フォールバックのメトリクスを一致済み。 システムフォールバック用の @font-face ブロックに、size-adjust、ascent-override、descent-override を計算して設定する。DevToolsでSlow 3Gにスロットリングし、読み込み時のレイアウトシフトを確認して検証する。CLSは0か、0に近いはず。
• デザインで使う軸を確認済み。 CSSで宣言したすべての軸が、最終デザインで実際に使われている。フォントファイルにあってCSSで使わない軸も、バイトを増やす。幅を使わないなら、軸範囲のサブセット化でそのバイトを削ることを検討する。
• Lighthouseスコアを確認済み。 フォントを組み込んだ本番URLでLighthouseを実行する。フォント関連のLCPとCLSはグリーンのはず。そうでなければ、フォールバックのメトリクスが間違っているか、preloadが抜けている。
• CORSヘッダーを確認済み。 CDNや外部オリジンから読み込むバリアブルフォントには Access-Control-Allow-Origin ヘッダーが必要。NetworkタブでCORSエラーがないか確認する。CORSの失敗は、本番では診断しづらい、サイレントなフォントフォールバックを引き起こす。

FAQ

バリアブルフォントとは何ですか。スタティックフォントとどう違いますか?

バリアブルフォントは、ウェイト、幅、スラント、オプティカルサイズといった軸で制御される、書体のデザインの全範囲を含む単一のフォントファイルです。スタティックフォントは、1つのウェイトとスタイルでの単一のスナップショットです。実用上の違いは、バリアブルフォントならCSSで font-weight: 350 を使ったり、ウェイトを滑らかにアニメーションさせたりできる一方、スタティックフォントでは、ファウンドリが別ファイルとして出荷した特定の値しか使えないことです。

バリアブルフォントは本当にパフォーマンスを向上させますか?

読み込んでいるウェイトの数によります。合計60KBの2つのスタティックウェイトを出荷しているなら、180KBのバリアブルフォントへの切り替えはパフォーマンスの退行です。合計300KBの5つのウェイトを出荷しているなら、120KBのサブセット化したバリアブルフォントへの切り替えは明確な勝ちです。バリアブルフォントのパフォーマンス上の根拠は本物ですが、成り立つのは3ウェイトの閾値を超え、かつ正しくサブセット化したときだけです。

UIデザインに最適なバリアブルフォントは何ですか?

Interは、UIデザインで最も広く使われているバリアブルフォントです。ウェイト軸が画面での使用に適切に調整されていて、きれいにサブセット化でき、Figmaが本番の基準として出荷しています。レスポンシブなエディトリアルレイアウトのために広い軸範囲が必要なら、Roboto Flexが正しい選択です。1つのタイプファミリーからバリアブルのサンセリフとバリアブルのモノの両方が欲しいなら、Recursiveは研究する価値があります。より表現力のあるディスプレイ書体を求めるWebデザインの原則であれば、FrauncesとPlayfair Displayはどちらも優れたオプティカルサイズ軸とウェイト軸を備えています。

CSSでfont-variation-settingsはどう使いますか?

font-variation-settings は、4文字の軸タグと数値を使って、バリアブルフォントの軸を直接設定する低レベルのプロパティです。font-variation-settings: 'wght' 450, 'wdth' 85 のように書きます。ウェイトや幅のような登録済みの軸には、継承や合成が正しく働くので、高レベルのCSSプロパティ(font-weight、font-stretch)を優先してください。font-variation-settings は、高レベルのCSSプロパティがないカスタム軸にだけ使いましょう。

バリアブルフォントはレイアウトシフトを起こしますか?

はい。しかも、ファイルが大きく読み込みに時間がかかるため、スタティックフォントよりレイアウトシフトを起こしやすいです。対策は、font-display: swap とメトリクスを合わせたフォールバックの組み合わせです。この組み合わせで、差し替えは視覚的に気づかれなくなります。メトリクスを合わせたフォールバックがなければ、font-display: swap は、見えないテキストをフォント到着時の目に見えるレイアウトの跳ねと引き換えにするだけです。2つの問題は、一緒に解決するか、まったく解決しないかのどちらかです。

バリアブルフォントはすべてのブラウザでサポートされていますか?

バリアブルフォントは、Chrome、Firefox、Safari、Edgeなど、すべてのモダンブラウザでサポートされています。ベースラインは十分に堅く、ブラウザ互換性のためにスタティックフォントのフォールバックは必要ありません。バリアブルフォントをサポートしないブラウザを使うユーザーの割合は、ほとんどの本番サイトで1パーセント未満です。そのエッジケースには、スタティックフォントのスタックではなく、システムフォントのフォールバックを用意してください。

バリアブルフォントのサブセット化はどのように動きますか?

サブセット化は、Pythonの fonttools ライブラリの pyftsubset のようなツールを使って、コンテンツが決して描画しないグリフをフォントファイルから取り除きます。必要なUnicode文字範囲を指定すると、ツールがそれ以外をすべて削ぎ落とします。フルのバリアブルフォントには3,000グリフが入っていることもあります。ラテン文字のみのサブセットなら約250グリフが残ります。結果は、ラテン文字のコンテンツでは見た目がまったく同じで、ファイルサイズはおよそ3分の1です。完全なコマンドリファレンスは、サブセット化の用語集の項目を参照してください。

バリアブルフォントが本当に解放するシフト

バリアブルフォントは、タイポグラフィの珍品ではありません。より少ないバイト数で、より多くの表現を出荷するための手段であり、それを本番のツールとして扱っているチームこそ、より低いネットワークコストで、より優れたタイポグラフィを実現しています。

現代のデザインシステムを動かすFigma variablesのアーキテクチャは、バリアブルフォントの軸と自然に対応します。Figmaの font-weight トークンは、フォントの軸の値です。きちんと構造化されたトークンシステムと、適切にサブセット化したバリアブルフォントを組み合わせれば、デザインファイルから本番まで、曖昧さなくデザインの決定が伝わります。そこにホバー状態のOKLCHカラーシステムを組み合わせれば、寄せ集めではなく、練られたと感じるプロダクトのインタラクションが作れます。

本番のバリアブルフォントの基準は、「バリアブルフォントを出荷したか」ではありません。基準は、正しくサブセット化し、適切にpreloadし、フォールバックのメトリクスを合わせ、デザインが使う軸だけを持つことです。それが、本番のタイポグラフィをやっているチームと、タイポグラフィ劇場をやっているチームを分ける基準です。

半分のバイト数で出荷され、ページを決してカクつかせないバリアブルフォントが欲しいですか?Brainyに依頼してください。適切な軸、適切なサブセット、そしてLighthouseをグリーンに保つ読み込みレシピを備えた、本番のタイポグラフィスタックを出荷します。