Googleフォントは便利ですが、日本語フォントは特に重くなりがちです。
理由は後述しますが、Googleフォントはできればサイト側で読み込まない方が良いです。
WordPressでGoogleフォントが読み込まれていて表示速度が低下している、という場合にどうすれば改善できるかを解説します。
記事を書いた人は信じられる？
最初に簡単に自己紹介をさせてください。
私は独学でサイト表示速度の改善方法を学びました。
高速化作業はPageSpeed Insightsの分析結果で図ることができ、施策効果が目に見えるもので、体感的に改善を感じることもできます。
当時はAIも今ほど普及していなかったので試行錯誤でスキルを身に付けました。
そのスキルを活かして、2019年ころからサイト高速化業務に携わってきましたが、2026年現在、1,000サイトは軽く超えた作業実績があります。
自己申告なので証拠はと言われるとなかなか示しづらいところはありますが、ココナラでのWordPress高速化作業実績がNo.1なのは確固たる証拠と言えると思います。
もちろんココナラ以外にランサーズでも作業実績があり、このサイトから直接依頼されるケースも多いです。
同業者さんから難しい改善を依頼されることも多々あります。
ネット検索でのWordPressの表示速度改善方法やAIの提案はまだまだあまく、効果がないものまで紹介、提案されることすらあります。
WordPressの表示速度改善方法を紹介している記事を、PageSpeed Insightsで分析したことはありますか？
立派なことを書いているのに残念なスコアになっていたりしませんか？
もちろん、運営するこのサイトのPageSpeed Insightsのスコアはほぼ100点です。
私は日本一サイト高速化をしてきているプロ、それも証明できる実績のあるプロだと自己評価しています。
1,000サイト以上を改善してきた本当のプロが、実践で結果を出せる本当の改善方法をご紹介します。
▽coconalaでの評価
https://coconala.com/users/2093261/reviews
Googleフォントを読み込まないという選択肢
できれば重いGoogleフォントは使わないのが一番です。
どうしても使いたい場合は2パターンあります。
- ファーストビューで使われている箇所は画像化し、Googleフォントは遅延読み込みする
- CDNのtextパラメータでサブセット化する
です。
画像化って・・・、正直なところデザイナーさん、コーダーさん泣かせな施策ではありますが、Googleフォントがパフォーマンススコアに与える影響は大きいです。
Googleフォントのサブセット化
ここは色々なことが書かれている記事がありますが、GoogleフォントをCDNではなく自サーバーから読み込んだとてパフォーマンススコアは基本的には改善されません。
読み込むファイルサイズはほとんど変わらないからです。
本当に効果的なのはサブセット化です。
便利なことに、GoogleフォントのCDNではtextパラメータでサブセット化して読み込むことができます。
サブセット化とは、「実際に使用する文字だけを配信する仕組み」です。
例えばこういうシーンで使います。
ファーストビューで「明るい街づくりを目指しています」というコピーに、GoogleフォントのNoto Serif JPが太さ800で使われていた場合。
https://googleapis.com/css2?family=Noto+Serif+JP:wght@700&text=明るい街づくりを目指してますこうです。
こうすることで、「明るい街づくりを目指しています」その文字だけをダウンロードさせることができ、フォントサイズを大幅に削減できます。
オフスクリーンで使用されているNoto Serif JPについてはJavaScriptでCDN本体を動的に遅延読み込みするのがおすすめです。
Noto Sans JPを使おう
Noto Sans JPはGoogleフォントをサイト側で読み込まなくても使えるのをご存知ですか？
厳密には対応してないブラウザもまだあったり、全ての太さがカバーされているわけではないので、細かく装飾したい場合は無理ですが、単純にGoogleフォントを使いたい、という場合はNoto Sans JPが表示速度に影響なく使えます。
最近のブラウザではNoto Sans JPが読み込まれていることが多いので、サイト側でCDNやフォントファイルを読み込まなくても、cssでfont-familyにNoto Sans JPを指定すると反映されるんです。
太さはブラウザによって異なりますが一般的な太字はカバーされています。
font-weightが300とか600とか微妙なところになるとサイト側で読み込まないよ反映されないかも知れません。
サイトでNoto Sans JPを使用している、かつNoto Sans JPのCDNをサイトで読み込んでいる、という場合はそのCDN読み込みを削除するだけで意外と簡単に改善が期待できます。
Noto Sans JP以外はどうなのかというと、現状はブラウザ側ではカバーされていないようです。
明朝のNoto Serif JPもダメなので、明朝系にしたい場合は汎用フォントで妥協すると表示速度改善が期待できます。
display=swapは効果ある？
実はパフォーマンススコアの改善にはdisplay=swapはほとんど効果がありません。
display=swapがあると、ウェブフォントの読み込み待ち中も文字を先に表示できることができるため、FCPに効くとかLCPに効くとか、そう解説する記事やAI提案があります。
しかし、私の経験では、おまじない程度の効果しか感じませんでした。
もちろん実際にやってみてですし、今となってはその理由も何となく想像できるようになりました。
効果がない理由としては、FCPやLCPに寄与する影響度が小さすぎるからでしょう。
理論的には効果があるから情報として存在しているのだと思いますが、実際にはサードパーティが多数読み込まれていたり、画像も重かったり、スクリプトもガンガン使われていたりでかき消されてしまうんだと思います。
ウェブフォントはなぜ重い？
フォントって漠然としてますよね。フォントファイルって何なんだろうと。
実は中身はフォントそのものなんです。
例えば日本語であれば、あいうえおのひらがなはもちろん、漢字も、数字も、記号も、全ての文字データの集まりです。
英語であればアルファベットのabcに数字や記号なんで実はそこまで重くありません。
英語のGoogleフォントも然りです。
では日本語はいったい何文字の文字データがあるでしょうか。数千はありますよね？
更に太さによってもフォントファイルは分かれていますので、通常の太さと太字で2倍です。
一部の見出しやメニューなどに使うためだけにfont-weightで500とか600とかも追加すると、数千文字分のデータが3倍、4倍と膨れ上がってきます。
お洒落に複数種類のGoogleフォントを色々な太さで読み込んだりすると、当然それ相当の重さになります。
結局どれが一番効果的？
これまでの経験から導き出されたウェブフォント対策をまとめると以下になります。
| 施策 | 効果 | コメント |
|---|---|---|
| Googleフォントをサイト側で読み込まない | ★★★★★ | 最も効果があります。Googleフォント自体を読み込まなくなるため、リクエスト数・通信量ともに削減できます。デザインに強いこだわりがなければ、この方法が一番おすすめです。 |
| 必要な文字だけサブセット化する | ★★★★☆ | 日本語フォントでは特に効果が大きいです。タイトルやロゴなど、使用する文字数が少ない場合は大幅な軽量化が期待できます。 |
display=swap を設定する | ★☆☆☆☆ | 表示体感は改善する場合がありますが、PageSpeed Insightsのスコアが大きく改善することはあまりありません。設定して損はありませんが、過度な期待はしない方が良いでしょう。 |
| Googleフォントをローカル配信するだけ | ★☆☆☆☆ | CDNではなく自サーバーから配信しても、フォントデータ自体が軽くなるわけではありません。通信先が変わるだけなので、表示速度改善の効果は限定的です。 |
あくまで表示速度の観点からのおすすめになります。
デザインを重視するのであればウェブフォントは手軽にサイトをかっこよくすることができる便利なものなので、何を重視するかによって判断していただければなと思います。