ウェブフォントを最適化する

前のモジュールでは、HTML、CSS、JavaScript、メディア リソースを最適化する方法を学びました。このモジュールでは、ウェブフォントを最適化する方法をいくつかご紹介します。

ウェブフォントは、読み込み時とレンダリング時の両方でページ パフォーマンスに影響を与える可能性があります。大きなフォント ファイルはダウンロードに時間がかかり、初回コンテンツ描画（FCP）に悪影響を及ぼす可能性があります。また、font-display 値が正しくないと、望ましくないレイアウトの移動が発生し、ページの累積レイアウト シフト（CLS）に影響する可能性があります。

ウェブ フォントの最適化について説明する前に、ブラウザがウェブ フォントを検出する方法を知っておくと、特定の状況で CSS が不要なウェブ フォントの取得を防ぐ仕組みを理解するのに役立ちます。

ファインド

ページのウェブフォントは、スタイルシートで @font-face 宣言を使用して定義します。

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}

上記のコード スニペットは、"Open Sans" という名前の font-family を定義し、それぞれのウェブフォント リソースの場所をブラウザに伝えます。帯域幅を節約するため、ブラウザは現在のページのレイアウトで必要と判断されるまでウェブフォントをダウンロードしません。

h1 {
  font-family: "Open Sans";
}

上記の CSS スニペットでは、ブラウザはページの HTML の <h1> 要素を解析するときに "Open Sans" フォントファイルをダウンロードします。

preload

@font-face 宣言が外部スタイルシートで定義されている場合、ブラウザはスタイルシートをダウンロードしてからでないと、ダウンロードを開始できません。そのため、ウェブフォントは遅れて検出されるリソースとなりますが、ブラウザがウェブフォントをより早く検出できるようにする方法があります。

preload ディレクティブを使用すると、ウェブ フォント リソースの早期リクエストを開始できます。preload ディレクティブを使用すると、ウェブフォントがページの読み込みの早い段階で検出され、ブラウザはスタイルシートのダウンロードと解析が完了するのを待たずに、すぐにダウンロードを開始します。preload ディレクティブは、ページでフォントが必要になるまで待機しません。

<!-- The `crossorigin` attribute is required for fonts—even
     self-hosted ones, as fonts are considered CORS resources. -->
<link rel="preload" as="font" href="/fonts/OpenSans-Regular-webfont.woff2" crossorigin>

インライン @font-face 宣言

<style> 要素を使用して、HTML の <head> に @font-face 宣言を含むレンダリング ブロック CSS をインライン化することで、ページの読み込み中にフォントをより早く検出できるようにします。この場合、ブラウザは外部スタイルシートのダウンロードを待つ必要がないため、ページ読み込みの早い段階でウェブフォントを検出します。

@font-face 宣言をインライン化すると、ブラウザが現在のページのレンダリングに必要なフォントのみをダウンロードするため、preload ヒントを使用するよりもメリットがあります。これにより、使用されていないフォントがダウンロードされるリスクを排除できます。

ダウンロード

ウェブフォントを発見し、現在のページのレイアウトで必要であることを確認したら、ブラウザはウェブフォントをダウンロードできます。ウェブフォントの数、エンコード、ファイルサイズは、ブラウザによるウェブフォントのダウンロードとレンダリングの速度に大きな影響を与える可能性があります。

ウェブフォントを自己ホストする

ウェブフォントは、Google Fonts などのサードパーティ サービスを通じて提供することも、オリジンで自己ホストすることもできます。サードパーティ サービスを使用する場合、ウェブページは必要なウェブフォントのダウンロードを開始する前に、プロバイダのドメインへの接続を開く必要があります。これにより、ウェブフォントの検出とダウンロードが遅れる可能性があります。

このオーバーヘッドは、preconnect リソース ヒントを使用して削減できます。preconnect を使用すると、ブラウザが通常よりも早くクロスオリジンへの接続を開くように指示できます。

<link rel="preconnect" href="https://fonts.googleapis.com">  
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

上記の HTML スニペットは、ブラウザに fonts.googleapis.com への接続と fonts.gstatic.com への CORS 接続を確立するよう指示します。Google Fonts などの一部のフォント プロバイダは、異なるオリジンから CSS とフォント リソースを提供しています。

ウェブフォントをセルフホスティングすることで、サードパーティ接続の必要性を排除できます。ほとんどの場合、ウェブフォントをセルフホスティングする方が、クロスオリジンからダウンロードするよりも高速です。ウェブフォントをセルフホスティングする場合は、サイトでコンテンツ配信ネットワーク（CDN）、HTTP/2 または HTTP/3 が使用されており、ウェブサイトに必要なウェブフォントに正しいキャッシュ保存ヘッダーが設定されていることを確認してください。

WOFF2 を使用する（WOFF2 のみ）

WOFF2 は、幅広いブラウザでサポートされており、WOFF よりも最大 30% 優れた最高の圧縮率を実現しています。ファイルサイズが小さくなるため、ダウンロードにかかる時間が短縮されます。WOFF2 形式は、最新のブラウザ間で完全な互換性を確保するために必要な唯一の形式であることがよくあります。

ウェブフォントをサブセット化する

ウェブフォントには通常、さまざまな言語で使用されるさまざまな文字を表すために必要な、幅広い種類のグリフが含まれています。ページで 1 つの言語のコンテンツのみを提供している場合や、1 つのアルファベットを使用している場合は、サブセット化によってウェブフォントのサイズを縮小できます。これは、多くの場合、Unicode コードポイントの数値または範囲を指定することで行われます。

サブセットは、元のウェブフォント ファイルに含まれていたグリフの縮小セットです。たとえば、すべてのグリフを配信する代わりに、ラテン文字の特定のサブセットを配信する場合があります。必要なサブセットに応じて、グリフを削除するとフォントファイルのサイズを大幅に削減できます。

Google Fonts などの一部のウェブフォント プロバイダは、クエリ文字列パラメータを使用してサブセットを自動的に提供しています。たとえば、https://fonts.googleapis.com/css?family=Roboto&subset=latin URL は、ラテン文字のみを使用する Roboto ウェブフォントを含むスタイルシートを提供します。

ウェブフォントをセルフホストすることに決めたら、次は glyphanger や subfont などのツールを使用して、それらのサブセットを自分で生成してホストします。

ただし、独自のウェブフォントをセルフホストする容量がない場合は、ウェブサイトに必要な Unicode コードポイントのみを含む text クエリ文字列パラメータを追加で指定することで、Google Fonts が提供するウェブフォントをサブセット化できます。たとえば、サイトに「Welcome」というフレーズに必要な少数の文字のみを含むディスプレイ ウェブフォントがある場合、次の URL を使用して Google Fonts からそのサブセットをリクエストできます。https://fonts.googleapis.com/css?family=Monoton&text=Welcome。このような極端なサブセット化がウェブサイトで役立つ場合は、ウェブサイトの 1 つの書体に必要なウェブフォント データの量を大幅に削減できます。

フォントのレンダリング

ブラウザがウェブフォントを検出してダウンロードすると、レンダリングできるようになります。デフォルトでは、ブラウザはウェブフォントを使用するテキストのレンダリングを、ウェブフォントがダウンロードされるまでブロックします。font-display CSS プロパティを使用すると、ブラウザのテキスト レンダリングの動作を調整し、Web フォントが完全に読み込まれるまで表示するテキストと表示しないテキストを設定できます。

block

font-display のデフォルト値は block です。block を使用すると、ブラウザは指定されたウェブフォントを使用するテキストのレンダリングをブロックします。ブラウザによって動作が若干異なります。Chromium と Firefox は、フォールバックを使用する前に最大 3 秒間レンダリングをブロックします。ウェブフォントが読み込まれるまで、Safari は無期限にブロックされます。

swap

swap は最も広く使用されている font-display 値です。swap はレンダリングをブロックせず、指定されたウェブフォントに切り替える前に、フォールバックでテキストをすぐに表示します。これにより、ウェブフォントのダウンロードを待たずにコンテンツをすぐに表示できます。

ただし、swap の欠点は、フォールバック ウェブフォントと CSS で指定されたウェブフォントの行の高さ、カーニング、その他のフォント指標が大きく異なる場合に、レイアウト シフトが発生することです。preload ヒントを使用してウェブフォント リソースをできるだけ早く読み込むように注意しない場合や、他の font-display 値を考慮しない場合、ウェブサイトの CLS に影響する可能性があります。

fallback

font-display の fallback 値は、block と swap の妥協点です。swap とは異なり、ブラウザはフォントのレンダリングをブロックしますが、フォールバック テキストへの切り替えはごく短時間のみ行われます。ただし、block とは異なり、ブロック期間は非常に短くなります。

fallback 値は、ウェブフォントがすぐにダウンロードされる高速ネットワークで効果的です。この場合、ウェブフォントはページの初回レンダリングで直ちに使用されます。ただし、ネットワークが遅い場合は、ブロック期間の経過後に最初にフォールバック テキストが表示され、ウェブフォントが到着すると置き換えられます。

optional

optional は最も厳しい font-display 値で、100 ミリ秒以内にダウンロードされた場合にのみウェブフォント リソースを使用します。ウェブフォントの読み込みにそれ以上の時間がかかった場合、そのウェブフォントはページで使用されず、ブラウザは現在のナビゲーションのフォールバック書体を使用します。その間、ウェブフォントはバックグラウンドでダウンロードされ、ブラウザのキャッシュに配置されます。

その結果、ウェブフォントがすでにダウンロードされているため、後続のページ ナビゲーションでウェブフォントをすぐに使用できます。font-display: optional は swap で見られるレイアウト シフトを回避しますが、最初のページ ナビゲーションでウェブフォントの読み込みが遅すぎると、一部のユーザーにはウェブフォントが表示されません。

フォントのデモ

理解度テスト

ブラウザはいつウェブフォント リソースをダウンロードしますか（preload ディレクティブで取得されない場合を想定しています）。

スタイルシートで参照が検出された直後。
もう一度お試しください。
ページの CSSOM が構築され、現在のレイアウトにウェブフォントが必要であると判断された場合。
正解です。

すべての最新ブラウザにウェブフォントを配信するために必要な唯一の（最も効率的な）形式は何ですか？

WOFF2
正解です。
WOFF
もう一度お試しください。
TTF
もう一度お試しください。
EOT
もう一度お試しください。

次は: JavaScript のコード分割

フォントの最適化について理解できたので、次のモジュールに進みましょう。次のモジュールでは、ユーザーの初回ページ読み込み速度を大幅に改善できる可能性のあるトピック、つまりコード分割による JavaScript の読み込みの遅延について説明します。これにより、ユーザーがページを操作する可能性が高い起動フェーズで、帯域幅と CPU の競合を可能な限り低く抑えることができます。