【実践ガイド】Webフォント（Google Fonts）の正しい使い方｜表示速度を落とさない導入テクニック

「おしゃれなフォントにしたらサイトが重くなった」問題

ホームページのデザインをワンランク上げたくて、Google Fontsで「Noto Sans JP」を導入した。見た目は良くなったけれど、PageSpeed Insightsのスコアが一気に20点も下がった——。

Google Fontsの日本語フォント（Noto Sans JP等）は、1ウェイト（太さ）あたり約1.5〜4MBのデータ量があります。Regular（400）とBold（700）の2ウェイトを読み込むだけで、最大8MBもの追加データがページに載ることになります。

結論から言うと、Google Fontsの日本語フォントは「正しく使えば」表示速度への影響を最小限に抑えられます。しかし、「普通に使う」だけだとページの表示が明らかに遅くなります。この記事では、パフォーマンスを落とさずにWebフォントを導入する実践的なテクニックを解説します。

Webフォントが表示速度に与える影響

FOIT（Flash of Invisible Text）とFOUT（Flash of Unstyled Text）

Webフォントの読み込み中に発生する2つの問題を理解しましょう。

FOIT（見えないテキストの閃光）: フォントが読み込まれるまで、テキストが一切表示されない現象。ユーザーは白い画面を見つめることになり、体感的には「サイトが壊れている」と感じます。
FOUT（スタイルなしテキストの閃光）: フォントが読み込まれるまで、ブラウザの標準フォント（メイリオ等）で表示され、読み込み完了後にWebフォントに切り替わる現象。テキストがチラッと変化するため、わずかに違和感があります。

どちらが良いのか？

UX（ユーザー体験）の観点では、FOUTの方がはるかに良いです。テキストが見えない状態が続くFOITは、ユーザーの離脱につながります。FOUTなら、少なくともテキストは最初から読めるため、ユーザーはすぐにコンテンツを消費できます。

Google Fontsの正しい読み込み方法（2026年版）

方法①：最適化されたlink要素での読み込み（推奨）

Google Fontsから取得するHTMLコードをそのまま使うのではなく、以下の最適化を加えます。

ポイント解説:

• preconnect でDNS解決を先行させ、フォントファイルのダウンロード開始を早める
• wght@400;700 で必要な太さだけを指定（全ウェイト読み込みは絶対NG）
• display=swap でFOITを防止

方法②：@font-face でのセルフホスティング（上級者向け）

Google Fontsのサーバーに依存せず、自社サーバーからフォントファイルを配信する方法です。CDNの応答速度に左右されないため、より安定したパフォーマンスが得られます。

@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
  unicode-range: U+3000-9FFF, U+FF00-FFEF; /* 日本語の文字範囲 */
}

やってはいけないNG例

日本語フォントのサブセット化

なぜサブセット化が重要なのか

日本語フォントファイルが大きい（数MB）のは、JIS第一水準〜第二水準の約6,000字＋記号を含んでいるためです。しかし、実際のWebページで使用する文字は、そのうちの一部に過ぎません。

サブセット化とは、実際に使用する文字だけを含むフォントファイルを作成し、データ量を大幅に削減する手法です。

Google Fonts APIのサブセット機能

Google Fonts APIは、2020年以降、日本語フォントを自動的にサブセット（分割）配信する仕組みを導入しています。ブラウザがリクエストした文字だけを含む小さなフォントファイルを動的に生成して返すため、以前と比べてデータ量は大幅に減少しています。

つまり、2026年現在、Google Fonts APIをで正しく読み込んでいれば、手動のサブセット化は不要です。

セルフホスティング時のサブセット化

自社サーバーからフォントを配信する場合は、手動でサブセット化が必要です。glyphhangerやpyftsubsetなどのツールを使い、JIS第一水準のみを含むフォントファイルを生成します。

Core Web Vitalsへの影響と対策

LCP（Largest Contentful Paint）への影響

Webフォントの読み込み遅延は、LCPスコアに直接影響します。特に、フォントがLCP要素（最大のテキストブロック等）に使われている場合、フォントの読み込み完了までLCPの計測が完了しません。

対策:

• font-display: swap を必ず指定する
• preconnect でDNS解決を先行させる
• 重要なフォントファイルに を使う

CLS（Cumulative Layout Shift）への影響

Webフォントとフォールバックフォント（メイリオ等）の文字サイズが異なる場合、フォント切り替え時にレイアウトが微妙にズレる（シフトする）ことがあります。

対策:

@font-face {
  font-family: 'Noto Sans JP';
  font-display: swap;
  /* ascent-overrideとdescent-overrideで */
  /* フォールバックフォントとの高さの差を調整 */
  ascent-override: 100%;
  descent-override: 25%;
  src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
}

おすすめフォント構成パターン

パターン①：安定重視（初心者向け）

body {
  font-family: 'Noto Sans JP', 'Hiragino Kaku Gothic ProN', 'メイリオ', sans-serif;
}

最も無難な構成。Google FontsのNoto Sans JPをメインに、読み込み完了まではOS標準フォントで表示。

パターン②：速度重視（パフォーマンス特化）

body {
  font-family: 'Hiragino Kaku Gothic ProN', 'メイリオ', 'Helvetica Neue', sans-serif;
}

Webフォントを一切使わず、OS標準フォントのみで構成。表示速度は最速ですが、OSによって見た目が変わります。

パターン③：デザイン重視（ブランディング特化）

body {
  font-family: 'Noto Sans JP', sans-serif;
  font-feature-settings: 'palt';
}
h1, h2, h3 {
  font-family: 'Zen Kaku Gothic New', sans-serif;
  font-weight: 700;
}

本文と見出しで異なるフォントを使い分け、デザイン性を高める構成。ただし、フォントの読み込み量が増えるため表示速度とのトレードオフ。

まとめ：Webフォントは「正しく使う」だけで速度劣化は防げる

Webフォント導入で表示速度が遅くなるのは、フォントが悪いのではなく「読み込み方が悪い」のが原因です。

今日からのアクション：

1. 今日：自社サイトのフォント読み込み方法を確認する（DevToolsのNetworkタブ）
2. 今週：@importを使っていたらに変更、display=swapを追加
3. 今月：PageSpeed Insightsで「フォントの表示中にテキストが見える状態を確保」の項目を確認

この記事を書いた人：進藤 優介｜株式会社Acqua 代表取締役 飲食業界18年の実務経験を経て、Web制作・デジタルマーケティングの世界へ転身。2020年にAcquaを設立し、AI×Webの力で中小企業のビジネスを加速させることをミッションに、HP制作・LP制作からAI導入支援まで代表自らが伴走しています。