【独自検証】フォントのサブセット化での容量を削減効果を検証

【独自検証】フォントのサブセット化での容量を削減効果を検証

Webサイトで利用される日本語Webフォントは、英数字のフォントと比べてファイル容量が大きくなりやすく、表示速度に影響する場合があります。

そこで有効なのが、実際に使用する文字だけを残してフォントを軽量化する「サブセット化」です。

本記事では、日本語Webフォントを実際にサブセット化し、フォント容量や通信量、FCP・LCPなどの表示速度がどの程度変化するのかを独自に検証します。

さらに、文字数による削減効果の違いや、サブセット化する際の注意点についても詳しく解説します。

フォントのサブセット化が表示速度改善につながる理由

フォントファイルのダウンロード量を削減できる

Webフォントのサブセット化による大きなメリットが、フォントファイルのダウンロード量を削減できることです。

フォントファイルには、Webページで実際には使用しない文字や記号まで多数収録されている場合があります。

特に日本語フォントは、ひらがな・カタカナ・漢字など収録されている文字数が多く、ファイル容量も大きくなりやすい傾向があります。

サブセット化では、Webページで使用する文字だけを抽出し、それ以外の文字情報を削除します。

その結果、フォントファイル自体を軽量化でき、ブラウザがダウンロードするデータ量を減らせます。

通信量の削減は、特にモバイル回線や通信速度が遅い環境で、表示速度改善につながる可能性があります。

Webフォントの読み込み時間を短縮できる

Webフォントは、HTMLやCSSなどのリソースと同様に、ブラウザがサーバーからファイルをダウンロードして利用します。

そのため、フォントファイルの容量が大きいほど、取得に時間がかかる可能性があります。

サブセット化によってフォントファイルの容量を小さくすると、ブラウザがダウンロードするデータ量が減少し、フォントの取得に必要な時間を短縮できる場合があります。

特に通信速度が遅いモバイル環境や、サーバーとの通信距離が長い環境では、ファイル容量の削減効果が表示速度に反映されやすくなります。

ただし、実際の読み込み時間は通信環境やキャッシュ、CDN、フォントの読み込み方法などにも左右されるため、サブセット化だけで必ず一定の改善が得られるわけではありません。

FCP・LCPなどの表示速度に影響する可能性がある

フォントのサブセット化は、FCP（First Contentful Paint）やLCP（Largest Contentful Paint）などの表示速度にも影響する可能性があります。

Webフォントがページ内のテキスト表示に必要な場合、フォントのダウンロードが遅れることで、ユーザーがコンテンツを視認できるまでの時間に影響するケースがあります。

サブセット化によってフォントの容量を削減すれば、必要なフォントをより早く取得でき、結果としてテキストの表示が早まる可能性があります。

ただし、FCPやLCPは画像、HTML、CSS、JavaScriptなど複数のリソースによって決まるため、フォントを軽量化しただけで大幅に改善するとは限りません。

実際の効果は、DevToolsやPageSpeed Insightsなどで検証することが重要です。

【独自検証】日本語Webフォントをサブセット化すると何％軽くなる？

実際にサブセット化前とサブセット化後で読み込み状況を確認してみました。

検証動画がこちら。

検証内容を下記で詳しく解説していきます。

検証環境

項目

条件

フォント

NotoSansJP

フォーマット

WOFF2

Webサイト

https://landinghub.sakura.ne.jp/to/fontsubset/

CSS・HTML

読み込むフォントファイルをビフォーアフターで変更

ネットワーク

Fast 4G

今回比較するフォントと検証の流れ

今回は「NotoSansJP」というフォントを使用して検証を行いました。

まず「NotoSansJP-full.woff2」というサブセット化していないフォントファイルを用意します。

もう一つ「NotoSansJP-subset.woff2」というサブセット化したフォントファイルを用意します。

これらをそれぞれ読み込ませて検証を実施しました。

読み込んだ結果を、devツールで計測し、変化を比較しました。

【検証結果】フォント容量はどれだけ削減できた？

結果は下記の通りとなりました。

サブセット化前

サブセット化後

削減率

フォント容量

2.3 MB

48.1 KB

約98%

転送量

2.3 MB

57.9 KB

約97%

読み込み時間

2.86 s

581 ms

約80%

結果的にフォント容量、転送量、読み込み時間ともにかなりの削減ができました。

フォントファイルの容量比較

フォントファイルの容量も詳しくみてみましょう。

サブセット化前（上記の画像）は転送量が2.3MBで全てのページ読み込み完了が2.86sだったのに対して、サブセット化後（下記の画像）は転送量が57.9KBで全てのページ読み込み完了が581msとなりました。

ファイルのサイズ自体も2.3 MB→48.1 KBとかなりの容量削減となりました。

Waterfallでもダウンロード時間の削減を確認

コンテンツダウンロードの時間も見ての通り2.86 s→581 msとかなり削減されているのがわかります。

容量の大きなフォントファイルであればあるほど、サブセット化の効果は高いことが伺える結果となりました。

フォントが切り替わるタイミング

同じ動画ですが、左のサブセット化していないページだとページが読み込まれた後にフォントが変わっているのがわかります。

※28〜31秒あたりを見ていただけるとわかりやすいです。

これはフォントファイルが読み込まれた後にフォントが反映されているということになります。

ページは先に表示されていますが、フォントが変わることでCLSなどにも影響が出る可能性があります。

逆に右側のページ（サブセット化している）は、ページが表示されたと同時にフォントファイルも読み込まれているので、ページ表示後にフォントファイルが変更されることはありませんでした。

【重要】サブセット化で本当に表示速度は改善するのか？

フォント容量が大きいサイトほど効果が出やすい

Webフォントのサブセット化による効果は、元のフォントファイルの容量が大きいほど実感しやすくなります。

特に日本語フォントは、ひらがな・カタカナ・漢字・記号など非常に多くの文字を収録しているため、欧文フォントと比べてファイル容量が大きくなりやすい傾向があります。

不要な文字まで含んだフォントをそのまま配信すると、実際には使用しないデータまでユーザーがダウンロードすることになります。

サブセット化によって使用する文字だけを残せば、フォントファイルの容量と転送量を大幅に削減でき、読み込み時間の短縮につながる可能性があります。

今回の検証でも、フォント容量を2.3MBから57.9KBまで削減でき、約97.5％の容量削減を確認しました。

高速回線では差が小さくなる場合がある

サブセット化による速度改善効果は、ユーザーの通信環境によって変わります。

光回線や5Gなど高速な通信環境では、大容量のフォントファイルでも短時間でダウンロードできるため、サブセット化前後の表示速度の差が小さくなる場合があります。

また、サーバーの応答速度やブラウザのキャッシュ、他のリソースの読み込み状況などもページ表示時間に影響します。

そのため、フォント容量を削減したからといって、必ず同じ割合でFCPやLCPが改善するわけではありません。

一方で、通信するデータそのものは確実に減らせるため、回線速度に左右されにくい「転送量削減」という点では明確なメリットがあります。

モバイル・低速回線では差が大きくなる可能性がある

モバイル回線や通信速度が制限された環境では、フォントのサブセット化による効果がより大きくなる可能性があります。

通信速度が遅いほど、大容量のフォントをダウンロードするために必要な時間も長くなるためです。

特に日本語フォントのように数MB規模になるファイルでは、ページ表示時にフォントが大きな通信負荷となることがあります。

サブセット化によってフォントを数十KB程度まで削減できれば、ダウンロードするデータ量を大幅に抑えられます。

今回の検証でも、2.3MBから57.9KBへ削減したことで、読み込み時間は2.86秒から581msとなり、約79.7％短縮しました。

フォントがLCP要素の場合は影響が大きくなる可能性がある

ページの主要な見出しやファーストビューのテキストにWebフォントが使用され、そのテキストがLCP（Largest Contentful Paint）の対象となっている場合、フォントの読み込みが表示速度に影響する可能性があります。

フォントのダウンロードに時間がかかると、文字の描画が遅れ、LCPの完了にも影響するケースがあります。

特にファーストビューで大きな見出しをWebフォントで表示しているページでは、フォントの容量削減が重要になります。

ただし、LCPは画像やHTML、CSS、サーバー応答時間など複数の要因によって決まるため、サブセット化によって必ずLCPが同じ割合で改善するわけではありません。

実際のサイトでは、PageSpeed InsightsやChrome DevToolsのPerformanceで変化を確認することが重要です。

フォントをサブセット化する方法

方法1．Google Fontsのサブセットを利用する

Google Fontsでは、フォントによっては文字コード範囲を指定して、必要な文字だけを読み込むことができます。

自分でFontToolsなどを使ってフォントを加工する必要がないため、手軽にWebフォントの読み込み量を削減できます。

手順1．Google Fontsから使用するフォントを選択する

Google Fontsにアクセスし、利用したいフォントを検索します。日本語サイトであれば、例えば「Noto Sans JP」などを選択します。

フォントを選択したら、使用するウェイト（400、500、700など）を選び、Webサイトへの導入方法を確認します。

手順2．Google FontsのCSSコードを取得する

Google Fontsで選択したフォントの「Get embed code」から、Webサイトに埋め込むためのCSSコードを確認します。

例えば、以下のようなコードが表示されます。

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

HTMLの<head>内に記述することで、Google Fontsからフォントを読み込めます。

手順3．必要な文字範囲を指定する

Google Fontsでは、日本語フォントなどで文字コードの範囲（unicode-range）を設定したCSSが提供される場合があります。

例えば、

@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/...) format('woff2');
  unicode-range: U+3041-3096;
}

のように、unicode-rangeによって対象となる文字の範囲を指定します。

ブラウザはページ内で使用されている文字に応じて必要なフォントファイルを読み込むため、フォント全体を1つの大きなファイルとしてダウンロードするよりも、通信量を抑えられる場合があります。

手順4．ブラウザで表示を確認する

CSSを設定したら、実際のページをブラウザで表示します。

日本語の文章、見出し、数字、記号などが意図したフォントで表示されているか確認してください。

特に、指定した文字範囲に含まれていない文字がある場合、別のフォントへフォールバックする可能性があるため注意が必要です。

手順5．DevToolsで読み込み量を確認する

Chrome DevToolsを開き、Network → Fontを選択します。

ページをリロードして、Google Fontsのフォントファイルがどの程度読み込まれているか確認します。

確認するポイントは以下です。

  • Size：フォントファイルのサイズ
  • Transferred：実際に転送されたデータ量
  • Time：フォントの読み込み時間
  • Waterfall：フォントの読み込みタイミング

Google Fontsを利用する方法は、フォントファイルを自分でサブセット化するより導入が簡単なのがメリットです。

一方、自社サイトで使用する文字を細かく制御したい場合は、FontToolsなどを利用して独自にサブセット化する方法も検討するとよいでしょう。

方法2．フォントファイルを自分でサブセット化する

フォントファイルを自分でサブセット化する場合は、FontToolsなどのツールを利用して、元のフォントからWebサイトで使用する文字だけを抽出します。

Google Fontsのような外部サービスに依存せず、サイトに必要な文字だけを含んだフォントファイルを作成できるのが特徴です。

手順1．フォントファイルを用意する

まず、サブセット化したいフォントファイルを用意します。

今回のようなWebサイトであれば、Google Fontsなどから「Noto Sans JP」などのフォントをダウンロードします。

元のファイルは、

NotoSansJP-Regular.woff2

のように保存します。

サブセット化前のファイルはバックアップとして残しておきましょう。

手順2．FontToolsをインストールする

FontToolsは、フォントの編集や変換などに利用できるPython製のツールです。

Macの場合はターミナルを開き、以下のコマンドを実行します。

pip3 install fonttools brotli

インストール後、以下を実行して正常にインストールできたか確認します。

pyftsubset --help

ヘルプが表示されれば準備完了です。

手順3．使用する文字を用意する

次に、Webサイトで実際に使用する文字を用意します。

例えばchars.txtというファイルを作成し、以下のように必要な文字を記述します。

表示速度改善
フォントサブセット化
Webサイトの読み込みを高速化します。
0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz

このファイルに含まれる文字だけをフォントに残すことで、不要な文字のデータを削減できます。

手順4．FontToolsでサブセット化する

ターミナルでフォントファイルがあるフォルダへ移動し、pyftsubsetを実行します。

pyftsubset NotoSansJP-Regular.woff2 \
  --text-file=chars.txt \
  --output-file=NotoSansJP-subset.woff2 \
  --flavor=woff2

実行すると、

NotoSansJP-Regular.woff2
        ↓
    FontTools
        ↓
NotoSansJP-subset.woff2

という形で、必要な文字だけを含んだサブセット版フォントが作成されます。

手順5．ファイル容量を比較する

サブセット化前後のファイル容量を確認します。

ls -lh *.woff2

例えば、

NotoSansJP-Regular.woff2    2.3M
NotoSansJP-subset.woff2     57.9K

となっていれば、フォント容量を大幅に削減できています。

今回のように2.3MBから57.9KBまで削減できれば、約97.5％の容量削減です。

手順6．CSSでサブセット版フォントを読み込む

作成したフォントファイルをWebサイトのfontsフォルダなどに配置し、CSSの@font-faceで読み込みます。

@font-face {
  font-family: "DemoJP";
  src: url("./fonts/NotoSansJP-subset.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

これで、Webページではサブセット化したフォントが使用されます。

手順7．表示を確認する

サブセット化したフォントを適用したページをブラウザで開き、文字が正しく表示されるか確認します。

特に、サブセット化の対象に含めなかった文字がある場合は注意が必要です。フォントに存在しない文字は、ブラウザによって別のフォントへフォールバックされます。

そのため、本文・見出し・ボタン・フォームなど、実際にサイト上で使用される文字がすべて含まれているか確認しましょう。

手順8．DevToolsで効果を確認する

最後にChrome DevToolsのNetwork → Fontを開き、フォントの読み込み状況を確認します。

比較するポイントは以下です。

  • Size：フォントファイルの容量
  • Transferred：実際の転送量
  • Time：フォントの読み込み時間
  • Waterfall：読み込みにかかった時間
  • FCP・LCP：ページ全体の表示速度への影響

サブセット化前と同じ条件で測定することで、「フォント容量をどれだけ削減できたか」だけでなく、「実際の表示速度にどの程度影響したか」まで検証できます。

方法3．サブセット化ツールを利用する

サブセット化ツールを利用すると、FontToolsなどのコマンドラインツールを使わずに、Web上の画面からフォントをアップロードしてサブセット化できます。

コマンド操作に慣れていない場合でも利用しやすく、フォント容量を手軽に削減できるのがメリットです。

手順1．サブセット化ツールを選ぶ

まず、フォントのサブセット化に対応したオンラインツールを利用します。

ツールによって対応しているフォント形式や、指定できる文字、出力形式などが異なるため、利用前にライセンスや利用規約も確認しましょう。

特に商用サイトで利用する場合は、元フォントのライセンスに加えて、アップロードしたフォントをツール側がどのように扱うかも確認することが重要です。

手順2．フォントファイルをアップロードする

サブセット化したいフォントファイルをツールにアップロードします。

例えば、

NotoSansJP-Regular.woff2

などのフォントファイルを指定します。

ツールによっては、TTFやOTFなどの形式しか受け付けない場合もあるため、対応形式を確認してください。

手順3．使用する文字を指定する

次に、フォントに残したい文字を指定します。

例えば、

表示速度改善
フォントサブセット化
Webサイトの読み込みを高速化します。
0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz

など、Webサイトで実際に使用する文字を入力します。

使用しない文字を削除するほどファイル容量を小さくできますが、後から対象外の文字を使用すると別のフォントに置き換わる可能性があります。

そのため、本文だけでなく、見出し・ボタン・フォーム・ナビゲーションなどで使用する文字も確認しておきましょう。

手順4．サブセット化を実行する

文字を指定したら、ツール上の「Subset」「Generate」「Convert」などのボタンを押してサブセット化を実行します。

処理が完了すると、必要な文字だけを含んだフォントファイルが生成されます。

例えば、

NotoSansJP-Regular.woff2
        ↓
サブセット化ツール
        ↓
NotoSansJP-subset.woff2

という形になります。

手順5．ファイル容量を比較する

生成されたフォントをダウンロードし、サブセット化前のファイルと容量を比較します。

例えば、

サブセット化前：2.3MB
サブセット化後：57.9KB

となった場合、約97.5％の容量削減です。

単純にファイルサイズを比較するだけでなく、実際のWebサイトに組み込んだ後にDevToolsで転送量を確認すると、より正確な検証ができます。

手順6．Webサイトにフォントを設置する

生成したフォントファイルをWebサイトのフォント用フォルダなどに配置します。

例えば、

fonts/
├── NotoSansJP-Regular.woff2
└── NotoSansJP-subset.woff2

のように配置します。

手順7．CSSでサブセット版を指定する

@font-faceで生成したフォントを読み込みます。

@font-face {
  font-family: "DemoJP";
  src: url("./fonts/NotoSansJP-subset.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

これでWebページ上ではサブセット化したフォントが使用されます。

手順8．表示と速度を確認する

最後に、ブラウザでページを表示して文字が正しく表示されることを確認します。

その後、Chrome DevToolsのNetwork → Fontを開き、以下を確認します。

  • Size：フォントファイルの容量
  • Transferred：実際の転送量
  • Time：フォントの読み込み時間
  • Waterfall：読み込みタイミング

さらにPageSpeed InsightsやDevToolsのPerformanceで、FCP・LCPなどへの影響も確認すると、サブセット化による速度改善効果をより具体的に評価できます。

日本語フォントをサブセット化するときの注意点

必要な漢字まで削除しない

日本語フォントをサブセット化すると、使用する文字を絞り込むほどファイル容量を小さくできます。

しかし、必要な漢字まで削除してしまうと、その文字だけが意図しないフォントで表示される「フォールバック」が発生する可能性があります

特に、本文だけを対象に文字を抽出すると、見出し・ナビゲーション・ボタン・フッターなどで使用されている文字が漏れることがあります。

サブセット化を行う前に、対象ページで使用されている文字をできるだけ網羅的に収集することが重要です。

作成後は実際のページを表示し、文字化けやフォントの不統一が発生していないか確認しましょう。

ページによって使用する文字が異なる

サイト内のすべてのページで同じ文字が使われているとは限りません。

あるページでは問題なく表示できても、別のページで使用されている漢字がサブセットフォントに含まれていない可能性があります。

例えば、商品ページ、ブログ記事、会社情報ページでは使用する文章や漢字が大きく異なります。

そのため、1つのページだけを基準にフォントをサブセット化すると、他のページでフォールバックが発生するリスクがあります。

サイト全体で共通のフォントを使用する場合は、複数ページから文字を収集するか、文字コード範囲ごとにフォントを分割して配信する方法も検討しましょう。

動的コンテンツに注意する

CMSの記事、ECサイトの商品名、ユーザーが入力するテキストなど、公開後に内容が変わるページでは注意が必要です。

サブセット化した時点では使用されていなかった文字が、後から追加される可能性があるためです。

例えば、新しい商品名に含まれる漢字や、新しく公開したブログ記事の文字がフォントに存在しない場合、その部分だけ別のフォントで表示されます。

静的なLPや固定された見出し・ロゴなどはサブセット化と相性が良い一方、頻繁に文章が更新されるサイトでは、対象文字を定期的に見直す仕組みが必要になります。

例

  • ユーザー名
  • 商品名
  • CMSコンテンツ
  • コメント
  • 検索結果
  • ECの商品情報

など。

将来的に追加される文字も考慮する

サブセット化では現在使用している文字だけでなく、今後追加される可能性がある文字も考慮することが重要です。

例えば、キャンペーンページの追加、商品の入れ替え、ブログ記事の公開、UIの変更などによって、新しい文字が必要になる場合があります。

必要最低限まで文字を削減すると容量は小さくなりますが、その分、更新時にフォントを再作成する手間が増えます。

そのため、完全に最小化するのではなく、ひらがな・カタカナ・英数字・主要な記号に加え、サイトで頻繁に使用する漢字を含めるなど、容量削減と運用のしやすさのバランスを考えることが大切です。

フォントライセンスを確認する

フォントをサブセット化する前に、必ずフォントのライセンスを確認しましょう。

フォントによってはWebフォントとしての利用、改変、再配布などに条件が設定されている場合があります。

サブセット化はフォントデータを加工して新しいファイルを生成するため、ライセンス上で改変や再配布が認められているかを確認することが重要です。

また、商用サイトで使用する場合は、制作会社やツール提供元の利用条件にも注意が必要です。

例えばNoto Sans JPはSIL Open Font License 1.1で提供されていますが、使用するフォントごとに条件は異なるため、導入前に必ず公式のライセンス情報を確認しましょう。

サブセット化と一緒に行いたいWebフォント高速化

WOFF2を利用する

Webフォントを配信する際は、対応ブラウザが許す限りWOFF2形式を利用するのがおすすめです。

WOFFやTTF、OTFと比較して圧縮効率が高く、同じフォントデータでも転送量を削減できる可能性があります。

サブセット化で不要な文字を削除したうえでWOFF2に変換すれば、さらにファイルサイズを抑えやすくなります。

CSSの@font-faceではformat("woff2")を指定し、古い形式を複数読み込ませる必要がないかも確認しましょう。

ただし、元ファイルを単純に拡張子だけ変更してもWOFF2にはならないため、適切な変換ツールを使用する必要があります。

font-display: swapを設定する

font-display: swapを設定すると、Webフォントの読み込みが完了するまで代替フォントを先に表示できます。

フォントのダウンロードを待ってテキスト全体が表示されなくなる状態を避けられるため、ユーザーがコンテンツを早く確認しやすくなります。

Webフォントの読み込み完了後に指定したフォントへ切り替わります。

サブセット化によってフォント自体のダウンロード時間を短縮し、さらにfont-display: swapを設定することで、フォント読み込みによる表示遅延を抑えやすくなります。

@font-face {
  font-family: "DemoJP";
  src: url("./fonts/NotoSansJP-subset.woff2") format("woff2");
  font-display: swap;
}

必要なフォントだけpreloadする

ファーストビューで必ず使用するWebフォントは、preloadによって優先的に読み込ませることができます。

ただし、すべてのフォントをpreloadすると通信の優先順位を圧迫し、CSSや画像など重要なリソースの読み込みを妨げる可能性があります。

preloadするのは、ファーストビューで使用するフォントやウェイトに限定することが重要です。

サブセット化によって容量を削減したフォントを優先的に読み込むことで、必要な文字を早い段階で取得しやすくなります。

<link
  rel="preload"
  href="./fonts/NotoSansJP-subset.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>

使用するフォントウェイトを減らす

Webフォントは、400・500・700など複数のウェイトを読み込むほど、必要なファイル数と転送量が増加します。

例えば本文用に400、見出し用に700を使用している場合、基本的には2種類のフォントデータを読み込むことになります。

サブセット化を行っても、複数ウェイトを大量に読み込んでいれば通信量は増えてしまいます。

本当に必要なウェイトだけに絞り、デザイン上の重要度が低いウェイトは削除することが効果的です。特に400・500・600・700など近い太さをすべて使用していないか確認しましょう。

不要なWebフォントを削除する

サイトの改修を繰り返していると、現在は使用していないWebフォントがCSSやHTMLに残っていることがあります。

また、異なるページやテーマのために複数のフォントファミリーを読み込んでいるケースもあります。

Chrome DevToolsのNetworkで「Font」を確認すると、実際にどのフォントファイルが読み込まれているか確認できます。

使用されていないフォントや不要なウェイトを削除すれば、サブセット化を行わなくても転送量を削減できる場合があります。

まず不要なリソースを減らしてからサブセット化を行うと、より効率的です。

可能ならシステムフォントを利用する

デザイン上の制約がない場合は、ユーザーの端末に標準搭載されているシステムフォントを利用する方法もあります。

システムフォントであればWebフォントファイルをダウンロードする必要がないため、フォントに関する追加の通信が発生しません。

特に本文のように大量の文字を表示する部分では、システムフォントを使用し、ブランドイメージに関わるロゴや見出しだけWebフォントを利用する方法もあります。

Webフォントを完全に削除できれば最も転送量を減らせますが、デザインや表示の統一性とのバランスを考えて選択することが重要です。

body {
  font-family:
    -apple-system,
    BlinkMacSystemFont,
    "Hiragino Sans",
    "Yu Gothic",
    "Yu Gothic UI",
    sans-serif;
}

フォントのサブセット化での容量を削減効果まとめ

Webフォントのサブセット化は、フォントファイルに含まれる不要な文字を削除し、実際に使用する文字だけを配信することで通信量を削減する方法です。

特に多くの漢字や記号を収録する日本語フォントでは、容量削減効果が大きくなる可能性があります。

今回の検証では、Noto Sans JPをサブセット化した結果、フォント容量を2.3MBから57.9KBへ削減し、約97.5％の容量削減を確認しました。

また、フォントの読み込み時間も2.86秒から581msへ短縮されています。

すべてのサイトで同じ効果が得られるわけではありませんが、モバイルや低速回線、大容量のWebフォントを使用しているサイトでは、表示速度改善につながる有効な施策といえます。

記事を書いた人

LandingHub 編集部

LandingHub 編集部

LandingHub編集部です。 知見を持ったLandingHubスタッフが情報を発信しています。 表示速度に関する価値のある再現性の高いノウハウに関して、技術的な知識の少ない担当者の方でもわかりやすく解説していきます。
コラム一覧に戻る