Webフォントが表示されない・指定したフォントに切り替わらない ─ CORS・キャッシュ・FOITの切り分け

Webフォントが効かない症状は、見た目が崩れただけに見えて、実は配信・CORS・キャッシュのどこかが切れているサインです。放置するとブランドの統一感が崩れるだけでなく、表示直後にフォントが入れ替わるFOUT（Flash of Unstyled Text）や、文字自体が一瞬消えるFOIT（Flash of Invisible Text）でCLS（Cumulative Layout Shift）が悪化し、Core Web Vitalsのスコアまで引きずられます。

まず切り分けたいのは、フォントファイルそのものが取得できているかどうかです。ブラウザの開発者ツールでNetworkタブを開き、.woff2 や .woff へのリクエストを見ます。ステータスが200なら配信は成功しており、疑うべきはCSS側かフォールバックの指定です。404ならパスの誤りかアップロード漏れ、403なら権限かCDNの設定、そしてConsoleにCORSエラーが出ているなら、別ドメインからフォントを読み込む際の Access-Control-Allow-Origin ヘッダーが欠けています。

CORSは特に厄介です。同一サイトに見えても、フォントだけをCloudflare R2やAWS S3、別サブドメインのCDNに置いている構成だと、フォントファイルにだけクロスオリジン制限がかかります。HTMLや画像は普通に表示されるのにフォントだけ無言で失敗するため、原因に気づくまで時間を溶かしがちです。配信側に Access-Control-Allow-Origin を付ける。許可するオリジンを明示するか、公開フォントなら * を返す。これが正解です。

Google Fonts を使っているのに表示されないなら、話は変わります。中国国内からのアクセスでは fonts.googleapis.com が遮断される、あるいは広告ブロッカーやプライバシー拡張がGoogle Fontsへのリクエストを止めているケースが現実にあります。ここはセルフホスト、つまりフォントを自社サーバやCDNに置く構成への移行を勧めます。GDPRの観点でも、2022年のドイツ・ミュンヘンの裁判例以降、Google Fontsを外部から動的に読み込む実装は避ける流れが強まっています。

@font-face の書き方にも落とし穴があります。format('woff2') の指定漏れ、src の順序ミス、相対パスの基準ずれ。古いブラウザ互換を気にして .eot や .ttf を延々と並べる必要は、もうほぼありません。woff2 を主、woff を予備に置けば、実用上の対応範囲は十分にカバーできます。

font-display の指定も入れておくべきです。font-display: swap を付けると、フォント読み込み中はフォールバックフォントで即表示し、読み込み完了後に差し替わります。FOITで文字が数百ミリ秒消えるより、多少のちらつきを許容するほうが体感は良くなります。本文の主要フォントは <link rel="preload" as="font" type="font/woff2" crossorigin> で先読みしておくと、p99のレンダリング遅延がはっきり縮みます。crossorigin を書き忘れるとpreloadが二重ダウンロードになる点だけ注意してください。

最後に疑うのはキャッシュです。CSSは更新したのにブラウザやCDNが古い @font-face を掴んでいる、woff2を差し替えたのにファイル名が同じでキャッシュが切れない。ファイル名にハッシュを付けるか、CDNのパージを一度通す。これだけで直ることは少なくありません。

見た目の問題と侮らず、Networkタブのステータスコードから順に追えば、原因はたいてい30分以内に特定できます。自力での切り分けが難しい、あるいはCDNやCORSの設定に踏み込む必要が出てきた場合は、早い段階で相談してください。