正直に言う、WordPressの高速化は「原因特定」が9割だった【実録3ヶ月の記録】
「プラグインを減らせ」「キャッシュを入れろ」——そんな一般的なアドバイスは、もう何度も試した。それでもサイトの表示に3秒以上かかり、Google PageSpeed Insightsのスコアは30点台のまま。広告費をかけて集客しているのに、ユーザーがページを見る前に離脱していく。売上に直結する問題なのに、何が本当のボトルネックなのかわからない——同じようにもがいている人へ、この記事を書いています。私が3ヶ月かけてWordPressサイトの表示速度を改善した過程で「やって意味があったこと」「時間の無駄だったこと」を、数値とあわせて正直にまとめました。
目次
- 売上が落ちて初めて「表示速度」を本気で調べ始めた理由
- 原因を一つずつ潰してわかった「本当に効く施策」と数値変化
- 失敗と遠回り——やっても意味がなかった対策と見落としがちな罠
- WordPress高速化が向いている人・向いていない人の境界線
- 高速化の先にあるもの——速度改善で変わったこと
売上が落ちて初めて「表示速度」を本気で調べ始めた理由
サイト速度の問題は「気づいたとき」にはすでに機会損失が積み重なっています。
私が運営しているのは、月間PV約5万のBtoB向け情報メディアです。2025年の秋頃から、直帰率がじわじわ上がり、CVR（コンバージョン率）が目に見えて下がり始めました。記事の質が落ちたわけではない。流入キーワードも変わっていない。原因を探る中で、ようやくたどり着いたのが「表示速度」でした。
PageSpeed Insightsで現実を突きつけられた
計測してみると、モバイルスコアは28点。LCP（Largest Contentful Paint）は4.2秒。Googleが「良好」とする2.5秒以内を大幅に超えていました。
- モバイルスコア: 28/100
- LCP: 4.2秒
- TBT（Total Blocking Time）: 890ms
- CLS: 0.18
正直なところ、体感では「少し重いかな」程度。しかし数値は深刻でした。
「遅い」は売上に直結するという当たり前の事実
表示が1秒遅れるとCVRが大幅に低下するという話はよく聞きますが、自分ごとになるまでピンときませんでした。実際に速度改善に着手した後、結果としてCVRが改善に転じたことで、「体感」ではなく「数値」で判断する重要性を痛感しました。
原因を一つずつ潰してわかった「本当に効く施策」と数値変化
高速化の本質は「何が遅いのか」を正確に突き止めることです。闇雲にプラグインを入れても効果は限定的でした。
まず疑うべきはサーバー、次にテーマ、最後にプラグイン
多くの記事が「プラグインを減らそう」から始まりますが、私の場合、最大のボトルネックはサーバーのレスポンス速度（TTFB）でした。
当時使っていた月額500円台の共用サーバーでは、TTFBだけで1.5秒以上。どれだけフロントエンドを最適化しても、サーバーが足を引っ張っていたのです。
効果が大きかった順に並べると：
- サーバー移行（TTFB: 1.5秒 → 0.3秒）——これだけでLCPが約1秒短縮
- 画像のWebP変換＋遅延読み込み（LCPがさらに0.5秒改善）
- 未使用CSSとJavaScriptの削除・遅延読み込み（TBTが890ms → 280msに）
- キャッシュプラグインの導入（体感でさらに軽くなった）
改善後の数値
3ヶ月の施策完了後、数値は以下のように変化しました。
- モバイルスコア: 28 → 82
- LCP: 4.2秒 → 1.4秒
- TBT: 890ms → 280ms
- CLS: 0.18 → 0.05
一つ踏み込んで言うと、スコアの数字そのものよりCore Web Vitalsの3指標（LCP・INP・CLS）を「良好」の範囲に入れることが実際のSEO評価と体感速度の両方に効きました。スコアが60点でもCore Web Vitalsがすべて緑なら、80点でも一部赤いサイトより有利な場合があります。
失敗と遠回り——やっても意味がなかった対策と見落としがちな罠
高速化の情報は溢れていますが、「やった気になるだけ」の施策も多いのが現実です。
プラグインの数を減らしても速くならなかった
「プラグインは少ないほど速い」という通説を信じて、20個あったプラグインを12個まで減らしました。結果は——ほぼ変化なし。
理由は単純で、削除したプラグインのほとんどが管理画面でしか動作しないものだったから。フロントエンドでCSSやJavaScriptを読み込むプラグインかどうかを見極めずに闇雲に減らしても、表示速度には影響しません。
見落としがちなポイント：
- 問い合わせフォームプラグインが全ページでCSSとJSを読み込んでいた
- SNSシェアボタンのプラグインが外部スクリプトを5つも呼んでいた
- Google Fontsの読み込みがレンダリングブロックを起こしていた
数ではなく「何を読み込んでいるか」が重要です。
「とりあえずキャッシュプラグイン」の落とし穴
キャッシュプラグインを入れた直後は確かに速くなりました。しかし、会員機能付きのページやWooCommerceのカート画面で表示がおかしくなるトラブルが発生。キャッシュの除外設定を正しく行わないと、ユーザーに他人の情報が表示されるリスクすらあります。
また、キャッシュプラグインを2つ重複して入れていた時期があり、逆にサイトが遅くなりました。キャッシュ系プラグインは1つに絞るのが鉄則です。
CDNを入れたら逆に遅くなったケース
無料CDNを設定したものの、サーバーが国内にあるのにCDNのエッジサーバーが海外経由になり、国内ユーザーへのレスポンスがかえって遅くなった時期がありました。CDNは万能ではなく、ターゲットユーザーの所在地とCDNの拠点を確認してから導入すべきです。
WordPress高速化が向いている人・向いていない人の境界線
すべてのサイト運営者が同じ施策をすべきとは限りません。自分の状況に当てはめて判断してください。
向いている人
- サイトの表示速度が明確にビジネス成果（売上・問い合わせ）に影響している人。ECサイトやリード獲得型のサイトは、0.5秒の改善がCVRに直結します
- すでにコンテンツの質は担保できていて、次の改善ポイントを探している人。速度改善は「コンテンツが良い前提」で初めて威力を発揮します
- 月額数千円のサーバーを使っていて、予算的にサーバー移行が可能な人。最もコスパが高い施策がサーバー変更だからです
向いていない人（正直に言います）
- 記事が10本未満で、まだコンテンツが少ない段階の人。速度を上げてもそもそも見るページがなければ意味がありません。まずはコンテンツ作成に集中すべきです
- 技術的な設定を一切触りたくない人。高速化は多少の技術知識が必要で、設定ミスでサイトが真っ白になるリスクもあります。その場合は、最初から高速なマネージドホスティングサービスを選ぶほうが現実的です
- 月間PVが数百程度で、まだアクセス自体が少ない段階の人。速度改善の効果を実感しにくいため、優先順位としてはSEO対策やSNS活用が先になります
高速化の先にあるもの——速度改善で変わったこと
表示速度の改善は、単なる技術的チューニングではなく「ユーザー体験全体の底上げ」でした。
3ヶ月の改善を経て、直帰率は改善前と比較して明らかに下がり、平均セッション時間は伸びました。CVRも回復基調に転じ、最終的には改善前を上回る水準に達しています。
ただし、最も大きな変化は数値ではなく運営の姿勢でした。速度を意識するようになってから、新しいプラグインを入れる前に「本当に必要か」を考えるようになり、画像をアップロードする前に圧縮する習慣がつきました。サイト運営全体の「品質意識」が上がったことが、長期的には一番の収穫です。
迷っているなら、まずはPageSpeed Insightsで自分のサイトを計測してみてください。数値を見れば「何から手をつけるべきか」が見えてきます。高速化は一気にやる必要はなく、効果の大きい施策から一つずつ潰していけば、確実にサイトは速くなります。今日できる最初の一歩は、現状を正しく知ることです。