はじめに：症状は「重い」と「アクセスが増えたように見える」
ある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側に持たせる設計にしていきます。
よくある不具合・機能追加・プラグインの限界を相談室で探せます。自分の環境だけで起きる場合は個別相談も可能です。
