Core Web Vitalsを改善するために、Google Fontsをセルフホストしてください。
Google Fontsをセルフホストし、Core Web Vitals改善のために最適化する方法を学びましょう。
Core Web Vitalsを改善するGoogle Fontsのセルフホスト
2025 Web Almanacによると、全ウェブサイトの54%がGoogle Fontsを使用しています。これらの大半は、Googleのサーバーからフォントを読み込んでいます。これは問題です。Google Fontsへのリクエストはすべて、外部接続、render blockingなCSS、そしてpreload、キャッシュ、制御が不可能なフォントファイルを追加します。同じフォントをセルフホストすれば、これらの問題はすべて解消されます。作業は10分程度で終わります。
最終レビュー: 2026年2月 (Arjen Karel)
Core Web Vitalsについて
Core Web Vitalsは、Googleがランキングシグナルとして使用する3つの指標です。読み込みを示すLCP、インタラクティビティを示すINP、視覚的な安定性を示すCLSで構成されます。フォントのセルフホストは主にLCPとCLSを改善し、First Contentful Paint (FCP)の改善にもつながります。
Google FontsがCore Web Vitalsに与える影響
タイポグラフィやデザインを向上させる目的でページに組み込まれるGoogle Fontsは、Core Web Vitalsに大きな影響を与えます。特にLargest Contentful Paint (LCP)とCumulative Layout Shift (CLS)への影響が顕著です。
私が話す多くの人にとって、これは目新しい情報です。GoogleのCDNは世界最高であるはずです。では、なぜGoogle Fontsはページの速度に悪影響を及ぼすのでしょうか。
「共有キャッシュ」という主張は過去のものです。 Google Fontsは非常に普及しているため、訪問者は他のサイトのキャッシュを持っているはずだ、と多くの開発者が今でも信じています。これは2020年以前は事実でした。しかし、Chrome v86以降(Safariは2013年から)、ブラウザはHTTPキャッシュをトップレベルドメインごとに分割しています。つまり、訪問者が他にどのサイトを訪れていても、新規訪問者に対してはゼロからGoogle Fontsをダウンロードします。共有CDNキャッシュによるパフォーマンスの利点はもはや存在しません。
新規訪問者のブラウザのキャッシュに、スタイルシートは決して存在しません。Google Fontsの最初の問題は、fonts.google.comまたはfonts.googleapis.comでホストされる外部スタイルシートに依存している点です。このスタイルシートは、(多くの人が考えているように)異なるドメインで再利用することはできません。つまり、render blockingなスタイルシートが初回訪問者に対して高速なブラウザのキャッシュから提供されることはなく、常にページのレンダリングを遅らせます。
2つの新しいサーバーへの2つの接続が必要です。第2の問題は、CSSファイルとフォントファイルをダウンロードするために、2つの異なるサーバーに接続する必要がある点です。新しいサーバーへの最初の接続には深刻なオーバーヘッドがあり、余分な時間がかかります。自身のサーバーとのすでに確立された接続からファイルを提供すれば、この時間は節約できました。これを回避するため、Googleは自社のドメインへのpreconnectを推奨しています。これにより問題は多少緩和されますが、決して完璧ではありません。
font-display属性の制御が制限されています。Google Fontsでもfont-display属性は設定できますが、グローバルにしか定義できません。つまり、すべてのwoff2ファイルが同じfont-display設定になります。
woff2ファイルの最終的な場所が不明です。そのため、最も重要なフォントをpreloadできません。結果としてフォントファイルのダウンロード待ち行列に入るのが比較的遅くなり、スタイル未適用のテキストの表示(FOUT)による視覚的なレイアウトシフトが発生する可能性が高くなります。詳しくは、ウェブフォント読み込み中にテキストを表示し続ける方法を参照してください。
フォントファイルを制御できません。さらにサブセット化することも、長いキャッシュヘッダーを設定することも、独自のCDNから提供することも不可能です。
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>Google Fontsをセルフホストするメリット
Google Fontsのセルフホストとは、外部のGoogleサーバーに依存せず、独自のサーバーからフォントファイルを提供することです。このアプローチにはいくつかの利点があります。
フォント配信速度の向上: フォントをセルフホストすることで外部サーバーへの依存が減り、フォント配信が速くなります。結果としてテキストコンテンツのレンダリングも高速化します。この改善はLCPに良い影響を与え、最大のテキスト要素をより速く表示させます。2025 Web Almanacによると、セルフホストは増加傾向にあり、現在31.5%のデスクトップサイトがフォントを完全にセルフホストしています(2024年の28%から上昇)。
レイアウトシフトの削減: Google Fontsをセルフホストすることで、フォントの読み込みと表示方法を制御し、遅延したフォントレンダリングによるレイアウトシフトの可能性を最小限に抑えられます。これはページの全体的な視覚的安定性の向上に役立ち、CLSに良い影響を与えます。
キャッシュとpreloadの完全な制御: セルフホストする場合、すべてのフォントファイルの正確なURLを把握できます。つまり、重要なフォントをpreloadし、積極的なキャッシュヘッダー(1年以上)を設定し、ページの他の部分と同じ接続からフォントを提供できます。
GDPRコンプライアンス
2022年1月、ミュンヘン地方裁判所は、GoogleのサーバーからGoogle Fontsを読み込むことは、同意なしに訪問者のIPアドレスをGoogleに転送するため、GDPRに違反するという判決を下しました。セルフホストすれば、フォント読み込み時にデータがGoogleに送信されないため、この問題は完全に解消されます。サイトにヨーロッパからの訪問者がいる場合、これもセルフホストすべき理由の1つです。
Google Fontsセルフホストのベストプラクティス
セルフホストしたGoogle Fontsを最適化し、Core Web Vitalsのパフォーマンスを向上させるには、以下のベストプラクティスを検討してください。
WOFF2形式のみを使用する: WOFF2は最高の圧縮率(WOFFより約30%小さい)を提供し、96%以上のブラウザでサポートされています。WOFF2をサポートしていない唯一のブラウザはInternet Explorerですが、2022年6月にサポートが終了しました。WOFFのfallbackはもう必要ありません。
フォントのサブセット化: フォントファイルのサイズをさらに小さくするために、ページコンテンツに必要な文字だけを含めるフォントのサブセット化を検討してください。これによりフォントの読み込みが速くなり、Core Web Vitalsが改善されます。Google Fontsはすでにunicode-rangeによるサブセット化を行っていますが、セルフホストする場合はfonttoolsなどのツールを使用してさらに最適化できます。
戦略的なfont-display属性: font-display属性を戦略的に設定し、フォント読み込み中のテキストレンダリングを制御します。「swap」は、ウェブフォントが完全に読み込まれるまでfallbackフォントを表示することで、First Contentful Paintを高速化します。「optional」はフォントの切り替えを完全にスキップし、fallbackフォントを置き換えないことでレイアウトシフトを防ぎます。この2つを戦略的に組み合わせることで、Cumulative Layout ShiftとFirst Contentful Paintの両方を最適化できることがよくあります。2025 Web Almanacによると、現在50%のページがfont-display: swapを使用していますが、重要でないフォントにおけるCWVパフォーマンス最大化の最良の選択であるfont-display: optionalを使用しているのはわずか0.5%です。
フォントのpreload: リンクのpreloadメカニズムを使用して最も重要なフォント(最大1つか2つ)をpreloadし、可能な限り早くフォントを利用できるようにします。同一オリジンのフォントであっても、常に
crossorigin属性を含めてください。そうしないとブラウザはフォントを2回ダウンロードします。フォントをpreloadしているのはわずか12%のページであるため、これは簡単に成果を出せる方法です。
<link rel="preload" as="font" href="/fonts/inter-400.woff2" type="font/woff2" crossorigin>Google Fontsをセルフホストする方法(正しい手順)
Google Fontsのダウンロードとセルフホストには約10分かかります。使用前に必ずフォントのライセンスを確認してください。大半のGoogle FontsはSIL Open Font Licenseで提供されており、商用も含めて無料で使用できます。
最も簡単な方法はgoogle-webfonts-helperを使用することです。任意のGoogle Fontsを、即座に使えるCSSとともにWOFF2ファイルとしてダウンロードできます。しかし、何が起きているかを正確に理解するために手動で行う場合は、以下の手順に従ってください。
fonts.google.comでGoogle Fontsのウェブサイトにアクセスします。
使用するフォントを選択し、含めたいフォントウェイトを選びます。
フォントページのトップバーにある「selected families」ボタンをクリックします。そこにGoogleがホストするスタイルシートへのリンクがあります。

このスタイルシートのURLをコピーし、ブラウザで開きます。そのフォントで利用可能なすべてのfont-face宣言が表示されます。

1つのフォントしか使用していないのに、複数のwoff2ファイルがあることに気づくかもしれません。これは、unicode-rangeごとに異なるフォントファイルが存在するためです。ダウンロードすべきフォントを確認するには、Googleがホストするスタイルシートを一時的にサイトに追加します。ショートカットのCtrl-Shift-Iを使ってChrome DevToolsを開きます。ネットワークタブに移動し、Fontをクリックします。ここでページを再読み込み(Ctrl-R)すると、どのフォントがダウンロードされたかを確認できます。
このフォントファイル名と、スタイルシート内の対応するwoff2ファイルを照合します。これで、サイトに使用されるフォントファイルが特定できました。
次に、完全なフォントURLをコピーしてブラウザで開きます。これによりフォントファイルがダウンロードされます。このファイルをサイトに配置してください。
手順7で使用したウェブフォントのCSSをコピーし、自分のスタイルシートに貼り付けます。URLをGoogleのCDNから自分のサーバー(例:'/fonts/inter-400.woff2')に変更することを忘れないでください。
フォントをpreloadします(視覚的に重要なフォントの場合)。
これで、選択したGoogle Fontsのダウンロードとセルフホストが完了しました。
実践例
これは、Interフォントを使用し、preload、WOFF2形式のみの使用、戦略的なfont-display値、システムフォントのfallbackなど、すべてのベストプラクティスを適用した完全な例です。
<head>
<title>Google Fontsのセルフホスト</title>
<!-- フォントをpreload(同一オリジンのフォントでもcrossoriginは必須) -->
<link rel="preload" as="font" href="/fonts/inter-400.woff2" type="font/woff2" crossorigin>
<style>
/* WOFF2形式でセルフホストされたInterフォント */
@font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
src: url('/fonts/inter-400.woff2') format('woff2');
font-display: optional;
}
/* system-uiフォントへのfallback */
body {
font-family: 'Inter', system-ui, sans-serif;
}
</style>
</head>
<body>
<h1>私のウェブサイトへようこそ</h1>
<p>このページはsystem-uiをfallbackとしてInterを使用しています。</p>
</body>
影響を監視する
セルフホストフォントに切り替えた後は、Real User Monitoringで改善を確認してください。CoreDashのデータでは、適切なpreloadを行ってフォントをセルフホストしているサイトは、Google FontsのCDNから読み込む場合と比較してLCPの中央値が180ミリ秒改善しています。LCP、CLS、FCPを継続的に追跡し、変更が機能しているか確認してください。