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

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

しかし、現代のGoogle Fontsはこの問題を極めてスマートに解決しています。それが「unicode-rangeによるマルチセグメント（細分化）配信」です。

常用度に応じて、ファイルを100個以上に超細分化！

Google Fontsで日本語フォントを呼び出すと、裏側ではフォントを1つ丸ごとロードしているわけではありません。Googleは日本語のフォントデータを、常用漢字・ひらがな・カタカナ・めったに使わない難しい漢字などの「文字グループ」ごとに、100個以上の超軽量な小さなフォントファイル（woff2形式）に分解してサーバーに保管しています。

そして、ブラウザがHTMLを読み込み、「このページにはこの漢字が使われているな」と解析した瞬間、「その画面で実際に使われている文字が含まれるフォントのパーツ」だけをGoogleの爆速CDNからピンポイントでダウンロードします。

これにより、数メガバイトあるはずの日本語フォントが、実質わずか数十キロバイト（数KB〜数十KB）の読み込みだけで瞬時に文字として画面に描画されるのです！私たちは知らず知らずのうちに、この超テクノロジーの恩恵を受けています。

Webフォントを導入した際、ページを開いた瞬間に「一瞬だけOS標準の文字が表示され、直後にふわっと指定フォントに切り替わる」現象を目にしたことはありませんか？これはFOUT (Flash of Unstyled Text) と呼ばれる現象です。読者に「一瞬カクついた」ようなチープな印象を与え、GoogleのSEO指標であるCLS（レイアウトシフト）で減点されてしまう痛い要因です。

このFOUTを防ぎ、最初からWebフォントでビシッと美しく文字を表示させるための最強の対策が、HTMLの `head` 内に記述する `link rel="preload"` (プリロード設定) です。

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

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

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

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

この記述により、ブラウザは「このフォントファイルは、ページの描画プロセスで絶対にすぐ使うから、他のCSSや画像の解析を待たずに、今この瞬間最優先でダウンロードして！」と強制的に割り込みをかけます。

ダウンロードされたフォントはブラウザのメモリに事前にスタンバイされるため、ページがレンダリングされた第1フレームから、ガタつき一切なしで、美しい丸文字が完璧に表示されます！

💡 注意！：プリロードは非常に強力なため、何本も無駄なフォントを登録すると、かえってメインのHTMLやCSSのダウンロードを邪魔して表示が遅くなります。本当にファーストビューで使う「極上の1〜2本」だけを厳選してプリロードするのがプロの設計ルールです。

🚨 開発者を襲う「crossorigin」の罠：プリロードのコード末尾にある crossorigin 属性は、たとえ自サーバーの同一ドメインから配信する場合であっても絶対に省略してはいけません！ W3Cの仕様上、フォントのロードは常に「CORS匿名リクエスト」で行われると決められています。そのため、この属性を忘れると、ブラウザは「プリロードしたフォント」と「実際にCSSで使われるフォント」を別物と判定し、フォントを2回も二重ダウンロードしてしまう最悪のバグ（無駄なダブルロード）が発生します。必ず指定しましょう！

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

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

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

日本語フォントには「日常で絶対に遭遇しないような極めて難しい漢字」や「各種記号」が何千文字も含まれています。これを、第一水準漢字・ひらがな・カタカナ・記号・英数字だけの「日常で使われる必要最低限の約3,000文字」だけに削ぎ落とす作業がサブセット化です。

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

ステップ2：最新の最強圧縮フォーマット『WOFF2』へ変換する

切り落としたフォントデータを、Web向けに特別に開発された最強の圧縮フォーマットである「WOFF2 (Web Open Font Format 2.0)」形式に変換します。これは、従来のttfやotfに比べて約30%〜50%もデータ容量をギュッと圧縮する技術です。

サブセット化とWOFF2変換を組み合わせることで、元のフォントの美しさは100%保ったまま、なんと約100KB前後（驚異の約97%カット！）まで極限スリム化した「超・軽量オリジナルWebフォント」が完成します。あとは自分のサーバーのフォルダにアップロードし、CSSで `@font-face` を指定して呼び出すだけ！外部との通信が発生しないため、エックスサーバーのような高速レンタルサーバーから爆速でユーザーに届けることができます。