AI導入・自動化

日本語Webフォントはなぜ重いのか — 19MBを実測して分かった美しさとの付き合い方

公開日: 2026-07-16約5分で読めます著者: 因幡匠瞬

僕のサイトの転送量を計測したら、約19.7MBありました。内訳を集計して驚いたのは、その大半が画像でもJavaScriptでもなく、フォントだけで19MBだったことです。

英語圏のサイト最適化の記事では、フォントはほぼ話題になりません。日本語サイト特有の問題だからです。この記事では、なぜ日本語Webフォントはここまで重いのか、実測データでどう軽くしたか、そしてどこからは軽くしないと決めたかまで書きます。

**この記事の結論：**日本語フォントは漢字数千文字×ウェイト数で、1ウェイトあたり数MBになります。最初にやるべきは未使用ウェイトの削除（実測：19MB→11.3MB・見た目の変化ゼロ）で、そこから先は美しさとのトレードオフとして判断します。

この記事で分かること：

1. なぜ重いのか — 文字数の桁が違う

英語のフォントに必要な文字は、アルファベット大小・数字・記号で100文字前後です。一方、日本語はひらがな・カタカナに加えて漢字が数千文字。JIS第1・第2水準まで含めると6,000文字を超えます。

さらにフォントには「ウェイト（太さ）」があります。細字・標準・太字…と1ウェイトごとに全文字分のデータを持つため、1ウェイトあたり数MBになります。

僕のサイトは明朝体とゴシック体の2書体を使っていて、合計9ウェイトを読み込んでいました。数MBが9個——それがフォント19MBの正体です。

日本語Webフォントが重い構造的な理由です。

重要なのは、読み込んでいるウェイトと、実際に使っているウェイトは別だということです。コードベース全体を調査した結果：

太字用の700や800は、どのページの見出しにも本文にも一度も使われていないのに、全ページで読み込まれていました。つまり削っても見た目は1ピクセルも変わりません。

削除の結果：

	Before	After
フォント総量	19MB（9ウェイト）	11.3MB（5ウェイト）
見た目の変化	—	ゼロ

これは日本語サイトの軽量化で、最も割が良い一手です。画像圧縮のように品質の議論すら必要なく、純粋に無駄だけを削れます。

未使用分を削った後に残る11.3MBは、「実際に使っている」フォントです。ここから先の軽量化には、何かを諦める判断が入ります。主な選択肢は：

僕のサイトは、明朝体の見た目がブランドの一部です。計測ツール（Lighthouse）のスコアを上げるためにここを削るのは、手段のために目的を壊すことになる——そう判断して、残りの11MBは受け入れました。

受け入れる判断を支えたのは、計測の仕組みの理解です。

Lighthouseの数値は、実際より遥かに遅い回線をシミュレーションした極端条件のテストです。ラボの数字としては正直に悪く出ますが、実際のユーザーの4G/5G/光回線では問題ない速度で表示されています。

そこで、以降の評価は**Google Search Consoleに蓄積される実ユーザーの速度データ（Core Web Vitals）**で行う方針にしました。ラボの数字で一喜一憂せず、実際の訪問者の体験で判断する。Googleの評価も最終的には実ユーザーデータが基準です。

見た目を変えずに削り、残りは受け入れると判断した流れです。

システムフォント（端末に最初から入っているフォント）なら転送量ゼロです。こだわりの書体を使わないサイトなら、それが最速の選択です。Webフォントを使う場合も、必要な文字だけを含む「サブセット版」を提供しているサービスがあります。

Chromeの開発者ツール（F12）→ Networkタブ → 「Font」で絞り込んでページを再読み込みすると、読み込まれているフォントファイルとサイズが一覧できます。合計が数MBを超えていたら、未使用ウェイトが混ざっていないか確認する価値があります。

太字を使っている箇所のウェイトは残す必要があります。ポイントは「デザインで使っている太さを特定して、それ以外を削る」ことです。CSSのfont-weight指定をコード全体で検索すると、実際に使われている太さが分かります。

この計測に至った経緯は表示速度改善の実録に、構造化データ側の土台整備はJSON-LD実装の実録にまとめています。サイト診断のご相談はお問い合わせからどうぞ。

因幡匠瞬（しょうま）

株式会社U.ai代表。AIと仕組みで事業を回した実録を、このブログにそのまま書いています。

切り抜き・AI導入の相談

記事の内容についての質問や、切り抜き運用・AI導入の相談は、お問い合わせからどうぞ。