2026.10.26 開発

WordPressの高速化手順：原因の切り分けとキャッシュ・DB・画像の改善【7.1系対応】

WordPressの高速化は、プラグインを入れる前に「どこで時間を使っているか」を測ると、打つ手が2〜3個に絞れます。サーバーがHTMLを返すまでが遅いのか、画像の読み込みが遅いのかで、効く施策がまったく違うためです。本記事では、curlとQuery Monitorで遅さの原因を切り分ける手順から、ページキャッシュ、OPcacheとRedisのオブジェクトキャッシュ、WordPress 6.6で変わった自動読み込みオプションの整理、LCP画像の優先読み込みまでを、コマンドと設定例付きで解説します。情報は2026年10月26日時点（WordPress 7.1.3）のものです。

まとめ：WordPressの高速化はTTFBとLCP画像を測ってから手を打つ

最初に、ログアウトした状態でHTMLの最初の1バイトが届くまでの時間（TTFB）を測ります。TTFBが長ければサーバー側の問題です。ページキャッシュ、OPcache、オブジェクトキャッシュ、データベースの整理の順に手を打ちます。

TTFBが短いのに表示が遅い場合は、画面で一番大きい画像（LCP画像）の読み込みが原因です。遅延読み込みを外し、優先読み込みを付けるだけで改善する例が多くあります。高速化プラグインを何本も重ねる対策はおすすめしません。キャッシュ同士が衝突して、表示が崩れる原因にもなります。

WordPressが遅い原因の切り分け：TTFBとLCPの内訳で効く施策を決める

指標の定義と計測ツールの使い方はCore Web Vitalsの基準値と測り方で扱っています。ここでは、測った値からWordPressのどこを直すかを決める手順に絞ります。

LCPの4つの内訳とTTFBが40%を超えたときに疑うサーバー側の処理

web.devのLCPの改善ガイドは、LCPを4つの内訳に分けて考えるよう勧めています。LCPの良好な基準は2.5秒以下です。

内訳	目安の比率	WordPressで疑う箇所
TTFB	約40%	PHPの処理・DBの問い合わせ・キャッシュ未設定
リソース読み込み遅延	10%未満	LCP画像の遅延読み込み・CSS背景画像
リソース読み込み時間	約40%	画像の容量・形式・配信元
要素描画遅延	10%未満	読み込みを止めるCSSとJavaScript

WordPressで多いのは、TTFBだけで1秒を超える状態です。ガイドも、TTFBが長いと2.5秒の達成は難しいと書いています。この場合、画像を圧縮しても体感はほとんど変わりません。

curlの計測値とQuery Monitorで遅いプラグインとクエリを特定する手順

TTFBは、手元のcurlで5回ほど測ると傾向がつかめます。初回だけ遅く2回目以降が速いなら、キャッシュは効いています。毎回遅いなら、キャッシュが無いか、効いていません。

# ログアウト状態のトップページを5回測る（TTFB=time_starttransfer）
for i in 1 2 3 4 5; do
  curl -s -o /dev/null -H "Cache-Control: no-cache" \
    -w "TTFB %{time_starttransfer}s  合計 %{time_total}s  HTTP %{http_code}\n" \
    "https://example.com/"
done

# 応答ヘッダーでキャッシュの当たり外れを確かめる（ヘッダー名はキャッシュの仕組みで異なる）
curl -s -D - -o /dev/null "https://example.com/" | grep -i -E "x-cache|cache-control|age"

example.comは自社のURLに置き換えます。サーバー側で時間を使っていると分かったら、Query Monitor（4.1系・2026年10月26日時点）を検証環境に入れます。データベースへの問い合わせを、原因のプラグインやテーマごとに集計してくれるツールです。遅い問い合わせと重複した問い合わせも警告します。1画面で数百件の問い合わせを出すプラグインが見つかれば、それが最初の対処先です。

ページキャッシュの導入：プラグイン方式とnginxのfastcgi_cacheの使い分け

TTFBを最も大きく縮めるのは、PHPを動かさずに作り置きのHTMLを返すページキャッシュです。WordPressの公式の運用資料も、静的なページなら数百倍の改善があり得ると書いています。

WP Super Cacheなどのプラグインで匿名アクセスをHTML配信にする設定

レンタルサーバーでは、キャッシュプラグインを1本だけ入れます。公式資料が例に挙げるのは、W3 Total Cache、WP Super Cache、Cache Enablerです。サーバー会社が独自のキャッシュ機能を用意している場合は、そちらを優先し、プラグインと二重にしません。

設定で確かめる点は2つです。ログイン中のユーザーにキャッシュを返さないこと。記事の更新時に、そのページと一覧ページのキャッシュが消えることです。導入後は前章のcurlで2回目以降のTTFBが縮んだかを測り、効いたことを数値で残します。

VPSでnginxのfastcgi_cacheを使いログイン中とPOSTを除外する設定例

VPSや自社サーバーでnginxを使っているなら、nginxのfastcgiモジュールのキャッシュ機能が使えます。WordPressの外側で動くため、プラグインより確実にPHPを止められます。

# http ブロック：キャッシュの置き場所と鍵を定義する
fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WP:64m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# server ブロック：キャッシュしない条件をまとめる
set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "")    { set $skip_cache 1; }
if ($request_uri ~* "/wp-admin/|/wp-login\.php|/cart/|/checkout/|/my-account/") { set $skip_cache 1; }
if ($http_cookie ~* "wordpress_logged_in_|comment_author_|wp-postpass_|woocommerce_items_in_cart") { set $skip_cache 1; }

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;

    fastcgi_cache WP;
    fastcgi_cache_valid 200 301 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    add_header X-Cache $upstream_cache_status;
}

X-CacheがHITなら作り置きのHTMLが返っています。ソケットのパスと除外するURLは、利用環境に合わせた変更が必要です。この方式は記事を更新してもキャッシュが自動では消えないため、保存期間を10分程度に短くするか、更新時に該当ファイルを消す仕組みを別に用意します。

キャッシュが効かないEC・会員サイトのページと除外の判断基準

カート、決済、マイページ、会員限定ページは、利用者ごとに中身が違うためキャッシュできません。誤ってキャッシュすると、別の利用者の情報が表示される事故になります。高速化より先に避けるべき失敗です。

判断の基準は「ログアウトした全員に同じHTMLを返してよいか」です。返してよいページだけをキャッシュします。会員サイトのように大半のページがログイン後に表示される構成では、ページキャッシュの効果は小さくなります。この場合は次章のオブジェクトキャッシュとデータベースの整理が主な手段です。

PHP実行の高速化：OPcacheの設定値と永続オブジェクトキャッシュRedisの導入

ページキャッシュを通らないアクセスでは、PHPの実行そのものを速くします。手を付ける順番は、OPcache、PHPの版、オブジェクトキャッシュです。

OPcacheの既定値128MBと本番のWordPressで見直す設定値の目安

OPcacheは、PHPのコードを解析した結果をメモリに置いて再利用する仕組みです。PHPマニュアルの設定一覧の既定値は、メモリ128MB、保持できるファイル数10,000です。プラグインの多いWordPressでは、ファイル数の上限に先に届きやすくなります。

; php.ini（またはconf.dの追加設定）の例。既定値はコメントに記載
opcache.enable=1
opcache.memory_consumption=256        ; 既定 128（MB）
opcache.interned_strings_buffer=16    ; 既定 8（MB）
opcache.max_accelerated_files=20000   ; 既定 10000
opcache.validate_timestamps=1         ; 既定 1。0にすると更新の反映に再起動が必要
opcache.revalidate_freq=60            ; 既定 2（秒）。ファイル更新を確かめる間隔

値は出発点の例です。設定後はopcache_get_status()のcache_fullとopcache_hit_rateを、Webサーバー経由のPHPで確かめます。コマンドラインのPHPは既定でOPcacheが無効なので、そこで見ても値は取れません。PHP自体の版上げも処理速度に効きますが、互換性の確認が要ります。手順はWordPressのPHPバージョンアップ手順にまとめています。

Redis Object Cacheでデータベースへの問い合わせを減らす設定手順

WordPressには取得したデータを使い回すオブジェクトキャッシュがあります。ただし開発者向け資料のとおり、既定での保存期間は1回のリクエストが終わるまでです。Redis Object Cache（3.0系・2026年10月時点）を使うと、この中身をRedisに保存し、次のリクエストでも使えます。

// wp-config.php：「That's all, stop editing!」の行より上に書く
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );            // 0〜15。サイトごとに分ける
define( 'WP_REDIS_PREFIX', 'corp-site' );    // 同じRedisを共有するときの識別子
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

# プラグインを入れて有効化し、接続を確かめる
wp plugin install redis-cache --activate
wp redis enable
wp redis status

定数と手順は配布元の導入手順に沿っています。Redisサーバーが使えないレンタルサーバーでは導入できません。効果が大きいのは、ログイン後の画面が多い会員サイトや管理画面の操作です。前章のページキャッシュが効くサイトでは、差が小さく出ることもあります。

データベースの肥大化対策：自動読み込みオプションとトランジェントの整理

WordPressは、すべてのリクエストの最初に「自動読み込み」の印が付いた設定値をまとめて読み込みます。削除したプラグインの設定が残ると、この量が膨らみ、TTFBが伸びます。

WordPress 6.6で変わった自動読み込みの判定と800KBの警告基準

WordPress 6.6で、自動読み込みの扱いが変わりました。コア開発チームの告知によると、印の値はon・off・auto・auto-on・auto-offの5種類になりました。明示のない150,000バイトを超える設定値は、自動読み込みの対象から外れます。

同じ版で、サイトヘルスに検査が加わりました。自動読み込みの合計が800KBを超えると、重大な問題として表示されます。ただし、6.6より前に保存された古い値はyesのまま残っています。長く運用しているサイトほど、この警告に当たりやすい構造です。

WP-CLIで自動読み込みの合計サイズと大きい設定値を洗い出すコマンド

合計と内訳はWP-CLIのoption listで出せます。内訳はコア開発チームの告知が自動読み込みとして扱う4つの値（yes・on・auto-on・auto）を、wp db queryで直接数えます。

# 自動読み込みの合計バイト数（800000を超えるとサイトヘルスで警告）
wp option list --autoload=on --format=total_bytes

# 大きい順に20件。接頭辞から、どのプラグインの設定かを判断する
wp db query "SELECT option_name, LENGTH(option_value) AS bytes, autoload
  FROM $(wp db prefix)options
  WHERE autoload IN ('yes','on','auto-on','auto')
  ORDER BY bytes DESC LIMIT 20;"

# 削除済みプラグインの設定だと確かめたものだけ、自動読み込みを外す
wp option set-autoload old_plugin_settings off

old_plugin_settingsは実際の設定名に置き換えます。set-autoloadを使えるのはWP-CLI 2.8.0以降です。稼働中のプラグインの設定を外すと、そのプラグインが動かなくなるおそれがあります。作業前にWordPressのバックアップを取ってください。

期限切れトランジェントと投稿リビジョンを削除するときの手順と注意点

トランジェントは、プラグインが外部APIの結果などを期限付きで保存する仕組みです。オブジェクトキャッシュが無いサイトでは、設定値と同じ表にたまります。wp transient deleteで期限切れの分だけ消せます。

# 期限切れのトランジェントだけを削除する（--allは使わない）
wp transient delete --expired

# 投稿リビジョンの件数を確かめる
wp post list --post_type=revision --format=count

--allは期限内の値まで消すため、直後の表示が一時的に遅くなります。リビジョンが数万件ある場合は、wp-config.phpにdefine( 'WP_POST_REVISIONS', 10 );を書いて今後の増加を止めます。過去分の削除に進む前には、DBのバックアップが必要です。

画像とフロントエンドの改善：LCP画像の優先読み込みと投機的読み込みの設定

TTFBが短いのに表示が遅いサイトは、ブラウザ側に原因があります。WordPress本体が備える読み込み効率の改善処理を、テーマが打ち消していないかを先に確かめます。

WordPress 6.3のfetchpriority自動付与とテーマ構造で無効になる例

WordPress 6.3以降は、LCPになりそうな画像にfetchpriority="high"を自動で付けます。6.3の告知では、LCPを5〜10%縮める見込みとされています。先頭から3枚の画像は遅延読み込みの対象から外す既定値（wp_omit_loading_attr_threshold）も同じ版からです。

効かなくなるのは、メイン画像をCSSの背景画像で出すテーマや、JavaScriptで画像を差し込むスライダーです。WordPressが画像タグとして認識できないため、優先読み込みが付きません。ブラウザの開発者ツールでLCP要素を確かめ、背景画像ならimgタグへの置き換えを検討します。web.devのガイドも、LCP画像を遅延読み込みにしないよう明記しています。

WordPress 6.8の投機的読み込みの既定値と設定を変えるフィルター

WordPress 6.8から、リンク先のページを事前に読み込む投機的読み込みが既定で有効です。6.8の告知では、既定はprefetch（HTMLだけ先に取得）とconservative（クリックし始めた時点で開始）です。ログイン中のユーザーと、クエリ付きのURLは対象に含まれません。

<?php
// テーマのfunctions.phpなどに追加する。リンクに触れた時点で描画まで先に済ませる
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

// 先読みすると困るページを外す（カートなど）
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths ) {
	$paths[] = '/cart/*';
	return $paths;
} );

先読みの幅を広げると、閲覧されないページの分もサーバーに負荷がかかります。ページキャッシュが効いていないサイトでは、広げずに既定のまま使います。

画像の圧縮・WebP変換とCSS・JavaScriptの結合を入れる順番と確認

画像の圧縮とWebP変換は、LCPの内訳で「リソース読み込み時間」が長い場合に効きます。CSSとJavaScriptの結合や遅延実行は、「要素描画遅延」が長い場合の手段です。後者は表示崩れやフォームの不具合を起こしやすいので、1項目ずつ有効にし、問い合わせフォームの送信まで確かめます。

外部のチャットや広告タグは、結合の対象から外します。実際の利用者の体感を継続して見たい場合は、Datadog RUMのような実測の仕組みを入れる選択肢もあります。

高速化プラグインを足すか構成を変えるか：自社対応と保守委託の判断基準

ここまでの手順を、どこまで自社で進めるかを決めます。条件を示したうえで結論を書きます。

プラグインの追加で止めるべきサイトとサーバー構成から見直すべきサイト

プラグインの追加で止めてよいのは、ページキャッシュを入れた後、ログアウト状態のTTFBが0.5秒程度に収まるサイトです。残る課題は画像とCSSの調整なので、本記事の手順で足ります。

構成から見直すべきなのは、キャッシュが効かないページが大半の会員サイトやECサイト、Query Monitorで1画面数百件の問い合わせが出るサイトです。プラグインを重ねても、PHPとDBの処理量は減りません。サーバーの増強、Redisの導入、問い合わせの多いプラグインの置き換えか改修が必要です。表示する内容が更新の少ない広報サイトなら、WordPressからCloudflare EmDashのような配信型のCMSへ移す選択肢も検討に入ります。

自社で高速化を進められる条件と保守会社に任せた方が早いサイト構成

自社で進められるのは、管理画面とWP-CLIを操作でき、検証環境で設定を試せるサイトです。キャッシュプラグインの導入とautoloadの整理なら、1〜2日で効果を測るところまで進められます。

任せた方が早いのは、独自開発のテーマやプラグインが遅さの原因になっている、サーバーの設定を変える権限が社内に無い、のどちらかに当たるサイトです。問い合わせの多い処理を書き換えるには、PHPとSQLの改修が必要です。一創のWordPress保守・メンテナンスでは、遅さの原因調査からキャッシュの設計、独自コードの改修、改善後の監視までを請け負っています。保守を内製と外注のどちらで持つかはWordPress保守運用の作業範囲と内製か外注かの判断基準で整理しています。

WordPressの高速化に関するプラグイン選定と運用のよくある質問と回答

WordPressの高速化について、サイト運用の担当者から寄せられやすい質問に答えます。

WordPressの高速化プラグインはどれを入れればよいですか？

まず、サーバー会社が独自のキャッシュ機能を用意しているかを確かめます。用意されていればそれを使い、無ければキャッシュプラグインを1本だけ選びます。公式の運用資料が例に挙げるのはW3 Total Cache、WP Super Cache、Cache Enablerです。画像圧縮やCSSの結合を含む多機能なプラグインは、キャッシュを入れて測った後、画像やCSSに課題が残った場合に追加します。

キャッシュプラグインを複数入れると速くなりますか？

速くなりません。ページキャッシュの仕組みは1つのサイトに1つしか働かず、複数入れると同じページを二重に作ったり、更新時の削除が片方だけで終わったりします。古い表示が残る、管理画面が崩れるといった不具合を招く原因です。サーバー会社のキャッシュとプラグインのキャッシュの併用も同じで、どちらか一方に寄せます。

WordPressが急に重くなった場合はまず何を確認すべきですか？

最初の確認対象は、直前に入れたり更新したりしたプラグインです。検証環境でそのプラグインを止め、TTFBが戻るかを測ると原因を絞れます。変更に心当たりが無い場合に見るのは、自動読み込みの合計サイズと、サーバーのCPUとメモリの使用率です。不正なアクセスの急増でも重くなるため、アクセスログで特定のURLへの集中が無いかも見ます。

レンタルサーバーのままでもWordPressを高速化できますか？

できます。サーバー会社のキャッシュ機能、PHPの版上げ、autoloadとトランジェントの整理、LCP画像の調整は、レンタルサーバーでも行えます。OPcacheの細かい設定やRedisの導入、nginxのキャッシュ設定は、サーバー会社が提供していない限り使えません。これらが必要なほど処理が重いサイトは、VPSやマネージドサーバーへの移行を検討します。