コア Web バイタルを改善するための 8 つのフォント読み込み戦略 (2022)

公開: 2022-10-15

最初は 2021 年 10 月に公開され、2022 年 10 月に包括性を高めるために更新されました

Web パフォーマンス、特に Core Web Vitals (CWV) について話すと、画像と JavaScript の最適化技術が脚光を浴びているように思えます。

ただし、見落としてはならないもう 1 つのプレーヤーがあります。それは Web フォントです。

それらは多くの場合、読み込みに時間がかかり、テキストのレンダリングをブロックする可能性さえある大きなファイルであることを考慮すると、フォントの最適化は全体的なパフォーマンス戦略の重要な部分です.

タイポグラフィは、優れたデザイン、ブランディング、読みやすさ、アクセシビリティの基本でもあります。 そして、これらすべてを可能にするのが Web フォントです。

次の行では、フォントが Core Web Vitals にどのように影響するか、およびフォントの読み込みを最適化する方法について説明します。

 さぁ、始めよう！

フォントの読み込みについて知っておくべきこと (一言で言えば)

すべての問題を解決できる単一のフォント最適化手法はありません。

少し厳しいかもしれませんが、これが真実です。 フォントの読み込みは、何年もの間、Web パフォーマンスの大きな原因となっています。 また、Web フォントを提供するための現在の戦略にはすべて、重大な欠点があります。

かなり長い間、Web フォントを提供する場合、次のいずれかを選択する必要がありました。

  • フォントがダウンロードされるまでテキストが非表示になるFlash of Invisible Text (FOIT) 。

または

  • Flash of Unstyled Text (FOUT)は最初にフォールバック システム フォントを使用し、ダウンロード時に Web フォントにアップグレードします。

簡単に言えば、訪問者に空白の画面を見つめさせるか、Web サイトで予期しないレイアウトの変化が発生するリスクを冒す可能性があります。

どちらも、今日の Core Web Vitals の世界では受け入れられないソリューションです。

基本的に、フォントの読み込み状況は次のとおりです。

ツイッター投稿

次に、 font-displayプロパティが発表されました。

font-displayは、関連する Web フォントがロードされていない場合にテキストのレンダリングをどのように進めるかをブラウザーに指示します。 font-faceごとに定義されます。

ブラウザには、まだ利用できないフォント ファミリを使用するテキストをレンダリングするときのデフォルトのフォント読み込み動作があります。

ブラウザのデフォルトのフォント読み込み動作

ソース: web.dev

フォントのダウンロードのプロセスは、次の 3 つの主要な期間に分けられます。

  • 最初の期間はフォント ブロック期間です。 この期間中にfont-faceが読み込まれない場合、それを使用しようとする要素は、代わりに非表示のフォールバック フォント フェイス (FOIT) でレンダリングする必要があります。 この最初の期間中にfont-face が正常に読み込まれると、通常どおり使用されます。
  • フォント スワップ期間は、フォント ブロック期間の直後に発生します。 この期間中にfont-faceがロードされない場合、それを使用しようとする要素は、代わりにフォールバック (システム) フォント (FOUT) でレンダリングする必要があります。 この期間中に font-face が正常にロードされた場合、フォントは通常どおり使用されます。
  • フォント障害期間は、フォント スワップ期間の直後に発生します。 この期間の開始時にフォントがまだロードされていない場合は、ロードの失敗としてマークされ、通常のフォント フォールバックが発生します。

これらの期間を理解すると、 font-display値をより効果的に使用できるようになります。

  • font-display: autoは、ユーザー エージェントが使用するフォント表示戦略を使用します。
  • font-display: blockは、フォントに 3 秒 (ほとんどの場合) の短いブロック期間と無限のスワップ期間を与えます。 つまり、ロード時に常に Web フォントにスワップします。 ページにとってフォントが重要な場合は、この値を使用します。
  • font-display: swapは、読み込まれるとすぐにフォントを表示します。 ブロックと同様に、この値は、特定のフォントでテキストをレンダリングすることがページにとって重要な場合にのみ使用する必要があります。
  • font-display: フォールバックはテキストを最大 100 ミリ秒非表示にし、3 秒以内にロードされた場合にのみ Web フォントでスワップします。 3 秒間のスワップ期間中にフォントが読み込まれない場合、フォールバックはページの残りの有効期間に使用されます。
  • font-display: オプションで、フォント フェイスに 100 ミリ秒の最小ブロック期間を指定します。 その後、フォントがまだ使用できない場合は、フォールバックにとどまり、スワップされることはありません。 基本的に、オプションの値は、フォントのダウンロードを開始するかどうかを決定するブラウザに任せます。

フォント表示値
 出典: Web フォントによるレイアウトのずれを回避する方法


サイトで使用する font-display 値を決定する際の目安として、次の Google の推奨事項を参考にしてください。

「フォント表示戦略は、パフォーマンスと美学の間のトレードオフに関するさまざまな視点を反映しています。 ほとんどのサイトでは、次の 2 つの戦略が最も適切です。
  • パフォーマンスが最優先の場合: font-display: optional を使用します。 これは最も「パフォーマンスの高い」アプローチです。テキスト レンダリングの遅延は 100 ミリ秒以内であり、フォント スワップに関連するレイアウト シフトがないことが保証されます。
  • Web フォントでテキストを表示することが最優先の場合: font-display: swap を使用しますが、レイアウトのずれを引き起こさないように、フォントを早期に配信するようにしてください。」

先に述べたように、フォントの読み込みに関して考えられるフォントの問題をすべて解決する完全な解決策はまだありません。 Google 自身がこれらの手順を推奨していますが、リスクがないわけではありません。

実際、一部のfont-display値は、Core Web Vitals を悪化させる可能性があります。

フォントがコア ウェブ バイタルに与える影響 (CLS & LCP)

Core Web Vitals に精通している場合は、一部のフォント読み込み方法が影響を与える可能性があることをご存知でしょう。

たとえば、フォントが読み込まれていない場合 (FOIT)、ブラウザは通常、テキストのレンダリングを遅らせます ( font-display: block )。 場合によっては、これにより First Contentful Paint (FCP) と Largest Contentful Paint (LCP) が遅延します。

一方、フォント スワッピングの実行は、累積レイアウト シフト (CLS) メトリックに直接関連する予期しないレイアウト シフトを引き起こすことでよく知られています。

それでは、フォント読み込みのベスト プラクティスを見て、CWV メトリックをチェックしてみましょう。

重要: CWV メトリックへの影響に基づいて次の手法を分類しましたが、それは一般的なベスト プラクティスではないという意味ではありません。 以下に挙げる方法はすべて、全体的なフォント読み込みプロセスとサイトのパフォーマンスを向上させることができます。


フォント読み込み時のレイアウトシフトの回避 (CLS)

累積レイアウト シフトは、ページ上の予期しないレイアウト シフトの重要性を測定します。 ユーザーの入力や事前の通知なしにページ上のコンテンツが移動すると、予期しないレイアウトの変化が発生します。

累積レイアウトシフト

フェッチとレンダリングのプロセスで、次の 2 つのことが原因でレイアウト シフトが発生する可能性があります。

  • フォールバック フォントが新しいフォント (FOUT) と交換されます。
  • フォントがレンダリングされるまで「非表示」のテキストが表示されます (FOIT)。

これらの問題に対処するために、次のベスト プラクティスのいくつかを実装できます。

1) link rel=preloadとfont-display を組み合わせる: オプション

link rel=preloadとfont-display: optionalを組み合わせるオプションは、Chrome 83 以降で利用可能であり、レイアウト シフトを回避する確実な方法であると言われています。

前述のように、フォントがfont-display: オプションの値を使用する場合、ブラウザーがフォールバックに戻る前にダウンロードして実行するのに 100 ミリ秒かかります。

フォントが 100 ミリ秒マークの前にダウンロードされた場合、カスタム フォントがページで使用されます。

これにより、ブラウザーがページを再レンダリングし、その結果、目に見えないテキストがわずかにちらつきます。

Chrome 83 では、リンク rel=preloadを使用するオプションのフォントの最初のレンダリング サイクルが削除され、カスタム フォントが読み込まれるか期間が完了するまでのブロック期間 (100 ミリ秒) に置き換えられます。

フォントがプリロードされ、100 ミリ秒のブロック期間後にダウンロードされると、フォントのロード プロセスは次のようになります。

フォントの読み込み

そして、フォントがプリロードされ、100 ミリ秒マークの前にダウンロードされると、次のようになります。

フォントの読み込み


この手法は、予期しないレイアウトのシフトやスタイル設定されていないテキストのフラッシュの問題をほぼ解決します。


2) サイズ調整を使用する

フォント スワッピングのもう 1 つの問題は、Web フォントが読み込まれるときに、わずかに異なるボックスの高さのサイズで表示されるため、ページ全体が移動することがあることです。

size-adjust記述子を font-face ルールに入れると、視覚的な変化が最小限に抑えられ、ほぼシームレスな交換が行われます。

実装方法については、@font-face の CSS size-adjust に関する Google のガイドをご覧ください。


3) フォールバック フォントを Web フォントと一致させる

スワップ効果を減らすには、フォールバックと Web フォントをできるだけ同じように見せるようにしてください。 もちろん、シフトを完全に回避することはできませんが、ユーザー エクスペリエンスをそれほど損なわないように、シフトの影響を少なくすることはできます。

Monica Dinculescu による Font Style Matcher アプリは、フォント マッチングのツールとしてよく知られています。

同じテキストを 2 つの異なるフォントでオーバーレイして、それらの違いを確認できます。 その後、フォント設定を調整して、より密接に整列させることができます。

フォントオーバーラップツール


残念ながら、他のフォント読み込み最適化手法と同様に、リスクとハードルがあります。

フォント スタイル マッチングの問題は、これらの CSS スタイルをフォールバック フォントだけに適用することができないため、JavaScript と FontFace.load API を使用して、Web フォントの読み込み時にこれらのスタイルの違いを適用する必要があることです。

2018 年の講演で、Zach Leatherman はこの手法をさらに詳しく説明しています。


フォントができるだけ速く読み込まれるようにする (LCP & FCP)

フォントの読み込みと Largest Contentful Paint メトリクスの改善については、もう少し一般的なテクニックを使用します。

LCP は、スクロールせずに見える最大のコンテンツ要素 (テキスト、画像など) の読み込みにかかる時間を測定します。 2.5 秒未満はすべて、適切な LCP 時間と見なされます。

最大のコンテンツペイント

CWV の一部ではないが、重いフォント ファイルをロードすることによって影響を受ける可能性がある別のメトリックは、First Contentful Paint (FCP) です。

FCP は、ブラウザーがページ上の最初の DOM コンテンツ (テキスト ブロック、画像、SVG、空白でないキャンバス要素など) を視覚化するのにかかる時間を測定します。

どちらの指標も、ウェブサイトがスクロールせずに見える範囲のコンテンツの要素を描画する速度を測定します。これは、訪問者の第一印象に大きな役割を果たします。

空白の画面を長時間 (FCP) 見つめていると、ユーザー エクスペリエンスは良くありません。 最大/ヒーロー要素 (LCP) がレンダリングされるまでの待ち時間が長すぎる場合も同様です。

Web フォントを最適化することは、サイトの知覚パフォーマンスを改善し、より良いユーザー エクスペリエンスを保証する 1 つの方法です。

試してみたいテクニックをいくつか紹介します。

1) フォントを圧縮する

フォント圧縮の仕組みを理解するには、Web フォントの構造を理解する必要があります。

Web フォントはグリフの集まりであり、各グリフは文字または記号を表すベクトル形状です。 個々のグリフは異なりますが、圧縮可能な類似の情報が多数含まれています。

正しい圧縮を適用できるようにするには、まずさまざまなフォント形式を知る必要があります。

  • Embedded OpenType (EOT) - 古い IE (I9 未満) ブラウザーに提供できます。 デフォルトでは圧縮されません。 このフォントに GZIP 圧縮を適用できます。
  • TrueType (TTF) - 古い Android (4.4 未満) ブラウザーに提供できます。 デフォルトでは圧縮されません。 このフォントに GZIP 圧縮を適用できます。
  • Web Open Font Format (WOFF) - ほとんどのブラウザーに提供できます。 コンプレッションを内蔵しています。
  • Web Open Font Format 2 (WOFF 2) - サポートしているブラウザーに提供できます。 カスタム圧縮アルゴリズムを使用して、他の形式よりも最大 30% のファイル サイズ削減を実現します。

次に、オンライン ツールを使用するか、いくつかのサーバー構成を作成して、(必要に応じて) GZIP 圧縮を適用できます。


2) インラインフォント

通常、フォントは外部の CSS スタイルシートに保存されます。 スタイルシートを使用するには、次のように HTML マークアップのheadタグにリンクを配置します。

外部CSS

ただし、外部 CSS ファイルを実行すると、ブラウザが最初にファイルを見つけてダウンロードする必要があるため、時間がかかります。

フォントの読み込みプロセスを高速化するために、フォント宣言やその他の重要なスタイルを、外部のスタイルシートに保持するのではなく、メイン ドキュメントのheadタグにインライン化できます。

インライン フォント

これにより、ブラウザは外部スタイルシートのダウンロードを待つ必要がないため、フォントの検索とレンダリングをより高速に開始できます。

重要:フォントのインライン化は注意が必要な手法です。 大きなフォント リソースをインライン展開したり、フォントが多すぎたりすると、メイン ドキュメントの配信や他のリソースの検出が遅れる可能性があります。 可能であれば、この変更が Web サイトのパフォーマンスにどのように影響するかをデプロイ前とデプロイ直後にテストしてください。


3) フォントがすぐにダウンロードされることを確認します

セルフホスティングフォントを選択するか、サードパーティに依存するかについては、終わりのない議論のようです.

Web フォントは定期的に更新されない静的リソースであるため、自己ホスト型の優れたオプションですが、サードパーティのリソースに依存することも悪いオプションではありません。

実際、Web Almanac は、サード パーティのフォントを使用する一部のサイトは、ファースト パーティのフォントを使用するサイトよりもレンダリングが高速であることを発見しました。

サードパーティのフォント統計


ソース: HTTP アーカイブ

結局のところ、最も重要なことは、フォントのダウンロードとレンダリングがどのくらいの速さで行われるかということです。 ほとんどの場合、答えはホスティングのアプローチではなく、次の 3 つの要素が整っているかどうかによって異なります。

  • コンテンツ配信ネットワーク (CDN)
  • HTTP/2
  • Web キャッシング ポリシー

そのため、「自分の Web フォントをセルフホストするべきかどうか」などの質問に時間を浪費する代わりに、より重要な要素が設定されていることを確認してください。


4) サードパーティ リソースへの事前接続

フォントをすばやくロードできるようにするもう 1 つの手法は、 link rel=preconnectを使用することです。

リンク rel=preconnectリソース ヒントを使用して、サードパーティのオリジンとの早期接続を確立します。

link rel=preconnectを追加すると、ページが別のドメインへの接続を確立する意図があること、およびプロセスをできるだけ早く開始したいことがブラウザに通知されます。 ブラウザーがリソースを要求するまでにセットアップ プロセスが完了しているため、リソースはより迅速に読み込まれます。

リソース ヒントは、ドキュメントのheadタグに配置する必要があります。


5) フォントをサブセット化する

Web フォントがグリフの集まりであるという事実に戻ると、知っておく必要があることの 1 つは、一部のフォントには何千ものグリフが含まれる可能性があるということです。 そして真実は - あなたのサイトはそれらすべてを使用しているわけではありません.

しかし…

ブラウザはまだそれらをダウンロードする必要があるため、読み込み時間が遅くなる可能性があります!

フォントのサブセットを入力します。

フォントのサブセット化とは、サイトで使用するグリフのみにフォントをトリミングすることを意味します。 サブセット化により、サイズを大幅に節約でき、フォントの読み込みが高速になり、全体的なパフォーマンスが向上します。

これを行う 1 つの方法は、フォントを任意の文字リストでサブセット化できる fontTools を使用することです。 しかし、それをうまく効率的に行うには、Web ページで使用するすべての文字を取得するための確実なプロセスを構築する必要があります。これは、最も簡単な作業ではない可能性があります。

近日公開:数か月にわたる懸命な作業の後、独自のフォント サブセット機能をリリースする寸前です。 これにより、NitroPack ユーザーは、デザインやパフォーマンスを損なうことなく、フォントを自動的にサブセット化し、サイズを大幅に縮小できます。


NitroPack がフォントの読み込みと主要な Web Vitals を最適化する方法

Web パフォーマンスの改善は、多くの作業と頭痛の種になる可能性があります。 そのため、ツールやサービスを使用すると非常に役立ちます。

たとえば、NitroPack にはさまざまな機能が含まれており、フォントを最適化する際に多くの時間を節約できます。

  • グローバル CDN
  • GZIP と Brotli 圧縮
  • HTTP/2 互換性
  • フォントの遅延読み込み
  • 重要な CSS

また、NitroPack では、デフォルトのフォント レンダリング動作を構成できます。

手動モードのユーザーには、「詳細設定」からこの動作をオーバーライドするオプションがあります。

フォントのレンダリング動作をオーバーライドする

さらに、「詳細設定」には、CSS 配信を最適化するオプションもあります。

CSS 配信を最適化する


また、Core Web Vitals への影響を確認し、最終的に最適なソリューションを見つけるために、さまざまなフォント構成を常にテストしています。 実際、Speed Insider の助けを借りてノンストップで実験を行うこのプロセスにより、お客様に最適な CWV 結果を提供することができます。

Core Web Vitals Tech Report 2021

また、NitroPack コミュニティに参加することに決めた場合は、セットアップに 5 分もかからず、無料プラン (CC は不要) でサービスを試すことができることを知っておく必要があります。