Google Fontsを使わずにフォントをローカルでホストする方法

なぜGoogle Fontsをセルフホストするのか？

Google Fontsは、優れたタイポグラフィを簡単に実現できるようにしました。スタイルシートを追加し、いくつかのウェイトを選び、ページを公開する。それは長年、小規模チームにとって妥当な既定の選択でした。

その代償は、すべての訪問者のブラウザが、フォントCSSとフォントファイルを取得するためにサードパーティサービスへ接続することです。これには2つの影響があります。

第一に、レンダリングに外部依存関係が追加されます。フォントCSSが遅い、ブロックされている、またはユーザーの地域やネットワークで利用できない場合、ページは待機するか、フォールバックに切り替わります。

第二に、プライバシー上の問題が生じます。フォントリクエストは、ユーザーのIPアドレス、ユーザーエージェント、リファラーポリシーの文脈、タイミング情報をサードパーティに明らかにする可能性があります。Google Fontsは、Fonts APIを通じてCookieを設定しないと説明していますが、「Cookieがない」ことは「個人データがない」ことと同じではありません。GDPRの下では、IPアドレスも文脈によっては個人データになり得ます。

フォントのセルフホスティングが、すべてのWebサイトで自動的に必須になるわけではありません。また、これは法的助言ではありません。しかし、欧州向けサイト、公共部門のサイト、医療、教育、金融、または不要なサードパーティリクエストを減らそうとしているチームにとって、ローカルホスティングは通常、より整理された選択です。

適切に行えば、パフォーマンス面でも有利になることがよくあります。問題は「適切に行えば」です。6つのフォントファイルを/assets/fonts/にコピーし、すべてのページで読み込むだけでは、ホスト型サービスを使うより悪くなる場合があります。より広いパフォーマンスの文脈を知りたい場合は、以前の記事であるWebフォントが今でも多くのサイトで最も簡単なパフォーマンス改善である理由で、よくある無駄のパターンを取り上げています。

セルフホストすると何が変わるのか

Google Fontsを通常の方法で使う場合、ページは次のように動作します。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

ブラウザはまずfonts.googleapis.comからCSSをリクエストし、その後fonts.gstatic.comからフォントファイルをダウンロードします。

セルフホストする場合、ページはCSSとフォントファイルの両方を自分のドメインからリクエストするべきです。

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

これにより、サードパーティへのフォントリクエストがなくなります。同時に、ファイル形式、キャッシュヘッダー、フォールバックフォント、更新を自分で選ぶ責任も生じます。

その責任は真剣に扱う価値があります。フォントはクリティカルレンダリングパス上にあります。設定が不適切だと、不可視テキスト、レイアウトシフト、初回レンダリングの遅延を引き起こす可能性があります。

Step 1: 実際に使っているものを監査する

何かをダウンロードする前に、サイトが本当に必要としているフォントファミリー、ウェイト、スタイル、文字セットを一覧にします。

一般的なマーケティングサイトで必要になるものは、たとえば次のようなものです。

• 本文用のRegular 400
• 見出しやボタン用のSemibold 600またはbold 700
• デザインで実際にイタリックを使っている場合のみItalic 400
• サイトが複数言語をサポートしていない限り、Latin文字セットのみ

古いデザインシステムの既定値には注意してください。多くのサイトは、誰かが以前フォントピッカーで選択したという理由だけで、300、400、500、600、700、イタリック、複数のスクリプトを読み込んでいます。

ブラウザのDevToolsでNetworkパネルを開き、“font”でフィルターし、ページを再読み込みして、どのファイルがリクエストされているかを確認します。そのうえで、CSS内のfont-weightの使用状況を調べます。CSSで300を一切使っていないなら、300をホストしないでください。

後で影響を確認する場合、Lighthouseは役立ちますが、そのスコアをすべてと見なさないでください。審判ではなく診断ツールとして使います。フォント修正の優先順位を付ける際には、別ガイドの慌てずにLighthouseレポートを読む方法が役立ちます。

Step 2: 適切なフォントファイルをダウンロードする

Google Fontsはオープンソースフォントを提供しています。Google FontsのWebサイト、または該当するフォントプロジェクトのリポジトリからダウンロードできます。ライセンスは確認してください。ただし、ほとんどのGoogle FontsはSIL Open Font LicenseやApache Licenseなどのオープンライセンスで配布されています。

WebではWOFF2を優先します。モダンブラウザで広くサポートされており、通常TTFやOTFよりもかなり小さくなります。2026年時点で、公開Webサイト向けにTTFをブラウザへ直接配信することが正当化されるケースはまれです。

妥当なディレクトリ構成は次のようになります。

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

説明的なファイル名を使いましょう。6か月後、font.woff2は扱いづらくなります。inter-latin-600.woff2は地味ですが有用です。

サイトがビルドシステムを使っている場合は、元のフォントを分かりやすい場所に置き、最適化済みファイルをpublic assetsディレクトリへコピーする処理はビルドパイプラインに任せます。

Step 3: 必要に応じてフォントをサブセット化する

サブセット化とは、不要な文字を削除することです。完全なフォントには、Latin、Cyrillic、Greek、Vietnamese、記号、多数のOpenType機能が含まれる場合があります。英語のみのランディングページでLatin文字だけが必要なら、サブセットによって大幅に小さくできます。

一般的な方法は2つあります。

1. フォント提供元またはリポジトリが用意した既成のサブセットを使う。
2. fonttoolsのpyftsubsetのようなフォントツールで独自のサブセットを生成する。

多くのチームにとって、既成のLatinサブセットで十分です。カスタムサブセット化は、テキスト量が限られた単一のキャンペーンページや、必要な文字範囲が予測しやすい製品UIなど、非常に制約のあるページで有用です。

多言語サイトでは注意が必要です。グリフが不足するとフォールバックフォントが混在し、見た目が壊れて読みやすさを損なうことがあります。複数言語をサポートする場合は、1つの小さなサブセットをすべてに強制するのではなく、言語ルートごとにフォントサブセットを割り当てます。

Step 4: @font-faceルールを書く

最小限のローカル設定は次のようになります。

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

ここではいくつかの細部が重要です。

多くのコンテンツサイトではfont-display: swapを使います。これは、ブラウザにフォールバックテキストを素早く表示させ、その後Webフォントが到着したら差し替えるよう指示します。これにより、FOIT、つまり不可視テキストのフラッシュの最悪の状態を避けられます。

明示的なフォールバックスタックを設定します。カスタムフォントが失敗しても、ユーザーは読みやすいテキストを得られるべきです。フォールバックは後付けではなく、デザインの一部です。サイズ、行長、本文テキストの選択を見直す必要がある場合は、モダンWebにおける読みやすい文字組みの実践ガイドから始めるとよいでしょう。

ウェイトを正しく対応させます。CSSがfont-weight: 500を要求しているのに、400と700しか定義していない場合、ブラウザが中間ウェイトを合成することがあります。必ずしもひどい結果になるわけではありませんが、見た目に一貫性がなくなる可能性があります。

Step 5: 外部のGoogle Fonts呼び出しを削除する

ローカルのフォントCSSを追加したら、テンプレートから古いリモート呼び出しを削除します。

次のようなものを探してください。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

あわせて次も確認します。

• CMSプラットフォームのテーマ設定
• ページビルダーのタイポグラフィパネル
• サードパーティウィジェット
• タグマネージャー
• @import url('https://fonts.googleapis.com/...')のような古いCSS imports

最後のものはよくあります。フォント用のCSS @importは、発見を遅らせるため、通常パフォーマンス面で不利です。セルフホストする場合は、メインCSS、または早期に読み込まれるフォントCSSファイルでフォントを直接定義します。

プライバシー対応は、チームが明らかなテンプレートだけを修正し、スクリプト、ウィジェット、古い埋め込みを見落とすことで失敗しがちです。同じパターンは同意管理でも見られます。サードパーティとの接点をより広く減らしている場合は、2026年にCookieで何が変わったのかのガイドも併せて読むと役立ちます。

Step 6: キャッシュヘッダーを設定する

フォントファイルは静的アセットです。ファイル名がバージョン管理されている、またはコンテンツハッシュ付きであれば、積極的にキャッシュされるべきです。

本番環境で適したヘッダーは次のとおりです。

Cache-Control: public, max-age=31536000, immutable

長期間のimmutableキャッシュは、ファイルが変わったときにURLも変わる場合にのみ使ってください。例は次のとおりです。

inter-latin-400.a8f3c2.woff2

または、バージョン付きパスです。

/fonts/v2/inter-latin-400.woff2

URLを変えずに/fonts/inter-latin-400.woff2を上書きすると、一部のユーザーは古いファイルを長期間保持する可能性があります。問題にならないうちはよいですが、いずれ問題になり得ます。バージョン管理はその問題を避けます。

また、フォントは正しいMIME typeで配信します。

Content-Type: font/woff2

ほとんどのモダンなホスティングプラットフォームはこれを自動で処理しますが、確認する価値はあります。

Step 7: 重要なフォントだけをプリロードすることを検討する

プリロードは、ブラウザが重要なフォントをより早く発見するのに役立つ場合があります。

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

これは控えめに使ってください。すべてのフォントウェイトではなく、ファーストビューに表示される主要なテキストフォントをプリロードします。過剰なプリロードは、CSS、画像、JavaScriptと競合します。

同一オリジンのフォントであっても、フォントのプリロードにはcrossoriginを含めます。フォント取得はCORSモードを使うため、これを省略すると一部の構成で重複ダウンロードが発生することがあります。

迷う場合はテストしてください。チェックリストに書いてあるからという理由だけで、プリロードをむやみに真似しないでください。

Step 8: プライバシーとパフォーマンスをテストする

テストは簡単です。

DevToolsを開き、キャッシュを無効にしてページを再読み込みし、Networkパネルで次をフィルターします。

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

自分のドメインから配信されているフォントファイルが表示され、Google Fontsへのリクエストがないはずです。

次に、コールドキャッシュとウォームキャッシュの両方でテストします。初回訪問時、フォントは一度だけダウンロードされるべきです。以降の訪問では、ブラウザに応じてメモリキャッシュまたはディスクキャッシュから読み込まれるはずです。

フォントが差し替わるときのレイアウトシフトを確認します。見出しが跳ねる場合、フォールバックフォントのメトリクスがWebフォントと大きく異なっています。より近いフォールバックを選ぶか、size-adjust、ascent-override、descent-override、line-gap-overrideなどの新しいCSSフォントメトリクス上書きを使うことで、目に見えるシフトを減らせます。これらはやや高度ですが、洗練されたインターフェイスには有用です。

最後に、プライベートブラウジングやコンテンツブロッカーを有効にした状態でもページをテストします。セルフホスティングの利点の1つは、プライバシーツールによってタイポグラフィが偶然ブロックされにくいことです。

避けたいよくある間違い

多すぎるウェイトをホストする

これは最も一般的な失敗です。多くの場合、2つのウェイトで十分です。3つあればたいてい十分です。強い理由がない限り、5つはデザインシステム上のにおいです。

イタリックを忘れる

コンテンツで本当の強調を使うなら、実際のイタリックファイルを読み込みます。合成イタリックは、特に長文の編集コンテンツでは見栄えが悪くなることがあります。

古いGoogle CSSリンクを残す

これでは目的が失われます。移行後、別のコンポーネントが挿入していない限り、フォントリクエストがGoogleへ送られるべきではありません。

長期キャッシュなしでフォントを配信する

セルフホスティングは制御権を与えてくれます。それを活用してください。フォントは長いキャッシュ期間に非常に適した候補です。

法務とドキュメント作業を無視する

プライバシーポリシーで以前Google Fontsやサードパーティのフォント読み込みに言及していた場合は、移行後に更新します。データ処理インベントリを管理している場合は、それも更新します。技術的な変更とコンプライアンス記録は一致しているべきです。

<!-- tool-cta:start -->

💡 お試しください: Google Fonts からダウンロードした TTF ファイルを、Webfont Generator でセルフホスト可能な WOFF2 と CSS に変換してください。

<!-- tool-cta:end -->

シンプルな移行チェックリスト

1. 実際に使っているフォントファミリー、ウェイト、スタイル、スクリプトを一覧にする。
2. WOFF2ファイルをダウンロードし、ライセンスを確認する。
3. サイトの言語要件が限られている場合は、フォントをサブセット化する。
4. font-display: swapを指定したローカルの@font-faceルールを追加する。
5. すべてのGoogle Fontsのlink、preconnect、@import参照を削除する。
6. 長期間有効なキャッシュヘッダー付きで、自分のドメインからフォントを配信する。
7. テストで効果が確認できる場合のみ、ファーストビューで最も重要なフォントをプリロードする。
8. DevToolsで、Google Fontsへのリクエストが残っていないことを確認する。
9. 必要に応じてプライバシー文書を更新する。

フォントのセルフホスティングは華やかな作業ではありません。依存リスクを減らし、プライバシー面の体制を改善し、レンダリングをより予測しやすくする、小さなインフラ整理の一種です。通常、それにかかる1〜2時間の価値はあります。