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

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

ウェブフォントは、読み込み時間とレンダリング時間の両方でページのパフォーマンスに影響する可能性があります。フォント ファイルのサイズが大きいと、ダウンロードに時間がかかり、First Contentful Paint（FCP）に悪影響を及ぼす可能性があります。また、font-display 値が間違っていると、ページの Cumulative Layout Shift（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 宣言をインライン化する

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

ブラウザは現在のページのレンダリングに必要なフォントのみをダウンロードするため、@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 web フォントのスタイルシートを提供します。

ウェブフォントを自己ホストする場合は、次のステップとして、glyphanger やサブフォントなどのツールを使用して、サブフォントのサブセットを自身で生成してホストします。

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

フォントのレンダリング

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

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 の競合を可能な限り低く抑えることができます。