【実録】WordPressのモバイルスコアを58 → 94 に上げた全工程を公開

〜SWELLテーマ × シン・レンタルサーバーでの実践記録〜

今回は実際にこのブログ「ウェブlog」のPageSpeed Insightsスコアをモバイルで58点から94点に改善した全工程をそのまま公開します。

大事なのは「やってみたら効果がなかった施策」も正直に記録していること。失敗も含めてリアルな検証記事です。

SWELLの導入をまだ検討中の方はこちらも参考にしてください。→ SWELLの評判・口コミを正直レビュー｜Cocoonとの違いと乗り換えるべき人を徹底解説

まず結果から：Before / After

指標	改善前（Before）	改善後（After）	変化
総合スコア（モバイル）	58点	94点	+36点
FCP（最初の描画）	7.1秒	1.1秒	-6.0秒
LCP（最大要素の描画）	9.2秒	2.9秒	-6.3秒
TBT（ブロック時間）	20ms	30ms	ほぼ同じ
Speed Index	7.1秒	3.1秒	-4.0秒
CLS（レイアウトずれ）	0	0	変化なし

PageSpeed Insightsのスコアは計測のたびに5〜10点程度ブレることがあります。複数回計測して傾向を見るようにしましょう。

検証環境

• サーバー：シン・レンタルサーバー
• WordPressテーマ：SWELL
• 計測ツール：PageSpeed Insights（モバイル）
• 計測ページ：トップページ

検証した施策と結果一覧

施策	採用	スコア変化	ひとこと
TypeSquare Webfonts削除	採用	+1点	使っていないプラグインは削除
スクリプト遅延読み込み ON	不採用	-2点	メインビジュアルが遅くなった
Googleフォントをローカル配信（OMGF）	採用	+24点	最大の効果！
手動フォントローカル配信	比較用	OMGFより-5点	仕組み理解には最適 追加の調整が必要
Prefetch（ページ遷移高速化）	不採用	-11点	PSIには逆効果
フッター・記事下の遅延読み込み	不採用	-20点	トップページでは逆効果
メインビジュアル画像の最適化	採用	+11点	1MBを軽量WebPに差し替え

実際行った6つの検証

検証①：TypeSquare Webfontsプラグインの削除

まず最初にやったのがプラグインの棚卸しです。インストール済みプラグインを見直したところ、「TypeSquare Webfonts for エックスサーバー」が有効になっていました。

このプラグインはXサーバー系列のWebフォントを読み込むためのものですが、SWELLのフォント設定を確認したところ「Noto Serif JP（Googleフォント）」を使っており、TypeSquareのフォントは実際には使われていませんでした。

削除後の結果：スコア 58 → 59（LCPが9.2秒→8.1秒に改善）

検証②：スクリプト遅延読み込み（効果なし・むしろ悪化）

SWELL設定の「スクリプトを遅延読み込みさせる」をONにしてみました。PageSpeed Insightsでレンダリングブロックが5,400ms削減できると指摘されていたため期待していましたが…

結果：LCPが9.2秒→12.8秒（大幅ダウン）

結果はLCPが9.2秒→12.8秒と大幅悪化。メインビジュアルの読み込みに使うlazysizes.jsが遅延対象になってしまったことが原因と考えられます。

教訓：

「スクリプト遅延」はサイトの構成によって逆効果になることがある。SWELLのメインビジュアルを使っている場合は注意が必要。

検証③：Googleフォントのローカル配信（最大の効果）

このブログではSWELLのフォント設定で「Noto Serif JP」（Googleフォント）を使用しています。Googleフォントは外部サーバーから読み込むため、その通信コストがFCPを大幅に遅延させていました。

これを自分のサーバーから配信（ローカルホスティング）することで劇的に改善されました。

方法A：プラグイン「OMGF」を使う（採用）

「OMGF | Host Google Fonts Locally」をインストールして有効化するだけ。自動でGoogleフォントを検出してサーバーに保存してくれます。

結果：スコア 59 → 83（FCP 7.1秒 → 1.1秒！）

方法B：手動でフォントをローカル配信（比較用）

プラグインを使わず手動でやる場合の手順です。仕組みを理解したい方や、プラグインを増やしたくない方向け。

結果：スコア 78（OMGFより-5点）。preload指定がない分、フォントの優先度が下がることが原因と考えられます。

OMGFはpreloadを自動で設定してくれるため、手動より優秀な結果になりました。

検証④：Prefetchの検証（効果なし）

SWELL設定の「ページ遷移高速化 → Prefetch」を有効にしてみました。リンクにマウスが乗った瞬間に次のページを先読みする機能で、実際のユーザー体感速度には効果があります。

結果：スコア83 → 72（大幅ダウン）

しかしPageSpeed Insightsのスコアは83 → 72と大幅ダウン。PrefetchのJSがレンダリングをブロックしているとPageSpeed Insightsが判断したためと思われます。

PageSpeed Insightsのスコアと実際のユーザー体験は別物です。Prefetchは体感速度には有効ですが、スコア改善目的には不向きということですね。

検証⑤：フッター・記事下の遅延読み込み（逆効果）

SWELL設定の「フッターを遅延読み込みさせる」「記事下コンテンツを遅延読み込みさせる」を試しました。

結果：スコア 83 → 63（大幅ダウン）

結果はスコア 83 → 63と大幅悪化。トップページではフッターのお問い合わせフォームなどがLCPの計算対象になってしまったことが原因と考えられます。

この設定は記事ページでは有効に働く可能性があります。トップページでの使用には注意が必要です。

検証⑥：メインビジュアル画像の最適化（大きな効果）

最後に手をつけたのがメインビジュアル画像の最適化です。元の画像は以下のスペックでした。

• サイズ：2000×979px
• ファイルサイズ：約1MB
• 形式：JPEG

これをSquoosh（ブラウザ上で簡単画像加工できます）で最適化してWebP形式で再アップロードしました。

• 横幅：1200pxに縮小
• 形式：WebP
• ファイルサイズ：180KB(大幅削減)

結果：スコア 83 → 94（LCP 4.5秒 → 2.9秒！）

メインビジュアル1枚の差し替えだけでここまで変わるとは驚きでした。

まとめ：このサイトで効果があった施策

優先度	施策	難易度	効果
★★★	Googleフォントのローカル配信（OMGF）	低（プラグインのみ）	超大
★★★	メインビジュアル画像の最適化	低（画像差し替え）	大
★☆☆	不要プラグインの削除	低	小

SWELLが標準で高速化の基盤をしっかり作ってくれているため、追加でやるべきことは意外とシンプルでした。

特にGoogleフォントのローカル配信は、Googleフォントを使っているWordPressサイトなら必須レベルの施策と言えます。

逆効果だった施策（注意！）

• スクリプトの遅延読み込み → メインビジュアルが遅くなった
• Prefetch → PageSpeed Insightsのスコアが下がった
• フッター・記事下の遅延読み込み → トップページでは逆効果

「良さそう」に見えても、サイトの構成によっては逆効果になることがあります。必ず1つずつ変更して計測することが重要です。

おわりに

今回の改善作業を通じて一番学んだことは「計測→変更→再計測」を1つずつ丁寧に繰り返すことの大切さです。

PageSpeed Insightsのスコアは毎回5〜10点程度ブレるので、1回の計測で一喜一憂せず、複数回の平均で判断することも重要です。

この記事が同じようにサイト速度改善に取り組む方の参考になれば嬉しいです！