WordPressが急に重くなった原因は「1ページ表示でRESTが十数回走る実装」だった（原因特定〜改善まで）

※この記事内の一部リンクにはアフィリエイトリンク（PR）が含まれます。

はじめに：症状は「重い」と「アクセスが増えたように見える」

あるWordPressサイトが、ある時期から急に重くなりました。体感だけでなく、計測でもページ表示に数秒〜十数秒かかることが増え、同時にアクセス解析（または負荷ランキング）の数字が「不自然に増える」ように見える現象も出ました。

具体的には、スマホで同じページを**1回更新しただけなのに、ヒット数が+1ではなく+13〜+14**のように増えてしまうことがありました。
最初は「ボット？」「マルウェア？」「不正アクセス？」と疑いましたが、結論は別のところにありました。

結論：アクセスが増えたのではなく「裏で追加リクエストが増えていた」

今回のポイントはここです。

> **アクセスが13倍に増えたのではなく、1回のページ表示の中で“裏リクエスト”が十数本追加で出ていた**

アクセス解析や負荷計測は「PHPに届いたリクエスト数」をカウントすることが多いため、裏でRESTが大量に走ると、見かけのアクセスも増えたように見えます。

—

## まずやったこと：1回の更新で“何本リクエストが発生しているか”を見える化
原因の切り分けで重要なのはこれです。

> **「ブラウザが1回のページ表示で、実際に何本HTTPリクエストを追加で出しているか」**

私は管理画面側に、簡易的な「リクエスト記録→集計表示」画面（いわゆる“トレース”）を用意し、次の手順で確認しました。

1. 記録ログを全削除
2. スマホで対象ページを**1回だけ**更新
3. 記録されたリクエスト一覧を、**Referer（参照元URL）**で絞り込み
4. `/wp-json/…` や `/admin-ajax.php` が何本出ているか数える

この時点で、「1回更新で+13〜+14」という体感の正体が見えてきます。

判明したこと：ページ表示の裏で WordPress REST API が十数回呼ばれていた

ログを見ると、単にページHTMLを1回取りに行っているだけではなく、ページ表示の直後に **WordPress REST API が連続で呼ばれている**ことが分かりました。

代表的には次のようなリクエストが短時間に多発します。

– `GET /wp-json/wp/v2/posts/{ID}?_fields=date` が大量に発生
– Referer（参照元）がトップページ `/` になっているものが多い

つまり「記事ページで重い」のではなく、トップページ等の**一覧表示**で何かが追加通信している可能性が高い、と当たりがつきます。

次の切り分け：どのページがトリガーになっているか

REST連打の参照元（Referer）を見ていくと、トリガーが **記事ページではなくトップページ `/`** になっていることが分かりました。
この段階で原因候補はかなり絞れます。

よくあるのは、トップページ内の「記事一覧」「人気記事」「ランキング」「スライダー」などのウィジェットが、表示後に追加処理をしているパターンです。

決定打：ページソース検索で “dateだけ取りに行く処理” を発見

最後はフロント側（HTML/JS）を確認しました。

トップページのページソースを開いて、次の文字列で検索します。

– `_fields=date`
– `wp-json/wp/v2/posts`
– `fetch(`

すると、**記事IDごとに投稿日（date）を取りに行く処理**が見つかりました。
しかも1箇所ではなく、複数のブロック（例：通常一覧、人気記事、スライダー）で似た処理が存在しており、状況によっては同じ記事IDに対して重複して呼ばれる可能性もあります。

この時点で結論は明確です。

> ページが重かった原因は、特定のフロントJSが「記事ごとに REST API を呼ぶ」設計になっていたこと

なぜ重くなるのか：「1記事=1リクエスト」の積み上げ

例えばトップページに13件のカードがあり、各カードの「投稿日判定」のためにRESTを1回叩く実装だと、ページ表示だけで

– HTML本体：1回
– REST：13回（＋場合によっては追加）
– 合計：十数回

となります。

さらに、1本あたりの処理が重い場合、体感速度は一気に悪化します。
そして「PHPに届くリクエスト数」も増えるため、解析上“アクセスが増えた”ように見えることがあります。

解決方針：REST連打をやめる（またはバッチ化する）

解決の方針はシンプルです。

1) `<time datetime>` があるなら、それを使って判定（通信ゼロ）

記事一覧に日付情報がHTMLとして出ているなら、JSはそれを読むだけで “NEW” を判定できます。通信は不要です。

2) `<time>` が無い場合でも「記事ごとにREST」はしない

どうしても日付がHTMLに無いウィジェットがある場合は、

– 必要な記事IDを集めて
– **1回のバッチ問い合わせ**でまとめて判定結果を返す

方式にします。

例：
– `include=…&_fields=id,date` でまとめ取得
– または `admin-ajax.php` でID一覧を送ってサーバ側でまとめ判定して返す

これで「1ページでRESTが十数回」が「ほぼ1回」に落ちます。

結果：表示が軽くなり、カウントも正常化

原因のJS処理を停止・修正したところ、

– ページ表示が目に見えて軽くなり
– 1回更新あたりのヒット増分も、想定に近い形へ戻りました

「感染」や「攻撃」を疑って時間を使う前に、**“1表示で何本リクエストが出ているか”**を見える化したのが、結果的に最短ルートでした。

同じ症状の人へ：再現性の高いチェックリスト

もしあなたのサイトでも

– 急に重い
– アクセスが不自然に増えたように見える
– REST API のアクセスが多い気がする

という時は、次の順で見てみてください。

1. 1回のページ更新で発生しているリクエスト数を確認（ログ/トレース）
2. RESTが増えているなら Referer でトリガーページを特定
3. ページソースで `wp-json` / `_fields=` / `fetch(` を検索
4. “1記事=1リクエスト” になっていたらバッチ化 or サーバ側に寄せる

おわりに：原因は「便利機能」の実装方式だった

今回の学びは、「便利なフロント機能ほど、裏で何本通信しているかを意識しないと簡単に重くなる」ということです。

特に “一覧にラベルを付ける” “人気記事にNEWを付ける” といった処理は、実装次第で **ページに表示される件数分だけリクエストが増える**落とし穴があります。

今後は「通信ゼロ」「バッチ1回」を基本方針にして、必要な情報はなるべくHTML側に持たせる設計にしていきます。