--- title: "WordPressの高速化手順：原因の切り分けとキャッシュ・DB・画像の改善【7.1系対応】" url: "https://www.issoh.co.jp/tech/details/18959/" published: 2026-10-26 updated: 2026-10-26 categories: ["開発"] publisher: "株式会社一創" --- # 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の基準値と測り方](https://www.issoh.co.jp/tech/details/18645/)で扱っています。ここでは、測った値からWordPressのどこを直すかを決める手順に絞ります。 ### LCPの4つの内訳とTTFBが40%を超えたときに疑うサーバー側の処理 web.devの[LCPの改善ガイド](https://web.dev/articles/optimize-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](https://wordpress.org/plugins/query-monitor/)（4.1系・2026年10月26日時点）を検証環境に入れます。データベースへの問い合わせを、原因のプラグインやテーマごとに集計してくれるツールです。遅い問い合わせと重複した問い合わせも警告します。1画面で数百件の問い合わせを出すプラグインが見つかれば、それが最初の対処先です。 ## ページキャッシュの導入：プラグイン方式とnginxのfastcgi\_cacheの使い分け TTFBを最も大きく縮めるのは、PHPを動かさずに作り置きのHTMLを返すページキャッシュです。WordPressの[公式の運用資料](https://developer.wordpress.org/advanced-administration/performance/cache/)も、静的なページなら数百倍の改善があり得ると書いています。 ### 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モジュール](https://nginx.org/en/docs/http/ngx%5Fhttp%5Ffastcgi%5Fmodule.html)のキャッシュ機能が使えます。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マニュアルの設定一覧](https://www.php.net/manual/ja/opcache.configuration.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バージョンアップ手順](https://www.issoh.co.jp/tech/details/18957/)にまとめています。 ### Redis Object Cacheでデータベースへの問い合わせを減らす設定手順 WordPressには取得したデータを使い回すオブジェクトキャッシュがあります。ただし[開発者向け資料](https://developer.wordpress.org/reference/classes/wp%5Fobject%5Fcache/)のとおり、既定での保存期間は1回のリクエストが終わるまでです。[Redis Object Cache](https://wordpress.org/plugins/redis-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 ``` 定数と手順は[配布元の導入手順](https://github.com/rhubarbgroup/redis-cache/blob/develop/INSTALL.md)に沿っています。Redisサーバーが使えないレンタルサーバーでは導入できません。効果が大きいのは、ログイン後の画面が多い会員サイトや管理画面の操作です。前章のページキャッシュが効くサイトでは、差が小さく出ることもあります。 ## データベースの肥大化対策：自動読み込みオプションとトランジェントの整理 WordPressは、すべてのリクエストの最初に「自動読み込み」の印が付いた設定値をまとめて読み込みます。削除したプラグインの設定が残ると、この量が膨らみ、TTFBが伸びます。 ### WordPress 6.6で変わった自動読み込みの判定と800KBの警告基準 WordPress 6.6で、自動読み込みの扱いが変わりました。[コア開発チームの告知](https://make.wordpress.org/core/2024/06/18/options-api-disabling-autoload-for-large-options/)によると、印の値は`on`・`off`・`auto`・`auto-on`・`auto-off`の5種類になりました。明示のない150,000バイトを超える設定値は、自動読み込みの対象から外れます。 同じ版で、サイトヘルスに検査が加わりました。自動読み込みの合計が800KBを超えると、重大な問題として表示されます。ただし、6.6より前に保存された古い値は`yes`のまま残っています。長く運用しているサイトほど、この警告に当たりやすい構造です。 ### WP-CLIで自動読み込みの合計サイズと大きい設定値を洗い出すコマンド 合計と内訳は[WP-CLIのoption list](https://developer.wordpress.org/cli/commands/option/list/)で出せます。内訳はコア開発チームの告知が自動読み込みとして扱う4つの値（yes・on・auto-on・auto）を、[wp db query](https://developer.wordpress.org/cli/commands/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](https://developer.wordpress.org/cli/commands/option/set-autoload/)を使えるのはWP-CLI 2.8.0以降です。稼働中のプラグインの設定を外すと、そのプラグインが動かなくなるおそれがあります。作業前に[WordPressのバックアップ](https://www.issoh.co.jp/tech/details/18612/)を取ってください。 ### 期限切れトランジェントと投稿リビジョンを削除するときの手順と注意点 トランジェントは、プラグインが外部APIの結果などを期限付きで保存する仕組みです。オブジェクトキャッシュが無いサイトでは、設定値と同じ表にたまります。[wp transient delete](https://developer.wordpress.org/cli/commands/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の告知](https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-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の告知](https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/)では、既定は`prefetch`（HTMLだけ先に取得）と`conservative`（クリックし始めた時点で開始）です。ログイン中のユーザーと、クエリ付きのURLは対象に含まれません。 ``` )（株式会社一創）