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

前のモジュールでは、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 ウェブフォントを使用したスタイル シートを提供します。

ウェブフォントを自社でホストする場合は、次のステップとして、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 の競合を可能な限り少なく抑えることができます。