WordPressの表示速度を見直していたとき、最後まで原因が特定できずに困ったのがモバイルのPageSpeed Insightsでした。
デスクトップはそこまで悪くない。（といっても60点台）
でもモバイルだけ、40〜50点台が出る。
GA4、Jetpack、reCAPTCHA、Cocoonの高速化設定。
いろいろ試したけど、決定打がない。
そんな状態がしばらく続いていました。
そこで最後に見直したのが、ConoHa WINGで使っていたWebフォントです。
具体的には、TypeSquare Webfonts for ConoHa を無効化して再測定してみました。
結論から言うと、私の環境ではこれがいちばん変化が大きかったです。
モバイルのPageSpeed Insightsで80点台が出やすくなって、条件が良いと90点を超えることもありました。
マジかよ…
そこなのかよ…
この問題を突き止めるのに、めちゃくちゃ時間を無駄にしました😱
もちろん、これは私のサイトでの話です。
テーマ、プラグイン、画像、広告、キャッシュ設定が違えば結果も変わります。
ただ、Webフォントは初期表示に影響しやすい要素です。
ConoHa WINGでTypeSquareを使っていて、モバイルのスコアがなかなか伸びないなら、一度切り分けの対象に入れてみる価値はあると感じています。
先に結論
この記事の結論はこんな感じです。
- 私の環境でいちばん差が大きかったのは、Webフォント停止だった
TypeSquare Webfonts for ConoHaを無効化したあと、モバイルで80点台が出やすくなった- GA4やJetpackの見直しでも変化はあったが、決定打ではなかった
- reCAPTCHAやCocoonの高速化設定も見直したが、決定打ではなかった
- PageSpeed Insightsは毎回同じ点数にならないので、1回の測定だけで判断しない方がいい
- TypeSquare自体が悪いという話ではなく、速度優先なら一度オフで比較してみる価値がある
最初は「いかにも重そうなもの」から疑っていたんですよね。
GA4とか、Jetpackとか、reCAPTCHAとか。
でも最終的には、Webフォントのプラグインが重かったと分かりました。
まず前提：TypeSquareが悪いと言いたいわけではない
最初に書いておきます。
この記事は、
「TypeSquareは悪い」
「ConoHaのWebフォントは使わない方がいい」
と言いたいわけではありません。
Webフォントを使うと、サイトの雰囲気を整えやすくなります。
見出しや本文の印象も変わりますし、デザイン面での魅力はたしかにあります。
ただ、Webフォントは読み込みやレンダリングに影響することがあります。
特に日本語フォントは文字数が多いぶん、表示速度への影響が出やすいです。
まとめると、こういう話です。
- TypeSquareは便利な公式機能
- ただしWebフォント全般には表示速度の負担がある
- 私のブログでは、速度を優先した方が合っていた
デザイン性を取るか、速度を優先するか。
私は速度を選びました。
私が試したことと結果の印象
厳密な検証ではありませんが、私の環境ではだいたいこんな印象でした。
| 試したこと | 結果の印象 | 判断 |
|---|---|---|
| GA4を外す | 7〜10点くらい上がることはあった | 多少効くが、決定打ではない |
| Jetpackを削除 | 少し軽くなったように見えることはあった | 影響はあるが大差ではない |
| reCAPTCHA v3をCloudflare Turnstileに変更 | 外部スクリプトの負担は減った印象 | 改善要素の1つではある |
| cdnjsや高速化設定の見直し | 上がることも下がることもあった | 単独では判断しにくい |
TypeSquare Webfonts for ConoHa を無効化 | モバイルで80点台が出やすくなった | いちばん差が大きかった |
ただ、GA4やJetpackが無意味だったわけではありません。
GA4を外せば軽くなる場面はあるし、Jetpackも多機能なので見直し対象になります。
reCAPTCHA v3も外部スクリプトなので、速度面で気になるのは自然なことです。
それでも私のサイトでは、どれを触っても「少し変わったかな」くらいで止まることが多かった。
最後まで初期表示を引っ張っていたのが、Webフォントだったのかもしれない。
今はそう見ています。
関連記事
＞WordPressのアクセス解析は何を使うべき？GA4・Jetpack・Cloudflareの使い分け
＞WordPressのContact Form 7でreCAPTCHA v3をTurnstileに変えたら迷惑メールが増えた話
重いと言われれるGA4を外した結果の数値
GA4を入れている時の私のとあるページの数値です↓
どちらも同じURLですが、携帯電話で52点で、デスクトップでは51点でした。何回測定しても、このあたりの数値をうろちょろします。
では重いと言われるGTA4を外したらどうなるのでしょうか？
結果はこちら↓
52点と63点。何回か測定すると、この数値よりも悪い時もあるし、良い時もあります。なんにせよ…そんなに変わらねー😭
重いと言われるGA4を外してこの程度なんですよね。
TypeSquareを外した場合のPageSpeed Insightsのスコア
現在の私の運用はTypeSquareを外しています。GA4は入れています。その状態でのPageSpeed Insightsのスコアはというと…
携帯電話で90点台が出ています。調子悪い時でも80点以上は出ています。
重いと言われているGA4を入れていても、これくらいの点数が出るんですよね。
この結果に自分が一番驚いています。SEOの専門家でもない自分が、50点台から90点台までスコアを上げられたことに(ﾉﾟοﾟ)ﾉ
良かれと思って入れていたプラグインが、サイトをこんなにも重くしていたなんて😭
スコアだけでなく指標を見ると、疑う場所が分かる
PageSpeed Insightsの指標を見る目的は、点数の低さを眺めることではなく、次に疑う場所を決めることです。
| 指標 | 何を見る指標か | 悪いときに疑うもの |
|---|---|---|
| FCP | 最初のコンテンツが表示されるまでの時間 | サーバー応答、CSS、Webフォント、レンダリングを妨げるリソース |
| LCP | 画面内で最も大きな主要コンテンツが表示されるまでの時間 | アイキャッチ画像、メインビジュアル、Webフォント、CSS、サーバー応答 |
| TBT | JavaScriptなどの長い処理でメインスレッドがブロックされた合計時間 | GA4、広告タグ、重いプラグイン、外部スクリプト、JavaScript処理 |
| CLS | 表示中に予期しないレイアウトのズレが起きた量 | 画像サイズ未指定、広告枠、埋め込み要素、フォント切り替え、後から表示される要素 |
| Speed Index | ページ内容が視覚的にどれくらい早く表示されるか | 画像、CSS、Webフォント、レンダリングブロック、初期表示全体 |
たとえば、TBTが悪いならJavaScriptや外部タグを疑います。GA4、広告タグ、重いプラグインなどが候補になります。
一方で、FCPやLCPが悪いなら、JavaScriptだけでなく、画像、CSS、サーバー応答、Webフォントなども疑った方がいいです。
CLSが悪いなら、画像サイズの未指定、広告枠、埋め込み要素、フォント切り替えなどによるレイアウトのズレを見ます。
つまり、スコアは結果です。指標は、原因を探すためのヒントです。
私がWebフォントを疑うようになった理由
最初に疑ったのは、「重い」と言われている系のものでした。
- GA4
- Jetpack
- reCAPTCHA
- 外部CDN
- 高速化設定まわり
どれも「重そう」に見えたからです。
実際、多少の変化はありました。
GA4を外せばスコアが上がることはあったし、Jetpackを削除して少し軽くなったように見えることもありました。
reCAPTCHA v3をTurnstileに変えたことで、外部スクリプトの負担が減った印象もありました。
ただ、どれを触っても「前より少しマシかも」くらいで止まるんですよね。
しかも測定タイミングで上がったり下がったりするので、これだという手応えがありませんでした。
そこで最後に見直したのが、ConoHa WINGのWebフォント設定でした。
TypeSquareを止めてみたら、そこで初めてモバイルの点数が一段上がった感覚がありました。20点くらい上がりました。
「嘘だろ？」と思って何回もプラグインのオン/ オフを切り替えて測定しました。疑いようもなく、TypeSquareをオフにすることで点数が爆上がりしていました。
JavaScriptやプラグインを減らすより、表示の入り口にあるフォントを軽くした方が効いた…マジかよ。完全にノーマークなプラグインでした。
なぜWebフォントは重くなるのか？
Webフォントは、画像や後から読み込まれる装飾とは少し違います。
文字の表示そのものに関わるものです。
本文や見出しにWebフォントを使っている場合、ブラウザはフォントファイルを読み込みながら画面を描画します。
そのため、標準フォントだけで表示する場合より、初期表示の負担が増えやすくなります。
日本語フォントは英数字中心のフォントよりデータ量が大きくなりやすいので、そのぶん速度への影響も出やすいです。
TypeSquareをオフにして困ったか
無効化する前は、少し迷いました。
- サイトの雰囲気が落ちるのでは
- 見出しの印象が変わりすぎるのでは
- 安っぽく見えないか
実際には、私のブログではそこまで困りませんでした。
フォントの印象は変わります。
見た目にこだわるなら、Webフォントを使う価値はたしかにあります。
ただ、スマホで記事を読むときに読者が意識するのは、凝った書体よりも、
- 早く開く
- 文字がすぐ読める
- スクロールが重くない
- 表示が安定している
の方だと感じました。
ブランドサイトやデザイン重視のサイトなら、Webフォントを残す判断もじゅうぶんあります。
でも、記事中心の個人ブログなら、標準フォントに戻しても大きな不満は出にくいと思います。
ConoHa WINGユーザーが試すならこの手順がおすすめ
TypeSquare Webfonts for ConoHa を有効化しているなら、次の順番で確認するのがおすすめです。
- 現在のURLをPageSpeed Insightsで測る
- モバイルとデスクトップを分けて見る
- スコアだけでなくFCP、LCP、CLSを確認する
TypeSquare Webfonts for ConoHaを一時的に無効化する- 同じURLを複数回測る
- 表示崩れがないか確認する
- デザインと速度のどちらを優先するか判断する
できれば、他の設定変更と同時にやらない方が比較しやすいです。
いろいろ一気に触ると、何が効いたのか分からなくなります。
まずはTypeSquareだけを止めて、同じURLで測ってみる。
それだけで、かなり判断しやすくなります。
まとめ
WordPressのPageSpeed Insightsを改善しようとして、最初はいかにも重そうなものから疑いました。
GA4、Jetpack、reCAPTCHA、cdnjs、高速化設定、プラグイン整理。
どれも無関係ではなかったと思います。でもすごく効果があるかと言われたら、「あるっちゃあるけれど、計測するたびにズレるからそこまで決定的とは言いづらい」という感じでした。
でも私の環境でいちばん差が大きかったのは、ConoHa WINGのTypeSquare Webフォントを止めたことでした。これは疑いようがないくらいにPageSpeed Insightsのスコアを爆上げさせました。
ConoHa公式はTypeSquareの導入手順を案内しているし、機能としては普通にいいものです。
その一方で、Webフォントは読み込みやレンダリングに影響します。
便利さと引き換えに、初期表示の負担になるケースがある、ということです。
もしConoHa WINGを使っていて、モバイルのPageSpeed Insightsがなかなか伸びないなら、TypeSquare Webfonts for ConoHa を一度オフにして比較してみる価値はあります。
少なくとも私のサイトでは、GA4やJetpackより、そこがいちばん効きました。
参考までに。それでは！
関連記事
＞WordPressのContact Form 7でreCAPTCHA v3をTurnstileに変えたら迷惑メールが増えた話
＞WordPressのアクセス解析は何を使うべき？GA4・Jetpack・Cloudflareの使い分け
参考情報
ConoHa WING「Webフォント」https://www.conoha.jp/wing/function/webfont/
ConoHa WINGサポート「Webフォント設定をする」https://support.conoha.jp/w/webfont/
web.dev「ウェブフォントを最適化する」https://web.dev/learn/performance/optimize-web-fonts?hl=ja
web.dev「Best practices for fonts」https://web.dev/articles/font-best-practices
Chrome for Developers「Lighthouse performance scoring」https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
コメント