WordPressのパフォーマンス最適化10の方法｜計測から始める改善手順

WordPressの表示速度を上げるには、思いつく対策を片っ端から入れるより、「どこが遅いのか」を計測してから効く順に手を打つほうが近道です。この記事では、計測、サーバー、キャッシュ、画像、CSS/JavaScript、データベース、定期処理までの10の方法を、効果が出やすい順に並べて、それぞれの確認方法と注意点を解説します。

作業の前に、ファイルとデータベースのバックアップを取り、可能ならステージング環境で試してから本番に反映してください。キャッシュや読み込み順の変更は、表示崩れやフォームの不具合として後から気付くことが多いためです。

1. まず計測して、遅い場所を特定する

最初にやることは測定です。Google の PageSpeed Insights では、実際の利用者のデータ（フィールドデータ）と、テスト環境での計測（ラボデータ）の両方が見られます。改善の目標にするのは Core Web Vitals の3指標です。

• LCP（Largest Contentful Paint）：ページの主要な要素が表示されるまでの時間
• INP（Interaction to Next Paint）：クリックや入力への反応の速さ。2024年3月に FID から置き換わりました
• CLS（Cumulative Layout Shift）：表示中のレイアウトのずれ

サーバー側の遅さは、プラグイン「Query Monitor」で確認できます。管理バーに表示される生成時間やデータベースクエリの数、遅いクエリを出しているプラグイン名がわかるので、「何が重いか」の当たりを付けられます。計測結果は改善前の値として残しておき、1つ対策をするたびに同じ条件で測り直すと、どの対策が効いたかを切り分けられます。

2. PHP とサーバー環境を見直す

WordPress 本体やプラグインの処理は PHP が実行するため、PHP のバージョンは速度とセキュリティの両方に効きます。サポートが終わった古いバージョンを使っている場合は、サーバーのコントロールパネルで新しいバージョンに切り替えます。WordPress が推奨する PHP のバージョンは WordPress.org の要件ページで公開されているので、推奨値は更新されていくため、作業時点の値をそちらで確かめてください（2026年10月現在）。

切り替える前に、テーマとプラグインが新しい PHP に対応しているかを確かめます。ステージングで切り替えて、管理画面とフロントの主要ページを一通り開き、エラーが出ないことを確認してから本番に反映すると安全です。あわせて OPcache が有効かどうかもサーバーの設定で確認します。多くのレンタルサーバーでは既定で有効です。

3. ページキャッシュを入れる

WordPress は通常、ページを表示するたびに PHP とデータベースで HTML を組み立てます。ページキャッシュは、組み立て済みの HTML を保存しておき、次の訪問者にそのまま返す仕組みです。体感速度とサーバー負荷の両方に最も効きやすい対策です。

導入方法は、サーバー側の機能（レンタルサーバーのキャッシュ機能や Nginx の FastCGI キャッシュなど）を使うか、キャッシュプラグインを使うかのどちらかです。両方を同時に有効にすると、更新が反映されない・古いページが残るといったトラブルの原因になるので、どちらか一方に寄せます。

ログイン中のユーザー、カート・マイページ、フォームの送信確認画面などは、キャッシュから除外する必要があります。ネットショップや会員サイトでは、除外設定を確認してから有効にしてください。

4. オブジェクトキャッシュを使う

ページキャッシュが効かないログイン中の画面や管理画面、WooCommerce のカートなどは、毎回データベースに問い合わせが発生します。ここに効くのが永続オブジェクトキャッシュです。Redis や Memcached をサーバーに用意し、対応するプラグイン（Redis Object Cache など）で WordPress から使えるようにすると、同じクエリの結果をメモリから返せるようになります。

サーバーが Redis や Memcached に対応しているかは、利用しているサーバー会社の案内を確認してください。共有サーバーでは使えないこともあります。WordPress の「サイトヘルス」画面で、永続オブジェクトキャッシュの利用が推奨として表示されることもあります。

5. 画像を軽くし、正しいサイズで出す

多くのサイトでページの重さの大半を占めるのが画像です。次の3点を確認します。

• 形式：写真は WebP（WordPress 6.5 以降は AVIF も扱えます。ただしサーバーの画像処理ライブラリが対応している必要があります）
• サイズ：表示幅より大きすぎる画像をそのまま載せていないか
• 読み込み方：ファーストビューより下の画像は遅延読み込みにする

テーマで画像を出すときは、<img> を手書きするより wp_get_attachment_image() を使うと、srcset と sizes が付き、画面幅に合った画像を選ばせられます。WordPress は本文の画像に loading="lazy" を自動で付けますが、LCP の対象になるファーストビューの大きな画像まで遅延読み込みにすると逆に遅くなります。

<?php
// テーマのテンプレートで、ファーストビューのメイン画像を出す例
echo wp_get_attachment_image(
	get_post_thumbnail_id(),
	'large',
	false,
	array(
		'loading'       => 'eager',
		'fetchpriority' => 'high',
	)
);

画像には幅と高さ（width / height）が付いていることも確認します。これがないと読み込み後にレイアウトがずれ、CLS が悪化します。

6. CSS と JavaScript の読み込みを整理する

PageSpeed Insights で「レンダリングを妨げるリソース」として指摘されるのは、HTML の表示を止めて先に読み込まれる CSS や JavaScript です（Lighthouse のバージョンによっては、別の診断項目にまとめて表示されます）。

自作のスクリプトは、WordPress 6.3 以降なら wp_enqueue_script() の5番目の引数で defer や async を指定できます。

<?php
// 子テーマの functions.php
add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'my-slider',
		get_stylesheet_directory_uri() . '/js/slider.js',
		array(),
		'1.0.0',
		array(
			'in_footer' => true,
			'strategy'  => 'defer',
		)
	);
} );

プラグインが全ページで読み込んでいる CSS や JavaScript が、実際には一部のページでしか使われていないこともよくあります。Query Monitor の「Scripts」「Styles」の欄でハンドル名を確かめ、不要なページでだけ wp_dequeue_script() / wp_dequeue_style() で外すと軽くなります。外したことでそのプラグインの機能が壊れていないか、対象ページを一通り開いて確認してください。

7. 使っていないプラグインとテーマ機能を減らす

プラグインの数そのものより、「重い処理をするプラグイン」が問題になります。Query Monitor でクエリ数や処理時間が多いプラグインを特定し、代わりの手段がないかを検討します。

• 使っていないプラグインは無効化ではなく削除する（無効化しただけでもファイルは残り、更新対象として管理が必要です）
• 似た機能のプラグインが重複していないか（SEO、キャッシュ、画像最適化などは重複しがちです）
• ページビルダーやスライダーなど、全ページで大きなファイルを読み込むものは、使うページを限定できないか

削除の前には、そのプラグインがショートコードやウィジェットを出していないかを確認します。消した後に本文に [shortcode] がそのまま表示される事故が起きやすいためです。

8. データベースを軽くする

長く運用したサイトでは、データベースに不要なデータがたまります。特に影響が大きいのが、ページ表示のたびに読み込まれる自動読み込み（autoload）のオプションです。削除したプラグインの設定が autoload のまま残っていると、全ページの表示が遅くなります。WordPress 6.6 以降はサイトヘルスで autoload の合計サイズが大きすぎる場合に警告が出ます。

サイズの大きい autoload オプションは、WP-CLI で次のように調べられます（テーブル接頭辞が wp_ 以外なら読み替えます）。

wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY size DESC LIMIT 20;"

見つかったオプションがどのプラグインのものかを確かめ、使っていないものだけを削除します。現役のプラグインの設定を消すと動作がおかしくなるので、削除の前にデータベースのバックアップを取ってください。

投稿のリビジョンが大量にたまっている場合は、wp-config.php で保存数を制限できます。

<?php
// wp-config.php（「編集が必要なのはここまでです」より上に書く）
define( 'WP_POST_REVISIONS', 10 );

この設定は今後の保存に効くもので、既存のリビジョンは消えません。

9. CDN とブラウザキャッシュを使う

画像・CSS・JavaScript のような静的ファイルは、CDN（Cloudflare など）から配信すると、利用者に近い場所から返せるので速くなります。また、静的ファイルに Cache-Control ヘッダーで長めのキャッシュ期間を付けておくと、2回目以降の訪問で再ダウンロードが不要になります。

WordPress は wp_enqueue_script() / wp_enqueue_style() のバージョン引数を URL の ?ver= に付けるので、ファイルを更新したらバージョン番号を上げれば、長いキャッシュ期間でも古いファイルが残り続けることはありません。HTML を CDN でキャッシュする場合は、ページキャッシュと同じくログイン中や管理画面を除外する設定が必要です。

10. WP-Cron と定期処理を見直す

WordPress の予約投稿や定期処理（WP-Cron）は、訪問者のアクセスをきっかけに動きます。アクセスの多いサイトでは無駄に何度も起動し、少ないサイトでは予定どおり動かないことがあります。サーバーの cron が使えるなら、WP-Cron のアクセス起動を止めてサーバー側から定期実行するほうが安定します。

<?php
// wp-config.php
define( 'DISABLE_WP_CRON', true );

# サーバーの crontab（5分ごとに期限が来た予定を実行する例。パスは環境に合わせて変更）
*/5 * * * * cd /path/to/wordpress && wp cron event run --due-now > /dev/null 2>&1

DISABLE_WP_CRON だけを設定してサーバー側の cron を登録し忘れると、予約投稿や自動更新が止まります。設定後は wp cron event list で次回実行時刻が進んでいるかを確認してください。

まとめ

• 対策の前に PageSpeed Insights と Query Monitor で計測し、改善前の値を残す
• 効果が大きいのはページキャッシュ、画像の最適化、PHP の更新。ログイン中のページはオブジェクトキャッシュで補う
• CSS/JavaScript は strategy（WordPress 6.3 以降）で defer を指定し、不要なページでは読み込まない
• autoload オプションやリビジョンを整理し、削除の前にはバックアップを取る
• WP-Cron はサーバーの cron に切り替えると安定する。変更はステージングで試してから本番へ

• レンダリングを妨げるリソースの解消方法
• データベースのインデックスとWP_Queryの高速化