前のモジュールでは、HTML、CSS、JavaScript、メディア リソースを最適化する方法を学びました。このモジュールでは、ウェブフォントを最適化する方法をいくつか紹介します。
ウェブフォントは、読み込み時間とレンダリング時の両方でページ パフォーマンスに影響を与える可能性があります。大きなフォントファイルはダウンロードに時間がかかり、First Contentful Paint（FCP）に悪影響を及ぼす可能性があります。また、font-display 値が正しくないと、望ましくない視覚的なレンダリングのずれが生じる可能性があります。
ウェブ フォントの最適化について説明する前に、ブラウザがウェブ フォントを検出する方法を知っておくと、特定の状況で 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> 要素を使用して、レンダリングをブロックする CSS（@font-face 宣言を含む）を HTML の <head> にインライン化すると、ページ読み込みの早い段階でフォントを検出できるようになります。この場合、ブラウザは外部スタイルシートのダウンロードを待つ必要がないため、ページ読み込みの早い段階でウェブフォントを検出します。
@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 https://fonts.googleapis.com/css?family=Monoton&text=Welcome を使用して Google Fonts にサブセットをリクエストできます。このような極端なサブセット化がウェブサイトで役立つ場合、ウェブサイトの 1 つの書体に必要なウェブフォント データの量を大幅に削減できます。
フォントのレンダリング
ブラウザがウェブフォントを検出してダウンロードすると、レンダリングできるようになります。デフォルトでは、ブラウザはウェブフォントを使用するテキストのレンダリングを、ダウンロードが完了するまでブロックします。font-display CSS プロパティを使用すると、ブラウザのテキスト レンダリングの動作を調整し、ウェブフォントが完全に読み込まれるまで表示するテキストと表示しないテキストを設定できます。
block
font-display のデフォルト値は block です。block を指定すると、ブラウザは指定されたウェブ フォントを使用するテキストのレンダリングをブロックします。ブラウザによって動作が若干異なります。Chromium と Firefox は、フォールバックを使用する前に最大 3 秒間レンダリングをブロックします。Safari は、ウェブ フォントが読み込まれるまで無期限にブロックします。
swap
swap は最も広く使用されている font-display 値です。swap はレンダリングをブロックせず、指定されたウェブフォントに切り替える前に、フォールバックでテキストをすぐに表示します。これにより、ウェブフォントのダウンロードを待たずにコンテンツをすぐに表示できます。
ただし、swap の欠点は、フォールバック ウェブフォントと CSS で指定したウェブフォントの行の高さ、カーニング、その他のフォント指標が大きく異なる場合、コンテンツのずれが目に見えて発生することです。
通常、block で Cumulative Layout Shift（CLS） が悪化することはありません（block では、テキスト自体が表示されない場合でも、代替フォントを想定してページをレイアウトする必要があるため、どちらもコンテンツのシフトの影響を受けます）。ただし、視覚的にはより不快に感じられる可能性があります。
fallback
font-display の fallback 値は、block と swap の妥協点のようなものです。swap とは異なり、ブラウザはフォントのレンダリングをブロックしますが、フォールバック テキストへの切り替えはごく短時間のみ行われます。ただし、block とは異なり、ブロック期間は非常に短くなります。
fallback 値を使用すると、ウェブフォントがすぐにダウンロードされる高速ネットワークでは、ウェブフォントがページの初回レンダリングで即座に書体として使用されるため、うまく機能します。ただし、ネットワークが遅い場合は、ブロック期間が経過した後にフォールバック テキストが最初に表示され、ウェブフォントが到着すると置き換えられます。
optional
optional は最も厳しい font-display 値で、ウェブフォント リソースが 100 ミリ秒以内にダウンロードされた場合にのみ使用されます。ウェブフォントの読み込みにそれ以上の時間がかかる場合は、そのウェブフォントはページで使用されず、ブラウザは現在のナビゲーションのフォールバック書体を使用します。その間、ウェブフォントはバックグラウンドでダウンロードされ、ブラウザのキャッシュに配置されます。
その結果、ウェブフォントはすでにダウンロードされているため、後続のページ ナビゲーションでウェブフォントをすぐに使用できます。font-display: optional は swap で見られる視覚的なずれを回避しますが、最初のページ ナビゲーションでウェブフォントの到着が遅すぎると、一部のユーザーにはウェブフォントが表示されません。
フォントのデモ
理解度テスト
ブラウザはいつウェブフォント リソースをダウンロードしますか（preload ディレクティブで取得されない場合）。
すべての最新ブラウザにウェブフォントを提供するために必要な（最も効率的な）唯一の形式は何ですか？
次の動画: JavaScript のコード分割
フォントの最適化について理解できたので、次のモジュールに進みましょう。次のモジュールでは、ユーザーの初回ページ読み込み速度を大幅に改善できる可能性のあるトピック、つまりコード分割による JavaScript の読み込みの遅延について説明します。これにより、ユーザーがページを操作する可能性が高い起動フェーズで、帯域幅と CPU の競合を可能な限り低く抑えることができます。