フォントが変われば、
作品の「ぬくもり」が変わる。

Webデザインに「ぬくもり」をプラスしてくれる丸ゴシックなどの日本語Webフォント。しかし、多くの開発者は「日本語フォントは重すぎて表示が遅くなるから、使うべきではない」と思い込んでいます。確かに、英語のアルファベットが記号を含めても数百字しかないのに対し、日本語にはひらがな、カタカナに加え、数千から数万もの「漢字」が存在します。フォントファイル全体の容量は、数メガバイト（数MB）に達することもあります。これは普通のWebサイトのHTMLやJSの数十倍の重さです。

しかし、現代のGoogle Fontsは、この問題を「全部まとめて軽くした」のではなく、必要な文字だけを取りに行きやすくしています。それが「unicode-rangeによるマルチセグメント（細分化）配信」です。

常用度に応じて、ファイルを多数のスライスに分ける

Google Fontsで日本語フォントを呼び出すと、裏側ではフォントを1つ丸ごとロードしているわけではありません。Googleは日本語のフォントデータを、常用漢字・ひらがな・カタカナ・めったに使わない難しい漢字などの「文字グループ」ごとに、多数の小さなフォントファイル（woff2形式）に分解してサーバーに保管しています。2018年のGoogleの解説では、よく使う約3,000字を20スライスに分けると、フォント全体を送る場合よりバイト数を約80%減らせたとされています。

ブラウザは、CSSの @font-face に書かれた unicode-range と、そのフォントが当たっている要素で実際に使われている文字の交差を見て、交差があるスライスだけを取得します。「HTMLを読んでこの漢字がある」と独自解析しているわけではなく、適用中のフォントと使用文字、unicode-range の組み合わせです。

2026年8月17日に google/fonts のソースを確認すると、Zen Maru Gothic Regular の TTF は約3.7MB、Noto Sans JP の可変フォントは約9.1MB ありました。短いUI文言だけならスライス数個（数十KB台になることもあります）。本文に漢字が多く、太さを複数使うと、数百KB以上になることもあります。「常に数十KBで瞬時」ではありません。 Networkパネルでコールドロードを測って判断してください。

Webフォントを導入した際、ページを開いた瞬間に「一瞬だけOS標準の文字が表示され、直後にふわっと指定フォントに切り替わる」現象を目にしたことはありませんか？これはFOUT (Flash of Unstyled Text) と呼ばれる現象です。フォールバック書体から指定フォントへ、見た目が切り替わります。字幅や行の高さが違うとレイアウトが動くこともありますが、FOUTそのものはCLSではありません。CLS（Cumulative Layout Shift）は、予期しないレイアウトの移動量を測る別の指標です。

FOUTを減らす方法のひとつが、HTMLの head 内に記述する link rel="preload"（プリロード設定）です。必要なフォントをCSSの解析前に見つけやすくしますが、表示環境やCSSの設定によって効果は変わります。

ブラウザの読み込み順序に割り込みをかける

通常、ブラウザはHTMLを上から解析し、CSSを読み込み、さらにDOMツリーが完成して「どの場所にどのフォントを当てるか」が決まるまで、フォントファイルをダウンロードしません。そのため、フォントのロードが一歩遅れてカクつきが発生します。

そこで、`head` タグの非常に早い段階で以下のように記述します：

html<link rel="preload" href="./fonts/my-round-font.woff2" as="font" type="font/woff2" crossorigin>

この記述により、ブラウザはCSSの解析完了を待たずに対象フォントの取得を開始できます。

フォントの取得開始を早められるため、表示切り替えを減らせる可能性があります。ただし、回線状況やキャッシュ、font-displayの設定によってはFOUTが残るため、実測して判断します。

💡 注意：使わないフォントまでプリロードすると、HTMLやCSSなど他の重要な通信を圧迫する場合があります。ファーストビューで実際に使うフォントだけを候補にし、変更前後を計測してください。

🚨 crossoriginについて：フォントはCORSモードで取得されるため、自己ホストの場合もフォントのプリロードには crossorigin を指定します。詳しくはweb.devのWebフォント最適化解説を確認してください。

「Google Fontsは便利だけれど、サードパーティ（外部ドメイン）との通信が発生するため、ネットワーク遅延やセキュリティポリシー(CSP)の観点から自前のサーバー（Xserverなど）からフォントを配信したい！」という場面は多々あります。しかし、フォントファイルをそのまま自分のサーバーに置くと、数MBのファイルをユーザーに丸ごと配ることになり、サーバーの転送帯域が圧迫され、表示速度も最悪になってしまいます。

この問題を解決するプロの技が、「サブセット化」と「WOFF2超圧縮」の掛け算です。

ステップ1：使わない文字をハサミで切り落とす（サブセット化）

日本語フォントには多数の漢字や記号が含まれています。実際に使う文字集合へ絞り込む作業がサブセット化です。必要な文字はサイトごとに異なるため、固定の文字数だけで判断せず、固有名詞や記号の欠落も確認します。

「サブセットフォントメーカー」などの無料ツールを使うと、フォントファイルをドラッグ＆ドロップするだけで、数メガバイトのファイルを一撃で 数百キロバイト程度 まで小さく削減できます。

ステップ2：Web向けのWOFF2形式へ変換する

絞り込んだフォントデータを、Web配信用のWOFF2(Web Open Font Format 2.0)形式へ変換します。削減量は元フォント、含める字形、変換方法によって変わるため、変換後の容量と表示を確認します。

サブセット化とWOFF2変換を組み合わせると、元ファイルより配信量を抑えられる場合があります。変換後は、必要な文字が欠けていないか、太さや字形が意図どおりか、実際のページで表示速度が改善したかを確認してから公開します。

完成形の @font-face 例

サブセットした1ファイルを自己ホストする場合の最小例です。複数スライスに分けるなら、同じ font-family で unicode-range だけ変えた @font-face を並べます。

css@font-face {
  font-family: "My Round JP";
  src: url("./fonts/my-round-jp.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+3040-30FF, U+FF66-FF9F; /* ひらがな・カタカナ */
}