あなたはフォントを間違って読み込んでいる――そしてそれがパフォーマンスを損なっている
(jonoalderson.com)- WebフォントはWebサイトの視覚要素であり、ブランドとユーザー体験を形作ると同時に、パフォーマンスとアクセシビリティへ直接影響する
- 誤ったフォント読み込み方法は FOUT（スタイルなしテキストのちらつき）や FOIT（非表示テキストのちらつき）を引き起こし、Core Web Vitals に悪影響を与える
- WOFF2 形式はモダンで効率的なフォントフォーマットであり、ほとんどの最新ブラウザでサポートされているため、不必要なレガシーフォーマットを削除してパフォーマンスを改善できる
- フォントのサブセット化と preload 戦略は、不要なデータ転送を減らし、ページ読み込み速度を高めるうえで不可欠
- システムフォントスタックと CSSディスクリプタを活用することで、フォント読み込み時のレイアウトシフト（CLS）を最小化し、安定したユーザー体験を提供できる
Webフォントの簡単な歴史
WebフォントはWebデザインとユーザー体験の中核要素だが、その重要性にもかかわらず、多くの人が誤った方法で使っている。以下はWebフォントの発展過程の整理。
-
「Webセーフ」時代
- 初期のWebでは Arial、Times New Roman のような Webセーフフォントしか使えず、カスタムフォントは画像で代用されていた
- ブラウザごとにフォントレンダリングが異なり、一貫したデザインを実現しにくかった
-
@font-face以前のハック: sIFRとCufón
- sIFR: Flashを使ってテキストを動的にレンダリングしていたが、重く、アクセシビリティも低かった
- Cufón: JavaScriptでフォントをベクターグラフィックに変換して埋め込んでいたが、遅く、アクセシビリティの問題も残った
-
@font-faceの登場
- @font-face によりCSSでカスタムフォントを埋め込めるようになったが、ブラウザごとに異なるフォーマット（EOT、SVGフォント、TTF/OTF）を要求し、複雑だった
- フォントライセンスの問題や違法コピーも広がっていた
-
商用サービス: Typekitとその仲間たち
- Typekit（現 Adobe Fonts）は、ライセンスと互換性の問題を解決したサブスクリプション型サービスで、JavaScriptスニペット経由でフォントを提供した
- サードパーティスクリプトに依存するパターンは、現在まで続いている
-
互換性ハックと回避策
- 複数フォーマットをホスティングしたり、FOUT や FOIT を解決するためのJavaScriptによる修正が必要だった
- グリフ不足の問題を解決するため、アイコンフォントを使おうとする試みもあった
-
Google Fontsと「無料フォント」ブーム
- Google Fonts は無料のオープンライセンスフォントによってフォント読み込みの手軽さを提供した一方、GDPR違反の問題や遅い読み込み速度によって新たな問題も生んだ
- ライセンス制限のため最適化しにくい商用フォントと異なり、Google Fontsは自由に使えた
フォントの動作の仕組み（基本）
フォントは単なるCSS設定ではなく、ブラウザの レンダリングパイプライン に深く関与する複雑な要素だ。
-
フォーマット: TTFからWOFF2まで
- TTF/OTF: デスクトップ中心の重いフォーマット
- WOFF2: Brotli圧縮 を使ったモダンで効率的なWebフォント形式であり、ほとんどのプロジェクトに適している
-
レンダリングパイプライン
- フォント読み込みは 登録、スタイル解決、フォントマッチング、グリフカバレッジ、リクエスト、表示段階、デコードとシェーピング の各段階を経る
- font-display 設定（swap, block, fallback, optional）はテキストの表示方法を決定する
-
メトリクス
- Ascent、descent、line gap のようなメトリクスはフォントの高さと間隔を定義する
- フォント置き換え時にメトリクスが一致しないと、レイアウトシフト（CLS）が発生することがある
-
合成スタイル
- ブラウザが要求された font-weight や style を見つけられない場合、偽の太字やイタリックを生成し、品質が低下する
- font-synthesis: none; で偽スタイルの生成を防げる
-
グリフカバレッジ
- フォントはすべての文字を含むわけではなく、欠けたグリフは 代替フォント でレンダリングされるため、一貫性の問題が生じる
- unicode-range を使って必要なグリフだけを読み込むよう設定できる
パフォーマンスと戦略の基礎
フォントは クリティカルレンダリングパス に影響し、管理を誤ると性能低下を招く。
-
ファイルサイズ
- 単一のフォントファミリーが最大 800KB に達することもあり、不要なグリフを含むことでデータの無駄が発生する
- フォントのサブセット化 により必要なグリフだけを送信し、サイズを最適化できる
-
レイアウトシフト
- 代替フォントとカスタムフォントの メトリクス差 によってCLSが発生する
- size-adjust、ascent-override のようなCSSディスクリプタでレイアウトを安定化できる
-
モダンなCSSディスクリプタ
- font-display: swap; は代替フォントを即座に表示し、安定したレンダリングを提供する
- unicode-range によって特定スクリプトに必要なグリフだけを読み込める
可変フォント: 約束と現実
可変フォント は1つのファイルで多様なスタイルとウェイトをサポートでき、効率性を高められる。
-
約束
- 複数の静的ファイルを単一ファイルに統合
- ビューポートサイズに応じて動的に調整できる レスポンシブタイポグラフィ
-
現実
- 必要なウェイトが少ないなら、可変フォントのほうが重くなる場合がある
- ブラウザサポート は一部の軸で制限があり、ライセンス問題が生じる可能性もある
-
パフォーマンス戦略
- 必要な軸だけを選び、スクリプト別サブセット化 でファイルサイズを最適化する
- 静的フォントと比べて本当に利点があるか確認する
-
CSSでの可変フォント軸の使用例
@font-face { font-family: "Acme Variable"; src: url("/fonts/acme-variable.woff2") format("woff2-variations"); font-weight: 100 900; font-display: swap; } h1 { font-family: "Acme Variable", system-ui, sans-serif; font-weight: 700; }
システムスタックとCDN
カスタムフォントなしで システムフォントスタック を使えば、即時読み込みと親しみやすい体験を提供できる。
-
システムフォントスタック
- -apple-system、Segoe UI などで構成されたスタックは、あらゆるプラットフォームで一貫性を保ちやすい
- 絵文字レンダリングではシステムフォントのほうが優れた性能を示す
-
CDNとサードパーティホスティング
- Google Fonts はデータ流出によりGDPR違反となる可能性がある
- セルフホスティング によりDNSルックアップ遅延を減らし、キャッシュ制御も可能になる
代替フォントとマッチング
代替フォントはカスタムフォント読み込み前のユーザー体験を左右するため、安定した設計が必要だ。
-
代替フォント設計
- x-height と 文字幅 をカスタムフォントに近づけて設定し、CLSを最小化する
- font-size-adjust で代替フォントのサイズを調整する
-
カスタムフォントと代替フォントのマッチング
- 近い比率のフォントを選び、メトリクス調整 によってレイアウト安定性を確保する
- プラットフォームごとのレンダリング差を考慮し、安定性 と 可読性 を優先する
プリロードと読み込み戦略
フォント配信戦略はユーザー体験に大きな影響を与える。
-
読み込みの結果
- FOIT は低速ネットワークでテキストが見えなくなる問題を引き起こす
- font-display: swap; は安全なデフォルトであり、代替フォントを即座に表示する
-
プリロード
<link rel="preload" as="font">を使ってフォント読み込みを即座に開始する- CORSヘッダー と正確なURL一致が必須
-
Early Hints (HTTP 103)
- サーバーがHTMLレスポンス前にフォント取得を指示し、読み込み時間を短縮できる
- クリティカルフォント だけをヒント対象にして帯域の浪費を防ぐべき
-
フォントローディングAPI
- Font Loading API は動的サイトでフォント読み込みを細かく制御できる
ファイルフォーマット: WOFF2、WOFF、TTFとレガシー負債
WOFF2 はモダンWebで最も効率的な形式であり、多くの場合は単一フォーマットで十分。
- WOFF2 だけを使って不要な形式を削除
- base64埋め込み はキャッシュを妨げるため避けるべき
アイコンフォント: Font Awesomeと大きな失敗
アイコンフォント はアクセシビリティとパフォーマンスの問題から、モダンWebには適していない。
- SVGアイコン は意味的で柔軟性があり、CSSでスタイリングできる
- 既存のアイコンフォントを使う場合は、サブセット化 とSVGへの移行計画が必要
ラテン文字を超えて: 非ラテン文字、RTL言語、絵文字
非ラテン文字と RTL言語 は複雑なシェーピングとメトリクスを必要とする。
- サブセット化 の際はスクリプトごとの特性を考慮し、レンダリングエラーを防ぐ
- 絵文字 はシステムフォントを使うことで一貫性と性能を改善できる
Webフォントの未来: 進化する標準と現代的なリスク
新しいCSSプロパティと 可変フォント、カラーフォント がWebタイポグラフィを進化させている。
- フォントローディングAPI と Early Hints により、SPAでの遅延問題を解決できる
- フォントを インフラ と見なし、パフォーマンスとアクセシビリティを優先すべき
ツールと監査
フォントパフォーマンスは DevTools、Lighthouse、Glyphhanger のようなツールで測定できる。
- フォントのサブセット化 ツールで不要なグリフを削除
- Font Style Matcher で代替フォントのメトリクスを調整
フォントを正しく扱うための宣言
フォントは単なる装飾ではなく、ユーザー体験 と パフォーマンス の中核要素だ。
- システム優先: 堅牢なシステムフォントスタックから始める
- 賢いサブセット化: 必要なグリフだけを送る
- WOFF2専用: レガシーフォーマットを削除
- グローバルスクリプトを尊重: 多様な言語と絵文字をサポート
- テスト重視: 多様なネットワークとデバイスでテストする
フォントを コンテンツ であり ブランド でもあるものとして扱い、パフォーマンスとアクセシビリティに対する厳格な管理を適用すべきだ
1件のコメント
Cufón、本当に久しぶりに聞く名前ですね（笑）