多くの WordPress ウェブフォント 特にモバイルデバイスでは、フォントの読み込みが並行して行われ、レンダリングがブロックされるため、LCPやFCPが長引きます。この記事では、なぜフォントが多すぎると時間がかかるのか、どのようにしてFOIT/FOUTが発生するのか、そしてどのような具体的な対策がサイトを著しく高速化するのかを紹介します。.
中心点
- 削減 数カットでリクエストとデータ転送を削減
- プリロード とプリコネクトが重要なファイルを優先
- フォント表示 見えないテキストを防ぐ(FOIT)
- ローカル ホスティングは外部レイテンシーとCORSを節約する
- サブセット 使用されていないグリフを削除し、フォントを小さくする
WordPressで多くのWebフォントが読み込み時間を犠牲にする理由
フォントを追加するたびに、さらに リクエスト, DNSルックアップが増え、キロバイトが増える。レギュラー、ボールド、イタリックを含むいくつかのファミリーは、テキストがきれいに表示されるまでに500-1000キロバイトまですぐに追加されます。ブラウザは重要なフォントが利用可能な場合にのみレンダリングできるため、これはLCP(Largest Contentful Paint)に直接影響します。たった3つのフォントで、最初のレンダリングが20~50パーセントも引き伸ばされ、低速接続のユーザーに大きな打撃を与えます。そのため私は、レンダリングのブロッキングを避けるために、明確に定義されたいくつかのカットと安全なフォールバックに重点を置いています。.
WordPressでWebフォントが読み込まれる方法 - そして、どこで引っかかるのか?
ウェブフォントは外部プロバイダーやテーマオプション経由で提供されることが多い。 DNS-ルックアップとTLSハンドシェイク。FOIT(Flash of Invisible Text)では、ブラウザはフォントを待ち、それまで見えないテキストを表示する。FOUT(Flash of Unstyled Text)はより良いですが、フォールバックフォントからウェブフォントに切り替える際に、短いレイアウトジャンプが発生します。優先順位付け、プリコネクト、賢明なキャッシュがなければ、ローディング時間とTTFB感は増大する。私は、メインコンテンツが常に最初に表示され、フォントがスタッタリングすることなく後から流れ込むように統合を計画しています。.
監査とモニタリング:すべてのフォントを可視化する
最適化する前に、全体像を把握します。DevToolsのネットワークタブで„フォント“、ファイル名、転送サイズ、および イニシエーター (テーマ、プラグイン、ブロックエディター)。ウォーターフォール時間は、フォントがクリティカルパスをブロックしているかどうかを示してくれる。カバレッジ・パネルでは、大きな@font-face CSSブロックがクリティカル・パスをブロックしているかどうかがわかります。 最小限 を使用することができます。パフォーマンス・トレースにより、WOFF2ファイルの準備が整うまでテキストレンダリングがブロックされるかどうかが判明する。WordPressレベルでは、隠れたフォントソース(ページビルダー、アイコンパック)を特定するため、テスト的にプラグインを非アクティブにしています。ここで私が重視している指標は、フォントリクエスト数、総KB数、最初に読める行までの時間、FOUT/FOIT時間、フィルムストリップのLCP/FCPへの影響である。.
ラボとフィールドのデータを比較している:LAN経由の高速なデスクトップは、4Gネットワークでしか見えない問題を覆い隠してしまいます。そのため、CPUと帯域幅のスロットルを低くして、現実的なモバイル状況をシミュレートしてテストしています。チェーンがきれいになり、フォールバックが安定してレンダリングされるようになってから、さらにタイポの微調整を加えます。.
コアウェブ・バイタルへの測定可能な効果
LCP、FCP、CLSは、不用意な負荷に敏感に反応する。 フォント, なぜなら、遅延フォントはレイアウトをずらし、コンテンツを不明瞭にするからだ。HTTP Archiveによると、ウェブフォントを使用したページは平均してより多くのデータを転送しており、モバイルデバイスではより顕著です。PageSpeed Insightsのドキュメントでは、レンダーブロッキングリソースが最初の表示までのパスを長くすると明確に説明しています。優先順位付けされたリクエストは、この連鎖を短縮し、待ち時間を顕著に短縮します。優先順位付けについて詳しく知りたい場合は、以下のサイトで背景情報をご覧いただけます。 リクエストの優先順位付け, これは、私が特に広範なテーマに使っているものだ。.
技術的原因の詳細
多くの個別ファイル、結合されていないスタイル、欠落しているサブセットにより、次のような問題が発生します。 ペイロード 不要である。HTTP/2やHTTP/3がないと、リクエストはしばしばキューに入れられ、レンダリングパスをブロックします。fonts.googleapis.comのような外部ドメインはさらに待ち時間を増やし、複数のファミリーで加算されます。CORSヘッダーは必要であり、そうでなければブラウザはプリロードをキャンセルするか、使用しない。私は、ローカルでの提供、きれいに設定されたヘッダー、2~3カットへのターゲット制限によって、このようなつまずきを防いでいる。.
タイポグラフィの落とし穴を避けよう:メトリクス、フォールバック品質、偽スタイル
純粋なファイルサイズに加え、タイポの詳細も表示の安定性に影響する。フォールバックフォントとウェブフォントのメトリクスが大きく異なる場合、スワップ中に目に見えるジャンプが発生します。私は サイズアジャスト とブロック合成スタイルで「偽」の太字/斜体を防ぐ:
フォントフェイス
font-family: 'Inter';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 100 900;
font-weight: 100 900; font-style: normal;
font-display: swap;
/* CLSを減らすためにメトリクスを調整する */
size-adjust: 100%;
ascent-override:90%;
descent-override:20%;
line-gap-override: 0%;
}
/* フォールバックフォントを視覚的に調和させる */
ボディ
font-family: system-ui, -apple-system, Segoe UI, Roboto, Inter, sans-serif;
font-size-adjust: 0.5; /* x-heightをより良く調整する */
font-synthesis: none; /* 偽のボールド/イタリックを防ぐ */
} 私はイタリック体のバリエーション用に別の軸や静的ファイルを定義し、偽イタリック体を避けている。また フォントウェイト ブラウザが補間しないように、正確に(300/400/600/700)設定します。この精密な作業にはほとんど時間がかかりませんが、フォールバックフォントからウェブフォントに切り替えたときにレイアウトが著しく変化するのを防ぐことができます。.
合理化:3つの緊急対策
私は家族の数を減らし、装飾的なカットをフォールバックに置き換え、一貫して次のような使い方をする。 フォント表示スワップ。システムスタック(-apple-system、Segoe UI、Roboto、Noto Sans、Ubuntu、Cantarell)は、ウェブフォントがバックグラウンドで読み込まれる間、素早くテキストを出力する。通常、見出しはボールドカット、本文は通常のバリアントで済みます。また、リクエストを少なくするために、不要なリモートコールを削除しています。さらに効果を出したい場合は HTTPリクエストを減らす その結果、クリティカルパス全体が緩和される。.
アイコンフォントを置き換える:SVGはリクエストを保存
多くのテーマにはアイコンフォントが付属している(ソーシャルアイコンやUIアイコンなど)。1つのアイコンフォントの重さは30~80KBで、以下のようなものがあります。 フォント・フェイス レンダリングパスに影響を与えます。私はそのようなフォントを エスブイジー - をインラインまたはスプライトとして使用できます。こうすることで、リクエストを減らし、アイコンのFOIT/FOUTを回避し、すべてのディスプレイでカミソリのようにシャープな視覚化を保証する。完全な切り替えがすぐにできない場合は、アイコンのフォントを実際に使用する絵文字にサブセレクトし、次のように設定する。 font-display: オプション, これにより、ページがアイコンフォントを待つことがなくなる:
フォントフェイス
font-family: 'ThemeIcons';
src: url('/fonts/theme-icons-subset.woff2') format('woff2');
font-display: optional; /* UIは操作可能なまま、アイコンは後でポップイン */
} インラインSVGはまた、新しいファイルを読み込むことなく、CSSで色や状態をコントロールすることもできる。これは、クリティカルなレンダリングチェーンを可能な限り短く保つという目標にぴったりだ。.
プレロード、プレコネクト、プレウォームを正しく使用すること
プレコネクトは決定的な場面で使う。 ドメイン, DNS、TCP、TLSに優先順位をつける。私は本当に重要なWOFF2ファイルに対してのみプリロードを使用し、そうでない場合は二次的なリソースに優先順位を浪費します。タグは、as=“font“、type=“font/woff2″、crossoriginを設定しなければなりません。そうしないと、ブラウザはヒントを部分的に無視します。多すぎるプリロードはお互いを妨害し、より重要なコンテンツを後方に押しやります。無駄のない、テストされた一連のヒントは、最初の読みやすい行までの時間を短縮します:
ローカルでホスティングし、GDPRに準拠する
必要なフォントをダウンロードし、サブセットして、自分のフォントから直接提供しています。 サーバー. .これにより、外部のDNSルックアップを節約し、CORSの問題を軽減し、完全なキャッシュ・コントロールを実現している。ローカルなアプローチは、長いキャッシュランタイムを容易にし、一貫した可用性を保証する。法的な明確さと実用的な実装のために、私のガイドでは グーグルフォント・ローカル. .こうして私は、タイポグラフィを犠牲にすることなく、テクノロジーとデータ保護をクリーンに保っている。.
サブセットと可変フォント:小さなサイズで最大の効果
完全な言語パックをロードする代わりに、私は必要な言語パックだけを保持します。 グリフ とエキゾチックなセットを削除します。拡張子なしの欧文は、ファイルサイズを40-70パーセント節約できることが多く、これは特にモバイルデバイスで顕著です。可変フォントは、複数の静的ファイルを、ウェイトとイタリックの軸を持つ単一のリソースに置き換えます。これにより、WOFF2ファイルを1つだけプリロードする場合、リクエストが減り、優先順位が向上します。同時に、5つのセクションを個別に転送しなくても、視覚的な多様性が維持されます。.
可変フォントの実際:軸の的を絞った使用
実現にあたっては、不必要に広い軸領域を避ける。私は 重量 例えば、レギュラーとボールドのみを使用する場合は400-700になる。こうすることでレンダリングの複雑さを軽減し、視覚的な一貫性を保つことができる。レスポンシブ・タイポグラフィの場合、私はキーワードではなく数値のウェイトを体系的に使用する:
フォントフェイス
font-family: 'InterVar';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 400 700; /* 100-900の代わりに狭い範囲 */
font-style: normal;
font-display: swap;
}
h1, h2 { font-family: 'InterVar', system-ui, sans-serif; font-weight: 700; }.
p { font-family: 'InterVar', system-ui, sans-serif; font-weight: 400; }.
:root { font-optical-sizing: auto; }.
/* 適宜、軸ごとの特殊なケース:
.element { font-variation-settings: 'wght' 650; }.*/ これにより、不必要な中間段階でシステムに負担をかけることなく、可変フォントの柔軟性を維持することができる。.
どの最適化がどれだけの効果をもたらすのか?(概要)
以下の概要は、私が実際に使用しているものを示している。 貯蓄 と私が注目している点。値は経験的な範囲であり、初期状態、テーマ、編集回数に依存します。私はPageSpeed InsightsとWebPageTestの実行ですべての変更をテストし、副作用を認識します。そして、しきい値やキャッシュに的を絞った調整を行います。これにより、すべての測定がリアルタイムで行われるようになります。.
| 最適化アプローチ | 典型的な貯蓄額 | 重要なお知らせ |
|---|---|---|
| 2カットに削減 | 150-400 KB | クリーン フォールバック セット |
| フォント表示:スワップ | + 素早く読めるテキスト | FOITの代わりにFOUTを受け入れる |
| ローカル・ホスティング+ロング・キャッシング | 2~3回少ない | キャッシュ・コントロール/Eタグ |
| プリコネクト+目標予圧 | 50-200ミリ秒 | のみ クリティカル ファイル |
| サブセット(ラテンベース) | 40-70 %より小さい | 後日拡張可能 |
| 4つのファイルの代わりに可変フォント | -3 リクエスト | WOFF2のみ使用 |
プラグインを賢く使う - オーバーヘッドをなくす
OMGFは、Googleフォントをローカルに読み込み、不要なフォントを自動的にサブセットし、短縮します。 サイン アウト。Asset CleanUpは、特定のテンプレートにフォントが必要ない場合、ページごとにフォントを無効にすることができる。AutoptimiseはCSSを結合し、最小化し、重要なスタイルが最初に来るようにフォントを抽出することができる。HTTP/2の下での過剰な集約は逆効果になる可能性があるため、組み合わせは慎重にテストしている。ゴールは、最初に見えるコンテンツへの安定した短いチェーンであることに変わりはない。.
WordPressでの実践的な実装:コード例
多くのテーマやページビルダーは自動的にフォントを含む。私は重複するソースを削除し、ローカルファイルに切り替え、明確な優先順位を設定します。.
1) テーマから外部フォントを削除し、ローカルフォントを読み込む
/* 子テーマの functions.php */
add_action('wp_enqueue_scripts', function() { )
/* テーマ/ビルダーのハンドル例をカスタマイズ/検索する */
wp_dequeue_style('google-fonts');
wp_deregister_style('google-fonts');
/* 独自のローカルフォントスタイルを含める */
wp_enqueue_style('local-fonts', get_stylesheet_directory_uri() .'/assets/css/fonts.css', [], '1.0', 'all');
}, 20); 2) クリティカルなWOFF2のための目標プリロード
/* functions.php */
add_action('wp_head', function() {)
echo '';
}, 1); 3) フォントのキャッシュとCORSヘッダーの設定
# .htaccess (Apache)
に
AddType font/woff2 .woff2
</IfModule
ヘッダーセット Cache-Control "public, max-age=31536000, immutable"
ヘッダーセット Access-Control-Allow-Origin "*" # Nginx (サーバブロック)
location ~* .(woff2|woff)$ { .
add_header Cache-Control "public, max-age=31536000, immutable";
add_header Access-Control-Allow-Origin "*";
types { font/woff2 woff2; }.
} 4) サブセットとスワップを含むfonts.cssの例
フォントフェイス
font-family: 'Inter';
src: url('/fonts/InterLatin-400.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
ユニコード範囲: U+000-5FF; /* 欧文ベース */
}
フォント・フェイス {
font-family: 'Inter';
src: url('/fonts/InterLatin-700.woff2') format('woff2');
font-weight: 700;
font-style: normal;
font-display: swap;
ユニコード範囲:U+000-5FF;
} 多言語ページ:ロケールごとにサブセットを読み込む
海外のプロジェクトでは、必要なフォントだけを読み込みます。ワードプレスでは ロケール は異なるスタイルを登録する。例えば、ドイツ語/英語はスリムなラテン語のサブセットのままで、ポーランド語やトルコ語の変種は拡張されたグリフを持つ。 ばかり それが必要な場所で。.
/* functions.php */
add_action('wp_enqueue_scripts', function() {)
$locale = get_locale();
if (in_array($locale, ['de_DE','en_US','en_GB'])){
wp_enqueue_style('fonts-latin', get_stylesheet_directory_uri()'/assets/css/fonts-latin.css', [], '1.0');
} elseif (in_array($locale, ['pl_PL','tr_TR'])){
wp_enqueue_style('fonts-latin-ext', get_stylesheet_directory_uri().'/assets/css/fonts-latin-ext.css', [], '1.0');
}
}); 重要:私は、本文には常にしっかりとしたシステムフォールバックチェーンを持たせている。これにより、言語ファイルに障害が発生したり、キャッシュがコールドになったとしても、ページが読みやすい状態を保つことができます。.
乗数としてのホスティング、キャッシュ、CDN
高速NVMe SSD、HTTP/3、CDNがTTFBを短縮し、以下を実現します。 フォント グローバルに高速化。サーバーサイドのキャッシュはバックエンドのリクエストを減らし、ブラウザーのキャッシュはローカルキャッシュからフォントを数ヶ月間フェッチする。WOFF2用のBrotliはもうほとんど利用できませんが、@font-faceを使ったCSSにはまだ価値があります。また、テキストがすぐに表示されるように、重要なCSS部分を優先的にインライン化しています。こうすることで、バックエンドが修正され、配信がきれいになり、フォントファイルが小さくなり、最終的にテキストがより速く表示される、という連鎖が生まれます。.
テストとロールアウト計画:安全な本番稼動
フォントの最適化を段階的に導入し、リスクを最小限に抑える。まず、現状(リクエスト、KB、LCP/FCP/CLS)を文書化します。次に、ファミリーやカットを減らし、アイコンを置き換え、長いキャッシュを持つローカルのWOFF2ファイルに切り替えます。それからPreconnect/Preloadを追加します。各ステップの後、フィルムストリップをチェックし、FOITが減少しているか、レイアウトのジャンプがなくなっているかを確認する。そして、これ以上不具合が見られなくなったら、すべてのテンプレートに変更を適用します。.
変わった見出し(非常に大きなフォントサイズ、トラッキング)やイタリック体が多用されているページは特に重要である。ここでは、特に以下の点をテストする。 サイズアジャスト そしてメートルオーバーライドは、フォールバックジャンプをしっかりと捉える。私の目標は変わらない。できるだけ早く、最初のラインが読めるようにする。.
簡単なまとめ:読み込み時間短縮、読みやすさ向上
多すぎるフォントは貴重なコスト 秒, というのも、それらはリクエストを引き延ばし、レンダリングをブロックし、データ量を増加させるからです。私はフォントをスリムに保ち、特に優先順位をつけ、スワップ、サブセット化、ローカル・ホスティングに頼っています。これにより、確実にLCPとFCPを下げ、ビジュアルジャンプを減らします。PageSpeed Insightsによるモニタリングとテストを繰り返し、効果を確認し、過去の値を収集します。これにより、ユーザーを待たせることなくタイポグラフィを強力に保つことができる。.


