「WordPress 7.1にアップデートしたら、サイトが遅くなった気がする」。2026年8月19日の正式リリース以降、そんな相談や検索が増えています。ただ、「遅くなった気がする」と「本当にWordPress本体が遅くなった」は別の話です。この記事では、WordPress 7.0.4と7.1を同じ環境に新規インストールして表示速度を実測し、そのうえで「更新後に遅くなった」ときに本当に疑うべき原因と切り分け手順を、WordPress専門エンジニアの立場から解説します。
結論から言うと、WordPress 7.1本体は7.0.4に比べて1ページあたり10ms前後（約7〜9%）だけ処理が重くなりましたが、体感できる差ではありません。アップデート後に明らかに遅くなったなら、原因はほぼ本体ではなく、プラグインやテーマの非互換、キャッシュの消失、PHPバージョンなど周辺にあります。
WordPress 7.1にすると遅くなる？先に結論
同じMac・同じPHP・同じテーマ・同じ記事データで、7.0.4と7.1を交互に各30回計測した結果の要点は次の3つです。
- フロントページ・記事ページ・約440ブロックの重いページのいずれも、7.1のほうがサーバー側の処理時間が9〜13ms（7〜9%）長い。ただし絶対値は120〜180msの世界で、人が体感できる差（100ms以上）ではない
- データベースのクエリ数は完全に同じ。ピークメモリは約1.3MB増（35.8MB→37.1MB）
- 差が大きいのは管理画面の投稿編集画面で、HTMLが約93KB増え、サーバー処理は約18ms（約10%）増。編集画面のJavaScript（editor.min.js）は1,024KBから1,540KBへ1.5倍になっており、古いPCでは「管理画面が重くなった」と感じる可能性がある
つまり、「7.1にしたからサイトが遅くなった」はデータ上ほぼ成り立ちません。一方で「編集画面がもっさりした」は一部あり得る、というのが実測から言える範囲です。
WordPress 7.0.4と7.1を同じ条件で実測した結果
検証環境は、Mac上のローカル環境「Local」に Apache＋PHP 8.2.27（OPcache有効）＋MySQL 8.0.35 を用意し、WordPress 7.0.4 と 7.1（いずれも日本語版）を別ディレクトリに新規インストールしたものです。テーマは両方とも Twenty Twenty-Five、プラグインなし。見出し・段落・リスト・カラム・カバー・ボタン・テーブルなどを混ぜた約50ブロックの記事を30本、さらにそれを20倍にした約440ブロック（入れ子含む）の固定ページを1枚、同じ内容で両方に投入しました。
計測は、処理時間・クエリ数・メモリをHTML末尾に出力する小さなmu-pluginを両方に置き、curlでTTFB（最初の1バイトが返るまでの時間）を取得。7.0.4→7.1の順で交互に、ウォームアップ3回のあと各30回ずつ実行し、中央値で比較しています。順序を逆にした10回でも同じ傾向でした。
| ページ | 7.0.4 | 7.1 | 差 |
|---|---|---|---|
| フロントページ（記事10件一覧）TTFB | 164.6ms | 178.0ms | +13.4ms（+8%） |
| 記事ページ（約50ブロック）TTFB | 123.6ms | 132.4ms | +8.8ms（+7%） |
| 重い固定ページ（約440ブロック）TTFB | 135.0ms | 145.4ms | +10.4ms（+8%） |
| 管理画面ダッシュボード TTFB | 116.2ms | 123.2ms | +7.0ms（+6%） |
| 投稿編集画面 TTFB | 170.8ms | 188.5ms | +17.7ms（+10%） |
| DBクエリ数（フロントページ） | 34 | 34 | 同じ |
| ピークメモリ（フロントページ） | 35.8MB | 37.1MB | +1.3MB |
いずれも中央値で、30回の90パーセンタイルも中央値から5〜8ms以内に収まっており、ばらつきはほとんどありません。なお、これはローカルのMac上の数値なので、レンタルサーバーでは絶対値がもっと大きくなります。ただし「差の割合が1割以下」という傾向は変わらないと考えてよいでしょう。
海外のエンジニアがDocker環境で行った同種の検証でも、TTFBの中央値は7.0.4が39ms、7.1が41msで「差はノイズに埋もれる」と報告されています。今回の実測はそれより差がはっきり出ましたが、結論は同じです。
なぜ7.1のほうがわずかに重いのか？
差の内訳を追うために、記事の描画をせず wp-load.php を読み込むだけの「起動時間」を30回ずつ測りました。結果は7.0.4が85.2ms、7.1が89.1msで、起動だけで約4msの差があります。読み込まれるPHPファイル数は473→488と15ファイル増え、この時点でのメモリは32.7MB→34.0MBと約1.3MB増えていました。つまり差の約3分の1は「7.1は読み込むコードが増えた」ことによるもので、残りはブロック描画側の増分です。
本体の容量も、7.0.4の103MBから7.1では126MBへ増えています。増えた23MBのうち22MBは wp-includes/js/dist、つまりブロックエディター用のJavaScriptです。これはフロントの表示速度には影響しませんが、編集画面をブラウザで開いたときの重さには直結します。
一方、7.1の目玉であるレスポンシブスタイル（画面サイズごとの設定）は、使ったブロックにだけメディアクエリ付きのCSSが生成される仕組みです。今回のテストデータではレスポンシブ設定を一切使っていないため、HTMLの増加は1ページあたり約1KB（インラインCSS約1KB増）にとどまりました。設定を多用すればその分だけHTMLは増えますが、表示速度を左右するほどの量にはなりにくいと見ています。
「アップデートしたら遅くなった」の本当の原因は？
本体の差が10ms程度だとすると、「更新したら明らかに遅くなった」ときの原因は別にあります。現場で実際によく当たるのは次のパターンです。
- プラグイン・テーマの非互換：7.1で変わった仕様（jQuery UIの1.14.2への更新、画像処理のブラウザ側への移行など）に追従していないプラグインが、PHPの警告や非推奨エラーを大量に出す。debug.log への書き込みが積み重なると、それだけでページ生成が目に見えて遅くなることがある
- キャッシュの消失：更新のタイミングでページキャッシュやOPcacheがクリアされ、しばらくは全ページが「初回表示」の状態になる。数時間〜1日で落ち着くことが多い
- PHPバージョンが古い：7.1はPHP 7.4でも動きますが、古いPHPのままだと本体の増分が相対的に重く出る。PHP 8.2以上に上げるだけで速くなるケースは多い
- 管理画面側の重さ：編集画面のJavaScriptが1.5倍になった影響で、メモリの少ないPCやタブを大量に開いた状態では編集画面がもたつく。これは「サイトが遅い」ではなく「ブラウザが重い」
- メディアライブラリの無限スクロール：7.1から標準で有効になり、画像が数千枚あるサイトではライブラリを開いたあと読み込みが続く。ユーザープロフィールから従来の表示に戻せます
ここまでのまとめ（サイト運営者の方へ）
WordPress 7.1本体の速度差は実測で1ページあたり約10ms、体感できるレベルではありません。更新後に遅くなったなら、原因はプラグイン・テーマ・キャッシュ・PHPバージョンのどれかである可能性が高く、「本体のせい」と決めつけず周辺から順に切り分ければ特定できます。実は同じ日にプラグインも一括更新していた、というケースも珍しくありません。ここから先は、実際に手を動かして原因を探す方向けの内容です。
技術者向け：遅くなった原因を切り分ける手順
順番が大事です。上から順に試すと、多くの場合は3番目までで原因が見つかります。
- まずTTFBを数値で持つ。ブラウザの体感ではなく、次のコマンドで「今の遅さ」を記録しておきます。何回か実行して中央値を取ってください。
1for i in 1 2 3 4 5; do curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/; done123456yabea@edel ~ % for i in 1 2 3 4 5; do curl -s -o /dev/null -w "%{time_starttransfer}\n" https://edel-hearts.com/; done0.1317880.1126610.1042980.1202610.110677 - Query Monitor で内訳を見る。プラグインを入れて管理バーの表示を開くと、PHP処理時間・クエリ数・遅いクエリ・PHPエラーが一目で分かります。「PHP Errors」に非推奨警告が並んでいれば、そのプラグインが第一容疑者です
- プラグインを一括停止して比較。Health Check & Troubleshooting のトラブルシューティングモードを使えば、訪問者に影響を与えずに自分のブラウザだけプラグイン全停止の状態を作れます。ここで速くなれば、1つずつ有効化して犯人を絞り込みます
- debug.log の肥大化を確認。wp-content/debug.log が数十MBになっていたら、それ自体が遅さの原因です。原因のプラグインを直すか、本番では WP_DEBUG_LOG を無効にします
- PHPバージョンとOPcacheを確認。サイトヘルス（ツール→サイトヘルス→情報→サーバー）でPHPのバージョンとOPcacheの有無を確認。PHP 8.2以上・OPcache有効が目安です
- フロントと管理画面を分けて測る。フロントは速いのに管理画面だけ遅いなら、原因は編集画面のJavaScript側やブラウザ拡張の可能性が高く、サーバー側の対策では直りません
遅くなったときの対処法と、アップデートのタイミング
原因がプラグインなら、そのプラグインの更新を待つか代替に切り替えます。原因が特定できず、かつ売上に直結するサイトであれば、アップデート前のバックアップから戻して7.0.4で様子を見るのも現実的な選択です。7.0.4は7.0系の最新版で、本体側のセキュリティ修正は当面続きます。
実は、当社のサイト edel-hearts.com も2026年9月7日の時点ではまだ7.0系のままです。管理画面には「7.1が利用可能です」の通知が出ていますが、メジャーアップデートは公開後7週間程度は様子を見るのが当社の基本方針で、これは今回に限った話ではありません。セキュリティ更新（7.0.2や7.0.4のようなマイナー版）は即日適用し、メジャー版は周辺プラグインの追従と最初の修正版を待つ、という使い分けです。
WordPress 7.1では、7.1で入った不具合を修正するだけの7.1.1が2026年9月17日に公開予定（RC1は9月10日）で、新機能の追加はありません。急ぐ理由がなければ、7.1.1が出てから、バックアップを取ったうえでステージング環境で確認し、本番へ、という順番をおすすめします。更新の手順そのものは「安全なWordPressアップデート手順」に、7.1で何が変わったかは「WordPress 7.1の新機能解説」にまとめています。
なお、更新とは関係なく元々遅いサイトは、7.1にしても7.0.4に戻しても変わりません。画像の最適化やキャッシュ設定など根本の改善は「WordPressの表示速度を改善する方法」を参考にしてください。
まとめ：WordPress 7.1が遅いのではなく、周辺の変化を疑う
同一環境の実測では、WordPress 7.1と7.0.4の差は1ページあたり約10ms、クエリ数は同じ、メモリは1.3MB増でした。「アップデートで遅くなった」と感じたら、本体ではなくプラグイン・テーマの非互換、キャッシュの消失、PHPバージョン、そして管理画面のJavaScript増加を順に疑ってください。切り分けの手順はQuery Monitor→プラグイン全停止→debug.log→PHP環境の順です。
「原因を探す時間がない」「更新のたびに不安になる」という方は、当社のWordPress保守サポートをご検討ください。毎日7世代のバックアップを取り、問題が起きたときだけご報告する運用なので、アップデートを任せたまま本業に集中できます。すでに遅くなって困っている場合はトラブル対応サービスで原因特定から復旧まで対応します。まずは無料AI診断で現状のサイトをチェックするか、お問い合わせから状況をお知らせください。
この記事を書いた人
矢部 敦合同会社Edel Hearts 代表
WordPress専門の開発会社を経営。プラグイン開発・カスタマイズ・保守を専門とし、18時間におよぶUdemyのWordPress講座を開講。出典付きで回答するAIチャットボット「Edel AI Hybrid Chat」開発者。本ブログの記事は、実際の開発・運用で得た一次情報をもとに執筆しています。会社情報はこちら
