※本ページにはプロモーション(広告)が含まれています

【2026年最新版】Google FontsのNoto Sans JPの読み込みが遅い・FOUTで表示が崩れる対処法【完全ガイド】

日本語 Web サイトで定番のフォントといえば Google Fonts が提供する「Noto Sans JP」です。デザインが端正で可読性が高く、商用利用もしやすいため、多くのコーポレートサイトやブログで採用されています。しかしこの Noto Sans JP には、ロード時間が長く First Contentful Paint（FCP）を遅らせる、フォント未読込時に標準フォントで一瞬表示されてからガクンと切り替わる「FOUT（Flash of Unstyled Text）」が起きる、という慢性的な悩みが付きまといます。

原因は明快で、日本語フォントは英字フォントと比べて漢字・ひらがな・カタカナを含むためファイルサイズが桁違いに大きいからです。Noto Sans JP の Regular ウェイト一つで標準的に 1.5 MB、Bold まで含めると 5 MB を超える容量になります。これを毎ページの初回訪問で全部ダウンロードさせていれば、回線が細いユーザーの離脱率が跳ね上がるのは当然です。

本記事では、Noto Sans JP の読み込み速度と FOUT を改善するための実践的なテクニックを段階的に紹介します。preload 属性、font-display: swap、サブセット化、self-host、CDN 比較といった、Web パフォーマンス改善の王道を網羅しているので、PageSpeed Insights のスコア改善や Core Web Vitals 対策を進めたい方にとって即効性のある内容になっています。

この記事でわかること

• Noto Sans JP が遅い 5 つの根本原因
• preload と font-display の正しい使い分け
• サブセット化で 1.5MB を 200KB まで削減する方法
• Google Fonts と jsDelivr / unpkg の速度比較
• FOUT を完全に消すフォント切替テクニック

なぜ Noto Sans JP は遅いのか（基礎解説）

日本語フォントは収録文字数が膨大です。Noto Sans JP は JIS 第一・第二水準漢字、補助漢字、ハングル、絵文字なども含めて 17,000 字超を 1 ファイルに格納しています。Google Fonts は CSS 経由で複数のサブセット（unicode-range）に分割配信していますが、それでも漢字を含むサブセットだけで数百 KB あります。

さらに、Google Fonts のリクエストは fonts.googleapis.com から CSS を取得し、その中で fonts.gstatic.com に対してフォントファイルを別途リクエストするという 2 段階構造です。この間にブラウザは「フォントが届くまで文字を描画しない」という挙動（FOIT）か、「標準フォントで先に描画してから差し替える」挙動（FOUT）を取ります。前者はテキスト不可視時間が長くなり、後者はチラつきます。

2026 年現在、Google は HTTP/3（QUIC）配信を行っているため接続レイヤは高速化していますが、それでも 1 MB 級のフォントファイルを取りに行く事実は変わりません。改善のカギは「届いてから描画する」のではなく、「届いていない間どう振る舞うか」と「そもそも届けるサイズを減らす」の二軸で攻めることです。

原因切り分けチェック

1. Lighthouse の「Avoid enormous network payloads」で Noto Sans JP が表示されるか
2. Network タブで woff2 ファイルのサイズと時間を確認
3. Performance タブの Layout Shift にフォント切替が記録されているか
4. 初回訪問とリロード後でロード時間がどれだけ違うか

対処法1: font-display: swap を必ず指定する

Google Fonts の URL に display=swap パラメータを付けることで、フォントが読み込まれる前に標準フォントで先に描画されます。FCP が劇的に改善し、ユーザーは何かしらのテキストをすぐ目にできます。

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap" rel="stylesheet">

欠点は FOUT が発生しやすくなる点です。これは後述の preload と組み合わせて補います。

対処法2: preload で先取りロードする

HTML の head に preload を追加し、ブラウザに「この CSS / フォントを優先的に取れ」と指示します。

<link rel="preload" href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap" as="style">
<link rel="preload" href="/fonts/NotoSansJP-Regular.woff2" as="font" type="font/woff2" crossorigin>

preload は強力ですが、入れすぎると逆に他のリソースを圧迫します。本当に最初に表示される範囲（above the fold）のフォントだけに絞るのがコツです。

対処法3: サブセット化で容量を 1/7 に削減

もっとも効果が大きい対処法です。サイトで実際に使う文字だけを切り出し、200KB 程度の小さい woff2 を生成します。

fonttools（Python）を使った例:

pip install fonttools brotli
pyftsubset NotoSansJP-Regular.otf \
  --unicodes="U+0020-007E,U+3000-30FF,U+4E00-9FFF" \
  --flavor=woff2 \
  --output-file=NotoSansJP-Regular-subset.woff2

上記は ASCII、ひらがな・カタカナ、CJK 統合漢字をカバーします。一般的な日本語サイトならこれで困りません。文字数を厳密に絞るなら、サイトテキストを --text-file=site-text.txt で指定する手もあります。

対処法4: self-host する

Google Fonts のサーバー応答時間や DNS 解決時間も遅延要因です。サブセット化した woff2 を自サイトに配置し、CSS から直接参照することで、外部リクエストを完全に排除できます。

@font-face {
  font-family: 'Noto Sans JP';
  src: url('/fonts/NotoSansJP-Regular-subset.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

HTTP/2 や HTTP/3 を有効にした自前サーバーや CloudFront・Cloudflare 経由なら、Google Fonts より高速になることも多いです。

対処法5: Variable Font 版を使う

Noto Sans JP には Variable Font 版（NotoSansJP-VF.woff2）があり、複数ウェイトを 1 ファイルで賄えます。Regular と Bold を別々にロードするより、結果的に総容量を削減できる場合があります。

CDN・配信方法の比較表

FOUT を完全に消すテクニック

FOUT のチラつきが許容できない場合、CSS Font Loading API を使って「フォントが読み込み完了したらクラスを付ける」方式が有効です。

<style>
  body { visibility: hidden; }
  body.fonts-loaded { visibility: visible; }
</style>
<script>
  document.fonts.ready.then(() => {
    document.body.classList.add('fonts-loaded');
  });
</script>

ただしこれは「フォントが届くまで何も見えない」状態を作るため、回線が細いユーザーには不評になりがちです。最低限のタイムアウト（1 秒）を設けて、超えたら強制表示する設計がベターです。

FAQ よくある質問

Q1. preload を入れたら逆に Lighthouse で警告が出ました。

preload しすぎると他のクリティカルリソースを押しのけます。本当に上部に表示されるフォントだけに絞ってください。

Q2. サブセット化したら一部の漢字が豆腐（□）になります。

サブセット範囲に含まれない漢字です。記事内容によって動的に必要文字が変わるサイトでは、CJK 統合漢字を全部含めるか、Google Fonts に戻すのが安全です。

Q3. Google Fonts は本当に GDPR 違反になりますか？

2022 年のドイツ判例以降、IP アドレス送信を理由に違反とされる事例があります。EU 圏向けサイトでは self-host が推奨されています。

Q4. font-display: optional を使うのはどんなとき？

初回訪問時はフォントを使わず標準フォントで完結させ、2 回目以降のキャッシュからのみ Noto Sans JP を表示したい、というモバイル重視のサイトに向いています。

Q5. Variable Font は古いブラウザで動きますか？

主要ブラウザ（Chrome 62+、Safari 11+、Firefox 62+、Edge 17+）でサポートされています。それより古い環境ではフォールバックとして標準フォントが使われます。

Q6. self-host のフォントを CDN に乗せたいです。

Cloudflare R2、AWS CloudFront、Vercel Edge Network いずれも woff2 配信に最適です。Cache-Control を 1 年（max-age=31536000, immutable）に設定すると効果が最大化します。

まとめ

Noto Sans JP は美しい反面、Web パフォーマンスの足を引っ張る代表格です。font-display: swap で FCP を即改善し、preload で重要フォントを先取りロード、サブセット化で容量を 1/7 に削減、最終的には self-host へ移行する、という 4 ステップで多くの問題は解決します。Core Web Vitals の合格ラインに届かないサイトは、まずフォント周りから手を入れてみてください。文字が届くまでの 0.5 秒の差が、ユーザーの第一印象を大きく左右します。