.png?q=75&fm=webp)
webフォントの読み込みが遅い！高速化で表示速度パフォーマンスを向上
「xfを導入したら、サイトの表示が遅くなった…」そんな悩みを抱えていませんか？
webフォントはデザインの品質を高める一方で、読み込みが遅くなる原因にもなります。
特に日本語フォントはファイルサイズが大きく、対策なしではCore Web VitalsのLCP（最大コンテンツ描画）に悪影響を与え、SEOの評価を下げるリスクもあります。
この記事では、webフォントの読み込みを高速化する具体的な方法を、コードサンプルとあわせてわかりやすく解説します。
今日から実装できる内容ばかりなので、ぜひ最後まで読んでみてください。
webフォントの読み込みが遅いとどうなる？
Webフォントは、サイトのブランドイメージや可読性を高める重要な要素です。
しかし読み込みに時間がかかると、ページの表示速度を大幅に低下させる原因になります。
Core Web Vitalsへの直接的な影響
Googleは2021年よりCore Web VitalsをSEOの正式なランキング要因として採用しています。
その中でも「LCP」はページ内の最大コンテンツが表示されるまでの時間を示す指標で、2.5秒以内が合格ラインとされています。
Webフォントの読み込みはLCPに直接影響します。
ページの主要なコンテンツがテキストである場合、フォントファイルの取得が完了するまでテキストが表示されないため、LCPの計測が大幅に遅延します。
参考：LCP改善方法
フォント読み込みがLCPに与える遅延の流れ
フェーズ | 内容 | 遅延リスク |
|---|---|---|
HTMLの解析 | ブラウザがHTMLを読み込みCSSを検出 | ー |
CSSの取得・解析 | CSSファイルをダウンロード後にフォントURLを発見 | 中 |
フォントファイルのリクエスト | CSSを解析して初めてフォントのリクエストが発生 | 高 |
フォントのダウンロード | フォントファイルのサイズが大きいほど遅延が増大 | 高 |
テキストの描画 | フォントの適用後にLCP要素が描画される | 最大 |
フォントのリクエストはHTMLの読み込み開始から数ステップ後にようやく発生するため、ネットワークの遅延が重なるとLCPを1〜2秒以上悪化させるケースもあります。
Googleの検索ランキングではLCPが「良好・要改善・不良」の3段階で評価され、2.5秒を超えると評価が下がり検索順位に悪影響を及ぼします。
フォントの最適化はLCP改善における優先度の高い施策のひとつです。
ユーザー体験（UX）への悪影響
Webフォントの読み込み遅延は、視覚的なちらつきとして直接ユーザーに伝わります。代表的な問題がFOITとFOUTの2つです。
FOIT（Flash of Invisible Text） は、フォントの読み込みが完了するまでテキストが一切表示されない現象です。
ユーザーにはページが壊れているように見え、離脱の原因になります。
一方FOUT（Flash of Unstyled Text） は、まずシステムフォントで文字が表示され、Webフォント読み込み後に突然フォントが切り替わるちらつき現象です。
これらのUX悪化はビジネス指標にも直結します。
Googleのデータによればページ読み込みが3秒を超えると直帰率が32%増加し、5秒を超えると90%増加するとされています。
フォントの遅延によるFOIT・FOUTはユーザーの信頼感を損ない、CVRの低下にも直結する無視できない課題です。
モバイル環境での深刻度
Webフォントの読み込み遅延は、モバイル環境ではPC以上に深刻な問題になります。
モバイル回線はWi-Fiと比べて帯域が限られており、フォントファイルのダウンロードに要する時間がPC環境の数倍になるケースも珍しくありません。
特に数百KB〜数MBに及ぶフォントファイルを複数読み込む設定になっている場合、モバイルユーザーへの影響は甚大です。
さらにGoogleはモバイルファーストインデックスを採用しており、検索順位の評価はモバイル版ページのパフォーマンスをもとに行われます。
つまりモバイルでのフォント読み込みが遅いことは、SEO評価の低下に直結します。
デスクトップでは問題なく表示されていても、モバイルのLCPスコアが「不良」になっているケースは多く、モバイル環境を優先した最適化が不可欠です。
【原因別】webフォントの読み込みが遅い原因
原因①：ファイルサイズが大きすぎる
日本語フォントはひらがな・カタカナ・漢字を合わせると収録文字数が6,000字を超えるため、1ウェイトだけで数MB〜数十MBになるケースがあります。
日本語フォントをサブセット化せずそのまま読み込むと、フォント1つで数MBのデータ転送が発生します。
複数ウェイトを指定していれば、その分だけ転送量が倍増します。
ファイルサイズの削減は日本語サイトにおけるWebフォント最適化の最優先課題です。
Google Noto Sans JP ファイルサイズ比較例
フォーマット | ウェイト | ファイルサイズ目安 |
|---|---|---|
.ttf（未圧縮） | Regular (400) | 約 7〜8MB |
.woff | Regular (400) | 約 4〜5MB |
.woff2 | Regular (400) | 約 3〜4MB |
.woff2（サブセット化済） | Regular (400) | 約 100〜300KB |
原因②：複数フォント・複数ウェイトの読み込み
Webサイトのデザインを整えるために複数のフォントウェイトを指定するケースは多いですが、ウェイトが1つ増えるごとにリクエスト数とファイルサイズが増加し、表示速度の低下を招きます。
まずはページ内で本当に使用しているウェイトをCSS上で確認し、不要なウェイトの指定を削除することが重要です。
使用するウェイトを2種類以内に絞るだけで、フォント読み込みの負荷を大幅に軽減できます。
たとえばfont-weight: 400・700・900を指定した場合、ブラウザは3つのフォントファイルを個別に取得するため、リクエスト数は3倍になります。
実際のサイトでは使用していないウェイトを指定したままになっているケースも多く見られます。
原因③：レンダリングブロックが発生している
ブラウザはHTMLを解析してCSSファイルを取得し、そのCSSを解析して初めてフォントのURLを発見します。
つまりフォントのリクエストは読み込みプロセスの後半にしか発生しません。
この構造的な遅延が「クリティカルパスのブロック」です。
CSSファイルが重い・外部CSSが多い場合はさらに遅延が重なります。
preloadやpreconnectを使ってブラウザにフォントの存在を事前に伝えることで、このクリティカルパスの遅延を短縮できます。
レンダリングブロックの解消はLCP改善に直結する施策です。
原因④：font-displayが未設定
font-displayプロパティはWebフォントの読み込み中にテキストをどう表示するかを制御する設定です。
未設定のデフォルト状態ではblockとして動作し、フォントの取得が完了するまで最大3秒間テキストが非表示になります。
これがFOIT（Flash of Invisible Text）の主な原因です。
font-displayの動作比較
値 | 動作 | FOIT | FOUT | LCPへの影響 |
|---|---|---|---|---|
block（デフォルト） | 最大3秒間テキストを非表示 | 発生 | なし | 悪化 |
swap | 即座にフォールバックフォントで表示→切り替え | なし | 発生 | 改善 |
fallback | 100ms待機後にフォールバック表示→切り替え | 軽微 | 発生 | 改善 |
optional | 取得できなければフォールバックのまま | なし | なし | 最良 |
LCPの改善を優先する場合はfont-display: swapの設定が推奨です。
テキストがLCP要素である場合、swapに変更するだけでLCPスコアが大幅に改善するケースがあります。
原因⑤：preload／preconnectが設定されていない
ブラウザは通常、CSSを解析した後にフォントファイルの存在を認識します。
この「フォントの発見が遅い」問題を解決するのがpreloadとpreconnectの設定です。
preload はHTMLの<head>内に記述することで、ブラウザに「このフォントを最優先で取得してほしい」と事前に指示できます。
CSSの解析を待たずにフォントのダウンロードが開始されるため、表示までの時間を大幅に短縮できます。
preconnect は外部フォントサーバー（Google Fonts等）に対して、DNSルックアップ・TCPコネクション・TLSハンドシェイクを事前に済ませておく設定です。
フォントのリクエストが発生した際に即座に接続できるため、レイテンシを削減できます。
この2つの設定がないだけで、フォントの表示開始が数百ms単位で遅延するケースがあります。
<!-- preconnect：外部フォントサーバーへの事前接続 -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- preload：特定フォントファイルの最優先取得 -->
<link rel="preload"
href="/fonts/NotoSansJP-Regular.woff2"
as="font"
type="font/woff2"
crossorigin>参考：プリロードとは
原因⑥：外部CDN（Google Fonts等）への依存による遅延
Google FontsなどのサードパーティCDNからWebフォントを読み込む場合、フォントファイルの取得前にDNSルックアップ・TCPコネクション確立・TLSハンドシェイクという3つのネットワーク処理が発生します。
これだけで100〜300msのレイテンシが追加される場合があり、低速回線や海外からのアクセスではさらに遅延が拡大します。
Google Fontsは手軽に利用できる反面、外部サーバーへの依存が表示速度のボトルネックになりえます。
preconnectの設定で接続を事前確立する方法のほか、フォントファイルを自サイトのサーバーやCDNにセルフホスティングすることで、外部接続のオーバーヘッドを完全に排除できます。
LCPに直結するフォントを外部CDNから読み込んでいる場合は、セルフホスティングへの切り替えを検討しましょう。
原因⑦：フォーマットが古い
フォントファイルのフォーマットは世代によって圧縮率が大きく異なります。
古いフォーマット（.ttf・.otf・.eot）は圧縮が弱く、ファイルサイズが肥大化します。
一方、現在の標準フォーマットであるWOFF2はBrotli圧縮を採用しており、.ttfと比較してファイルサイズを30〜50%削減できます。
フォントフォーマット比較表
フォーマット | 圧縮方式 | 相対ファイルサイズ | ブラウザ対応 | 推奨 |
|---|---|---|---|---|
.eot | 独自 | 大 | IE のみ | 非推奨 |
.ttf / .otf | 非圧縮 | 大 | 主要ブラウザ対応 | 非推奨 |
.woff | zlib圧縮 | 中 | 主要ブラウザ対応 | 許容 |
.woff2 | Brotli圧縮 | 小（30〜50%削減） | 現代ブラウザほぼ100% | 推奨 |
現代のブラウザはほぼすべてWOFF2に対応しているため、WOFF2のみを提供する構成で問題ありません。
既存サイトで.ttfや.otfのまま配信している場合は、WOFF2への変換を優先的に実施してください。
webフォントの読み込みを高速化する方法
解決策① font-display: swap を設定する
最も手軽で効果が高い方法が、font-display: swap の設定です。
デフォルト状態ではフォントの読み込みが完了するまで最大3秒間テキストが非表示になる「FOIT」が発生します。
swap を指定することで、読み込み中はシステムフォントで即座に表示し、完了後に切り替わるため、ユーザーが白紙画面を見ることがなくなります。
Google Fontsの場合はURLに &display=swap を追加するだけで設定できます。
@font-face {
font-family: 'Noto Sans JP';
src: url('font.woff2') format('woff2');
font-display: swap; /* ← これを追加するだけ */
}解決策② rel="preload" でフォントを先読みする
ブラウザは通常、CSSを解析して初めてフォントの存在に気づくため、読み込み開始が遅れます。
rel="preload" をHTMLの <head> に記述することで、ブラウザにフォントを最優先で取得するよう指示でき、表示の遅延を大幅に短縮できます。
外部サービスを利用している場合は、合わせて preconnect も設定しておくと、DNSルックアップや接続確立の時間も節約できます。
<link rel="preload" href="/fonts/NotoSansJP.woff2"
as="font" type="font/woff2" crossorigin>解決策③ フォントをWOFF2形式に変換する
フォントのファイル形式を見直すだけで、大幅な軽量化が可能です。
古い .ttf や .otf と比べ、WOFF2はBrotli圧縮を採用しており、ファイルサイズを30〜50%削減できます。
現代のブラウザはほぼ100%WOFF2に対応しているため、WOFF2のみを指定しても問題ありません。
変換には無料の pyftsubset（コマンドライン）やオンラインツールの「Convertio」などが利用できます。
まずは手持ちのフォントファイルの形式を確認してみましょう。
解決策④ フォントをサブセット化する（静的・動的）
日本語フォントが重い最大の原因は、使わない文字のデータまで読み込んでいることです。
サブセット化とは、実際に使う文字だけを抽出してフォントファイルを軽量化する手法です。
静的サブセット化はツールで事前にファイルを削減する方法、動的サブセット化はGoogle Fontsの text= パラメータを使ってオンデマンドに必要文字だけを取得する方法です。
数MBあったフォントが数十KBまで圧縮された事例もあります。
<!-- 動的サブセット：使う文字のみ指定 -->
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP
&text=使用する文字列&display=swap" rel="stylesheet">解決策⑤ 使用フォント数・ウェイトを絞る
シンプルですが見落とされがちな対策です。フォントファミリーを複数使ったり、font-weight を400・700・900とまとめて指定したりすると、その分だけリクエスト数とファイルサイズが増加します。
フォントは1〜2種類・ウェイトは2種類以内を目安に絞り込みましょう。
また、可変フォント（Variable Fonts） を活用すれば、1ファイルで複数のウェイトをカバーできるため、リクエスト数を大幅に削減できます。
まずはデザイン上本当に必要かどうかを見直すことが第一歩です。
解決策⑥ フォントをセルフホスティングする
Google Fontsなどの外部サービスを利用する場合、DNSルックアップ・TCPコネクション確立・TLSハンドシェイクといった通信オーバーヘッドが発生し、100〜300msの追加遅延が生じることがあります。
フォントファイルを自サーバーやCDN（Cloudflareなど）から配信する「セルフホスティング」にすることで、この外部依存をなくせます。
ただし、Google Fontsのライセンス（OFL）を確認した上で実施してください。
WordPressユーザーは「OMGF」プラグインで手軽に対応できます。
解決策⑦ content-visibility で遅延ロードを活用する（上級）
ファーストビューに表示されない要素のフォントまで最初から読み込むのは無駄です。
CSS の content-visibility: auto を設定すると、要素がビューポートに近づくまでレンダリングとフォントのダウンロードを遅延させられます。
初回表示に必要なリソースが絞られるため、LCPの改善に効果的です。
ただし、設定した要素の高さが崩れる場合があるため、contain-intrinsic-size で予め高さを指定しておくことを推奨します。
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: 0 500px; /* 高さの目安を指定 */
}【よくある質問（FAQ）】
Q1. webフォントをやめてシステムフォントにした方がいい？
パフォーマンス最優先なら有効。ただしデザイン一貫性とのトレードオフを解説
Q2. Google Fontsは無料で使えるのに何が問題？
外部依存・GDPRリスク・CDN遅延を解説
Q3. font-display: swap にするとCLSが悪化すると聞いたが？
フォールバックフォントのサイズ調整（size-adjustプロパティ）で解決可能
Q4. 日本語フォントはサブセット化が難しい？
ダイナミックサブセッティング対応サービスの活用を推奨
Q5. Webフォントを使わずにSEO上問題ない？
SEO直接影響なし。速度改善の観点ではむしろシステムフォント有利な場合も
Q6. 可変フォント（Variable Fonts）は効果的？
ウェイト違いを1ファイルで賄えるため効果的。ただし日本語対応フォントは限定的
webフォントの読み込みの高速化まとめ
webフォントの読み込み高速化は、たった一行のCSSを追加するだけで改善できるものも多く、今日から着手できる対策ばかりです。
まずは優先度の高い font-display: swapの設定 と preloadの追加 から始め、余裕があれば サブセット化・WOFF2変換・セルフホスティング へと段階的に取り組みましょう。
これらを実践することで、Core Web VitalsのLCPが改善され、SEO評価の向上・離脱率の低下・CVRアップといった効果が期待できます。
サイトのパフォーマンスは、ユーザー体験に直結します。まず一つ、今日から実装してみてください。
記事を書いた人
井上寛生
LandingHub 執行役員 / 事業責任者 / 技術責任者