WordPress高速化の実装手順｜表示速度の原因診断と改善

WordPressの表示速度は、記事、画像、プラグイン、テーマ改修、解析タグの追加を重ねるほど少しずつ悪化します。

最初は問題なく見えていたサイトでも、いつの間にかトップページ、サービスページ、記事、問い合わせフォームの表示が重くなり、広告やSEOで集めた訪問者を取りこぼしていることがあります。

このとき、いきなり高速化プラグインを増やすと、原因が見えにくくなります。たとえば、画像が重いページにDB最適化だけをしても、ファーストビューの表示はほとんど変わりません。逆に、サーバー応答が遅い状態でCSSだけを圧縮しても、体感速度は上がりにくいです。

GoogleのCore Web Vitalsは、読み込み、操作性、レイアウトの安定性を見る指標として整理されています。代表的にはLCP、INP、CLSです。

web.dev: Web Vitals

また、WordPress公式の最適化ガイドでも、不要なプラグインの見直しや、プラグインごとの負荷確認が重要な観点として扱われています。

WordPress Developer Resources: Optimization

WordPress高速化は、プラグインを入れる作業ではなく、遅い原因を特定して、影響が大きい順に直す作業です。

先に結論：高速化はプラグイン導入ではなく原因診断から始める

WordPress高速化の最初の目的は、スコアを上げることではありません。

問い合わせ、資料請求、予約、購入などのCVに向かうページで、ユーザーが離脱しにくい表示速度にすることです。

そのため、まず次の順番で確認します。

順番	確認すること	見るポイント
1	重要ページを決める	トップ、サービスページ、記事、LP、フォーム
2	現在値を測る	PageSpeed Insights、Lighthouse、Search Console
3	ファーストビューを見る	LCP対象、画像、フォント、メインビジュアル
4	重いリソースを見る	画像、CSS、JavaScript、外部タグ
5	WordPress内部を見る	プラグイン、テーマ、DB、PHP、Cron
6	サーバー側を見る	TTFB、PHPバージョン、MySQL、キャッシュ、CDN
7	修正後に再測定する	変更前後で同じURLを比較する

ここを飛ばして高速化プラグインを複数入れると、設定が競合しやすくなります。キャッシュ、CSS結合、JavaScript遅延読み込み、画像変換を複数プラグインで同時に触ると、画面崩れやフォーム不具合が起きることがあります。

最初に決めるべきなのは、導入するプラグイン名ではなく、どのページのどの指標を改善するかです。

高速化は「何を入れるか」より「どこを触らないか」も大事です。

まずPageSpeed Insightsで見るべき数字

最初に見るのは、PageSpeed Insightsです。

ただし、点数だけを見ると判断を間違えます。まず見るべきは、どの指標が悪いのかです。

指標	見ていること	WordPressでよくある原因
LCP	メインコンテンツが表示される速さ	ファーストビュー画像、サーバー応答、CSS、フォント
INP	操作への反応	重いJavaScript、外部タグ、テーマやプラグインの処理
CLS	表示中のレイアウトずれ	画像サイズ未指定、広告、埋め込み、Webフォント
TTFB	サーバーが返し始めるまでの時間	PHP処理、DB、キャッシュなし、サーバースペック

Google Search ConsoleのCore Web Vitalsレポートは、実ユーザーのデータをURLグループ単位で確認できます。

Google Search Console Help: Core Web Vitals report

開発中はLighthouseのラボデータを使い、公開後や既存サイトではSearch Consoleのフィールドデータも見ます。

ここで重要なのは、トップページだけを測らないことです。WordPressでは、記事詳細、カテゴリ一覧、サービスページ、フォームページで読み込むプラグインやテンプレートが違います。

PageSpeed Insightsは点数を見る道具ではなく、LCP、INP、CLS、TTFBのどこから直すかを決める道具です。

画像は最初に疑う

WordPressが遅いとき、最初に疑うべきは画像です。

特に次の状態はよくあります。

状態	起きること	対策
4000px以上の画像をそのまま使っている	ダウンロード量が増える	表示サイズに合わせてリサイズする
JPEG/PNGだけで配信している	ファイルサイズが大きい	WebPやAVIFへの変換を検討する
ファーストビュー画像が重い	LCPが悪化する	メイン画像だけ別管理し、圧縮率を調整する
画像のwidth/heightがない	読み込み中にレイアウトがずれる	サイズ指定を入れる
下部画像まで最初に読む	初期表示が遅くなる	遅延読み込みを設定する

画像圧縮プラグインを入れる前に、そもそもアップロード時点で画像が大きすぎないかを見ます。

よくある失敗は、トップのメインビジュアルだけデザイナーが作った高解像度画像をそのまま使っているケースです。この場合、全画像を一括圧縮するより、LCP対象になっている1枚を調整する方が効果が出ます。

画像改善では、全画像を一括で触る前に、LCP対象になっているファーストビュー画像を先に確認します。

キャッシュは万能ではない

キャッシュはWordPress高速化で効果が出やすい施策です。

ただし、キャッシュには種類があります。

キャッシュ	内容	注意点
ページキャッシュ	HTMLを静的に返す	ログイン状態、フォーム、会員ページでは注意
ブラウザキャッシュ	画像やCSSを端末側に保存する	更新が反映されにくいことがある
オブジェクトキャッシュ	DB問い合わせ結果などを保存する	Redis/Memcachedなど環境依存がある
CDNキャッシュ	CDN側で配信する	管理画面や動的ページを除外する

コーポレートサイトやメディアのように、ほとんどのページが静的に見えるサイトではページキャッシュが効きます。一方、会員制サイト、予約、EC、問い合わせフォーム、診断フォームでは、キャッシュ除外の設計が必要です。

キャッシュプラグインを使う場合も、最初から全部の設定をオンにしない方が安全です。ページキャッシュ、CSS最適化、JavaScript遅延、画像変換を1つずつ有効にして、表示崩れとフォーム送信を確認します。

キャッシュは速くする設定であると同時に、フォームやログイン画面を壊しやすい設定でもあります。

CSSとJavaScriptは「減らす」が先

CSSやJavaScriptは、圧縮や結合よりも、まず減らすことを考えます。

WordPressでは、使っていないプラグインのCSSやJavaScriptが全ページで読み込まれていることがあります。

たとえば、問い合わせフォームのスクリプトが全記事で読み込まれている、スライダー用JavaScriptがトップページ以外でも読み込まれている、SNS埋め込みや解析タグが過剰に入っている、といった状態です。

確認項目	改善の考え方
全ページ読み込みのCSS/JS	必要ページだけで読み込む
スライダーやアニメーション	CVに関係しないなら削る
外部タグ	広告、ヒートマップ、チャット、計測タグを棚卸しする
Webフォント	ウェイト数を減らす、必要文字だけ読む
JavaScript遅延	フォームやメニューが壊れない範囲で試す

Autoptimizeのようなプラグインは、CSS、JavaScript、画像などの最適化に使われることがあります。

WordPress.org: Autoptimize

ただし、圧縮や遅延読み込みはサイトごとに相性があります。管理画面でオンにしただけで終わらせず、スマホ表示、ハンバーガーメニュー、フォーム、CTA、計測タグが動くかまで確認します。

CSSとJavaScriptは、圧縮より先に「不要な読み込みを減らす」ことを優先します。

プラグインとテーマを棚卸しする

WordPress高速化で避けて通れないのが、プラグインとテーマの棚卸しです。

特に次のプラグインは負荷や読み込み範囲を確認します。

種類	確認すること
ページビルダー	CSS/JSが過剰に出ていないか
フォーム	全ページでスクリプトを読んでいないか
多機能SEOプラグイン	使っていない機能が多くないか
セキュリティ系	ログやスキャンでDBが重くなっていないか
解析・タグ系	外部通信が増えすぎていないか
バックアップ系	実行時間と保存先が適切か

削除する前には、必ずバックアップと検証環境を用意します。不要に見えるプラグインでも、ショートコード、カスタム投稿、フォーム、リダイレクト、構造化データに使われていることがあります。

テーマも同じです。多機能テーマは便利ですが、使っていない機能のCSSやJavaScriptまで読み込むことがあります。テーマ変更が難しい場合でも、子テーマ、テンプレート、読み込み制御で改善できることがあります。

プラグイン削除は作業ではなく、影響範囲を確認してから止める小さな移行プロジェクトです。

DB・PHP・サーバー側を確認する

画像やキャッシュを直しても遅い場合は、WordPress内部とサーバー側を見ます。

領域	よくある問題	改善例
DB	リビジョン、不要なtransient、肥大化したログ	不要データ削除、インデックス、定期メンテナンス
autoload	optionsテーブルのautoloadが重い	不要なautoload設定を整理する
PHP	古いPHP、メモリ不足、重い処理	バージョン更新、メモリ設定、処理の見直し
wp-cron	アクセス時に重い定期処理が走る	サーバーcronへ移す、実行頻度を見直す
サーバー	TTFBが遅い、CPU/メモリ不足	サーバー変更、プラン見直し、キャッシュ導入
CDN	画像や静的ファイルが遠い	CloudflareなどCDN配信を検討する

この領域は、管理画面だけでは判断しにくいです。

特にautoloadの肥大化、重いクエリ、PHPエラー、Cronの詰まりは、表面上は「なんとなく重い」としか見えません。サーバーログ、Query Monitor、New RelicのようなAPM、ホスティング側のモニタリングで確認します。

WP-OptimizeのようにDB、キャッシュ、画像圧縮をまとめて扱うプラグインもあります。

WordPress.org: WP-Optimize

ただし、DB最適化はやり直しが難しい作業も含みます。削除系の操作は、バックアップ、検証、復元手順を確認してから実行します。

画像やキャッシュで改善しない場合は、autoload、Cron、PHP、DB、サーバー応答の順に裏側を確認します。

CDNとサーバー移行は最後の手段ではない

「サーバー移行は最後」と考えがちですが、実際には早めに判断した方がよい場合があります。

たとえば、次の状態なら、細かいチューニングよりサーバーやCDNの見直しが効くことがあります。

• TTFBが常に遅い
• 管理画面も遅い
• アクセスが増える時間帯だけ極端に重い
• PHPやMySQLのバージョンが古い
• 共有サーバーでリソース制限に当たっている
• 海外アクセスや全国配信で静的ファイルが遅い

LiteSpeed Cacheのように、サーバー環境と組み合わせて使われる高速化プラグインもあります。

WordPress.org: LiteSpeed Cache

ただし、サーバー移行だけで全部解決するとは限りません。重い画像、不要プラグイン、外部タグ過多が残っていれば、新しいサーバーでも遅くなります。

理想は、先に現状を測り、移行前後でどの指標が改善したかを比較できる状態にしてから移行することです。

サーバーやCDNを見直す判断は、TTFBや負荷状況を測ってから行うと失敗しにくくなります。

高速化作業で壊れやすい箇所

WordPress高速化は、表示速度だけを見て進めると事故が起きます。

特に壊れやすいのは次です。

箇所	起きる不具合	確認方法
問い合わせフォーム	送信できない、確認画面が出ない	テスト送信する
ハンバーガーメニュー	スマホで開かない	実機またはモバイル表示で確認する
スライダー	画像が表示されない	トップとLPを確認する
CTAボタン	クリック計測が消える	GTMやGA4イベントを見る
埋め込み	YouTube、地図、SNSが崩れる	各ページの埋め込みを確認する
管理画面	投稿編集が遅い、エラーが出る	管理者で編集作業を試す

本番でいきなり設定を変えるのではなく、できれば検証環境で変更し、公開前に主要導線を確認します。

高速化プラグインの設定変更は、見た目が崩れなくてもCV計測が壊れることがあります。資料請求、問い合わせ、電話クリック、LINE追加など、売上につながるイベントは必ず確認します。

高速化の完了条件は、速くなったことだけでなく、フォーム、CTA、計測が壊れていないことです。

実装順序のおすすめ

WordPress高速化を実務で進めるなら、次の順番が安全です。

フェーズ	作業	完了条件
1	重要URLを決める	CVに近いページが優先対象になっている
2	現状測定	PageSpeed、Search Console、サーバー応答を記録した
3	画像改善	LCP画像と重い画像をリサイズ・圧縮した
4	キャッシュ設定	ページキャッシュと除外条件を確認した
5	CSS/JS整理	不要な読み込みと外部タグを削った
6	プラグイン棚卸し	不要プラグインを停止・削除した
7	DB/PHP確認	autoload、Cron、PHP、DBの問題を確認した
8	サーバー/CDN検討	TTFBや負荷状況から必要性を判断した
9	導線確認	フォーム、CTA、計測、スマホ表示を確認した
10	再測定と運用化	変更前後を比較し、月次確認項目を決めた

この順番にすると、効果が大きいところから触りつつ、サイトを壊すリスクを下げられます。

WordPress高速化で一番避けたいのは、設定をたくさん変えたのに、何が効いたのか分からない状態です。変更は小さく分け、変更前後の数字を残します。

まとめ

WordPress高速化でやるべきことは、単に高速化プラグインを入れることではありません。

重要なのは、次の順番です。

1. CVに近い重要ページを決める
2. PageSpeed Insights、Lighthouse、Search Consoleで現状を測る
3. LCP、INP、CLS、TTFBのどこが悪いかを見る
4. 画像、キャッシュ、CSS/JS、外部タグを優先して直す
5. プラグイン、テーマ、DB、PHP、wp-cron、サーバーを確認する
6. フォーム、CTA、計測が壊れていないか確認する
7. 変更前後の数字を残し、定期的に見直す

WordPressは、記事追加、プラグイン追加、テーマ改修、タグ追加を繰り返すほど少しずつ重くなります。

だからこそ、高速化は一回きりの作業ではなく、保守改善の一部として扱うべきです。

WordPress高速化は一度の設定変更ではなく、表示速度と保守リスクを定期的に見直す運用です。