レスポンシブなWebフォントの読み込み：デバイスに応じた戦略

LCPの高速化とレイアウトシフトゼロを実現するレスポンシブなフォント読み込み戦略

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05

レスポンシブなfont-displayとレスポンシブなpreload戦略

Core Web Vitalsの専門家として、日々さまざまな解決策を目にしています。その大半は意味をなしませんが、ごくまれに、特定のサイトにおいて非常にシンプルで洗練された、理にかなう戦略に出会うことがあります。

2025 Web Almanacによると、Webサイトの88%がWebフォントを使用し、ページあたり中央値で4つのフォントファイルを読み込んでいます。しかし、フォントをpreloadしているサイトはわずか12%であり、font-display: optionalを使用しているサイトはたった0.5%です。大半のサイトはフォントの読み込みを画一的な問題として扱っています。この記事ではより賢明なアプローチを解説します。デスクトップとモバイルでフォントの読み込み方を変える方法です。

この戦略は、レスポンシブなpreloadを組み合わせたものです。デスクトップではfont-display: optionalを使用してFlash Of Unstyled Textを排除します。モバイルではfont-display: swapを使用して、視覚的な一貫性よりも高速なテキストのレンダリングを優先します。

最終更新: 2026年3月 Arjen Karel

tip: この戦略は、クリティカルレンダリングパスが大きいサイト、つまりLCP要素の前に複数のフォント、スタイルシート、スクリプトを読み込むサイトで効果的です。単一の軽量なフォントを読み込むだけのサイトであれば、複雑さを増す価値はありません。

早期のフォント読み込みが抱える問題

Core Web Vitalsを最適化する際、常に適用されるシンプルなルールが1つあります。
「Largest Contentful Paintの前に行うすべての処理は、Largest Contentful Paintを遅延させる」ということです。

この原則はWebフォントにも当てはまります。ページ読み込み時にWebフォントの読み込みを優先するとUXは向上しますが、特に特定のデバイスタイプでCore Web Vitalsのしきい値を満たすのに苦労している場合は、UXとLCP改善のバランスを取る必要があります。

2025 Web Almanac Performanceの章によれば、モバイルページの約24%でテキストがLCP要素になっています。テキストがLCP要素である場合、フォントの読み込み戦略はLCPスコアに直結します。画像がLCP要素である残りの76%のページでも、フォントは初期のネットワーク帯域幅を奪い合い、画像の読み込みを遅らせる可能性があります。

オランダのニュースサイトを例に考えてみましょう。モバイルデバイスでは、LCP要素の前に3つのフォントがキューに入っています。これにより、3つのフォントが初期のネットワークリソースを奪い合い、画像のタイミングが遅れます。

responsive font loading mobile device

font-display: optionalとswapの理解

レスポンシブ戦略に踏み込む前に、そのベースとなる2つのfont-displayの値を理解する必要があります。font-displayの概要については、Webフォントの読み込み中にテキストが確実に見えるようにする方法を参照してください。

font-display: swapは、ただちにfallbackフォントを表示し、カスタムフォントが読み込まれたらそれに切り替えます。テキストが最初から表示されるため、これはLCPにとって非常に有効です。欠点は、カスタムフォントが到着してfallbackと置き換わる際、フォントメトリクスの違いによって視覚的なレイアウトシフトが発生し、CLSスコアが悪化することです。約50%のサイトがswapを使用しており、圧倒的に人気のある値です。

font-display: optionalは、ブラウザにフォントを読み込むための約100ミリ秒の猶予を与えます。フォントが間に合えば（通常はキャッシュや高速なpreloadから）、それが使用されます。間に合わない場合は、ページ読み込み全体を通してfallbackフォントが使用され、切り替えは一切発生しません。つまりレイアウトシフトはゼロになりますが、最初の訪問ではカスタムフォントが表示されない可能性があります。最もCLSに安全なオプションであるにもかかわらず、optionalを使用しているサイトはわずか0.5%です。

Chrome 83以降、font-display: optionalと<link rel="preload">を組み合わせると、フォントの到着を待つために最初のペイントが最大約100ミリ秒ブロックされます（絶対最大値は1500ミリ秒）。フォントがpreloadされていれば、ほぼ常にその時間内に到着します。結果として、最初のペイントでスタイルが適用されたテキストが表示され、FOUTはゼロ、レイアウトシフトもゼロになります。これがレスポンシブ戦略のデスクトップ側がうまく機能する理由です。

レスポンシブなフォント戦略による解決

このように初期のネットワーク競合が激しい場合、デバイスの種類で分けることが理にかなっています。通常、有線（または高速なネットワーク接続）を利用する高速なデスクトップデバイスは、より多くの初期ネットワークリソースを一度に処理できます。そのため、重要なフォントファイルをpreloadすることは完全に理にかなっています。

一方、モバイルデバイスは、通勤中など最適とは言えないネットワーク環境下で使用される可能性があります。また、モバイルデバイスはデスクトップに比べてCPUが遅く、利用可能なメモリも少ないことがよくあります。こうした制限があるため、デバイスの種類によってフォントの読み込み方を変えることは理にかなっています。

  • デスクトップ: フォントをpreloadすることで、帯域幅と処理能力に優れたデバイスでのレンダリングパフォーマンスが向上します。フォント切り替えの問題を排除するために、font-display: optionalを使用します。preloadと組み合わせることで、Chromeはフォントを待つためにレンダリングをわずかにブロックし（最大約100ミリ秒）、最初のペイントでスタイル適用済みのテキストを表示してCLSをゼロにします。
  • モバイル: ネットワーク競合を避けるため、フォントをpreloadしないでください。テキストをより速くレンダリングするために、font-display: swapを使用します。このアプローチでは、カスタムフォントをバックグラウンドで読み込みながらfallbackフォントをすぐに表示するため、性能の低いデバイスでより良い体験を提供します。

<link rel="preload">とメディアクエリを使用した実装

フォントを一律に読み込む代わりに、HTMLの<link>タグのmedia属性とCSSを使用して、デバイスの種類に基づいて異なるフォント戦略を適用できます。

完全な実装

<head>
  <!-- viewportメタタグは、media条件付きのpreloadより前に配置する必要があります -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- デスクトップのみフォントをpreloadします -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* モバイル: swapにより高速なテキストレンダリングを保証します */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* デスクトップ: optional + preload = 最初のペイントでスタイル適用済みのテキストを表示します */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

この実装に関するいくつかの重要な詳細事項です。

  1. viewportメタタグの順序: <meta name="viewport">タグは、preloadリンクよりも前に配置する必要があります。ブラウザのpreloadスキャナは、他のメタタグをパースする前にmedia属性を評価します。viewportが設定されていないと、モバイルデバイスではメディアクエリが誤ったサイズに対して評価されてしまいます。
  2. 完全な@font-face宣言: 各@font-faceブロックには、font-familyとsrcの両方を含める必要があります。通常のCSSプロパティとは異なり、@font-faceディスクリプタはカスケードしません。完全なfont-faceを再宣言せずに、2つ目のブロックでfont-displayだけを上書きすることはできません。ブラウザは不完全な@font-faceルールを破棄します。
  3. crossorigin属性: crossoriginなしでpreloadされたフォントは2回フェッチされます。同一オリジンのフォントであっても、フォントのpreloadには常にこれを含めてください。
  4. ブレークポイントの一致: preloadのmedia属性（768px）は、CSSのメディアクエリ（768px）と一致する必要があります。これらが一致しない場合、あるブレークポイントでpreloadを行い、別のブレークポイントで誤ったfont-displayを適用することになります。

fallbackフォントのマッチングによるモバイルでのレイアウトシフト削減

モバイルの戦略ではfont-display: swapを使用します。つまり、カスタムフォントがfallbackと置き換わる際に、短いFlash Of Unstyled Textが発生します。この視覚的なジャンプは、CSSのフォントメトリクスの上書きを使用することで最小限に抑えることができます。

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

ascent-override、descent-override、およびsize-adjustディスクリプタを使用すると、fallbackフォントの寸法をカスタムフォントに合わせることができます。切り替えが発生した際、テキストはほとんど動きません。これらのディスクリプタはすべてのモダンブラウザでサポートされています。Capsizeのようなライブラリを使えば、特定のフォントに対する適切な上書き値を自動的に計算できます。

このアプローチの利点

  • デスクトップのUX: デスクトップでは最初のペイント時にWebフォントでレンダリングされ、FOUTとFOITの両方を防ぎます。フォント読み込みによるレイアウトシフトはゼロです。
  • モバイルのパフォーマンス: font-display: swapにより、カスタムフォントがまだ読み込まれていなくても、ユーザーはすぐにテキストを見ることができます。preloadしないため、フォントが帯域幅をLCP画像と奪い合うこともありません。
  • 宣言的でシンプル: 純粋なHTMLとCSSのみを使用します。JavaScriptやフォント読み込みライブラリ、フレームワークの依存関係はありません。つまり、すでに導入されている任意のリソース優先順位付け戦略と一緒に機能します。

実際の効果

この戦略は、Eコマースサイトの監査中に出会った実際の事例に基づいています。そのサイトでは、見出し用フォント、本文用フォント、アイコンフォントの3つのカスタムフォントを読み込んでいました。デスクトップではすべてが十分に速く読み込まれたため、フォントが問題を引き起こすことはほとんどありませんでした。しかし、4G経由のモバイルでは3つのフォントのpreloadがヒーロー画像と競合し、LCPを2.5秒のしきい値よりもはるかに遅延させていました。

レスポンシブ戦略を実装した結果（デスクトップのみでpreloadし、モバイルでのフォントのpreloadを削除しました）：

  • デスクトップ: 最初のペイントでスタイル適用済みのフォントが表示され、CLSとUXが向上しました。preloadとfont-display: optionalの組み合わせにより、フォント関連のレイアウトシフトがすべて解消されました。
  • モバイル: フォントが初期の帯域幅を奪い合うことがなくなったため、First Contentful PaintとLargest Contentful Paintが高速化しました。ヒーロー画像は競合なしで読み込まれました。

DebugBearの調査もこの効果を裏付けています。適切に適用すれば、フォントのpreloadはLCPを約30%改善できます（1.82秒から1.24秒へ）。しかし、過剰に使用すると（あるサイトでは38個のフォントをpreloadしていました）、preloadは事態を悪化させます。レスポンシブなアプローチは、モバイルでの代償なしに、デスクトップでのpreloadの利点をもたらします。

CoreDashが監視するサイト全体において、フォントを戦略的にpreloadした場合、モバイルでのページ読み込みの約82%がLCPの基準をクリアしています。これはデバイスの種類に関係なくすべてのフォントを同じように読み込むページの70%と比較されます。preloadとoptionalの組み合わせが最も効果を発揮するデスクトップでは、この差はさらに広がります。

この戦略を使用すべき場合（および避けるべき場合）

この戦略を使用すべきケース:

  • サイトが2つ以上のカスタムフォントファイルを読み込む場合
  • モバイルとデスクトップで異なるCore Web Vitalsのパフォーマンスプロファイルを持つ場合（デスクトップは基準をクリアしているのにモバイルがLCPで苦労しているサイトでよく見られます）
  • モバイルでフォントが他の重要なリソース（ヒーロー画像、クリティカルCSS）と競合している場合
  • フォントをセルフホストしている場合（この戦略は任意のフォントホスティングで機能しますが、セルフホストならpreloadのパスを完全に制御できます）

この戦略を避けるべきケース:

  • 軽量なWOFF2フォント（20 KB未満）を1つしか読み込まない場合。レスポンシブな読み込みのオーバーヘッドに見合いません。
  • サイトがすでにモバイルとデスクトップの両方でCore Web Vitalsをすべてクリアしている場合。存在しない問題に複雑さを追加しないでください。
  • システムフォントに依存している場合。すでにfont-family: system-ui, sans-serifを使用しているなら、最適化する余地はありません。

この戦略、あるいはその他のフォント読み込み戦略を実装した後は、Real User Monitoringでその影響を監視し、変更が実際にfield dataを改善したことを確認してください。Labテストでは、この戦略を価値あるものにする実際のネットワーク環境の変動性を見逃す可能性があります。

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

大規模サイトのCore Web Vitalsを通してきました。

欧州の大手メディアやEコマース基盤で50万ページ超。修正コードを書き、フィールドデータで効果を検証します。

進め方を見る
レスポンシブなWebフォントの読み込み：デバイスに応じた戦略 Core Web Vitals レスポンシブなWebフォントの読み込み：デバイスに応じた戦略