WordPress Heartbeatとは？バックエンドの速度低下とCPUスパイクの説明

ワードプレスのバックエンドに表示されるラグ、異常に高いCPU使用率、admin-ajax.phpリクエストの急増そのとき、多くのウェブマスターはあるフレーズを勧められる：

そのハートビートをオフにしてみてください。"

まだハートビートとは一体何なのか？?
なぜバックグラウンドが遅くなるのですか？
それ本当にCPUスパイクが原因か、それとも単なる見当違いか？生贄"?

I. ハートビートとは？一文で何をしているのかを説明する

ハートビート は、WordPress 組み込みのバックグラウンド・ハートビート・メカニズムその本質は

ページをリフレッシュすることなく、バックエンドページを表示する。一定間隔でサーバーにAJAXリクエストを送信する。これは状態を同期させるために使われる。

これらのリクエストは主に admin-ajax.php 送信された場合、デフォルトの頻度は

15～60秒ごと
背景ページを開く≠アイドル
ページが存在する限り、ハートビートは "ジャンプ "している。

ハートビートの中核的役割（冗長ではない）

多くの人の最初の反応はこうだ：

"資源の無駄遣いのようだ"

しかし、実際には、『ハートビート』は複数のバックオフィス主要機能.

オートセーブ

記事を書いたり、ページを変えたりするとき：

WordPressは定期的に下書きを保存する
ブラウザのクラッシュ、切断、誤終了を防ぐ

これはハートビートの提供である。

編集ロック（投稿ロック）

複数の人間が協力する場合：

A 編集中の記事
B 同じ記事を開く
システムは "他のユーザーが編集中です "と言う。

また、ハートビートも同期状態にある。

ログイン状態の検出

ハートビートは定期的に確認する：

ログインはまだ有効ですか？
権限を再確認する必要があるかどうか

そうでないと、バックグラウンドでいろいろなことを操作しているうちに、一日の終わりには「オフライン」になっていることに気づくかもしれない。

リアルタイムのバックエンド機能を持つプラグイン／テーマ

以下を含むがこれらに限定されない：

注文状況の更新
セキュリティ・プラグイン・リスク管理
エディター・リアルタイム・キャリブレーション

特に WooCommerce のサイトでは、この種の依存関係がより頻繁に発生することになる。

なぜバックグラウンドが遅くなり、CPUが急上昇するのですか？

ここからがポイントだ：
心臓の鼓動そのものは重くない。

問題は「ジャンプ」ではなく、「一度にたくさんのことをする」ことだ。

すべてのハートビート要求：

入り込む admin-ajax.php
WordPressコアの読み込み
マウントされたアクション／フックを実行する
「プラグインによる「傍受と処理

あなたのサイトが以下の条件を満たしている場合
CPUのスパイクは非常に起こりやすい。

CPUが高騰している5つの本当の理由

バックグラウンドで複数のタブを同時に開く

これは最も一般的だが、最も見過ごされている症状::

1バックエンドページ＝1ハートビート
5タブ＝5倍のリクエスト
さらに複数の管理者が同時にオンライン

鼓動は直接スタックする。

ハートビートでプラグインが「機能」する

多くのプラグインがこれを行う：

"ハートビートは定期的にトリガーを引くので、その間に何かをチェックする"

例えば、こうだ：

セキュリティプラグインスキャンステータス
統計プラグインジャーナリング
モールプラグインオーダーの同期化
エディタ構造データの保存

その結果だ：1つのハートビート＝複数の複雑なSQLクエリ

admin-ajax.php自体がすでにパフォーマンスのボトルネックになっている。

サーバー環境によっては

admin-ajax.php キャッシュが有効になっていません。
PHP-FPM プロセス数の制限
データベースのレスポンスが遅い

ハートビートは、処理能力が不十分なままドアをノックし続けている。

バックエンドのエディター自体が "重い"。

ブロックエディター、ページビルダーを使用する場合：

すべてのハートビートにはデータ比較が伴う。
複雑なJSON構造
自動リビジョン・スタッキング

CPU使用率が段階的に上昇している。

サーバー設定がバックエンドに不親切

よく見かける：

ロープロファイルVPS
ウェブホスティング
バックオフィスとフロントオフィスのリソース共有

ハートビートは既存のパフォーマンス問題を増幅させる。

V. 重要な認知の誤解：ハートビート≠CPU問題出典

非常に重要なポイントだ：

ハートビートは "トリガー "であって、"メーカー "ではない。

まさにその通りだ：

タイムシグネチャーのリクエスト
単一のエントリー・ポイントを提供する

CPUを本当に消費するのは、通常

プラグイン実装関数
データベースクエリ
ログ書き込み
安全校正

だから、ある現象を目にすることになる：

ハートビートと同じだ。
A 現場は問題ない。
BサイトダイレクトCPU 100%.

VI.どのように見分けるか：あなたの質問はハートビートかどうか？

迅速判定法（設定変更なし）

これら3つのシグナルを観察することができる：

CPUスパイクがバックエンドへのログイン後にのみ発生するかどうか
バックグラウンドのページを閉じると、CPUが急激に低下しますか？
admin-ajax.phpはサーバーログに大きく表示されますか？

この3つが同時に成立する場合
心臓の鼓動が関係している可能性が高い。

ただし、参加≠犯人であることに注意

正しい質問はそうではない：

「ハートビートを切るべきか？

その代わりだ：

"ハートビートが発動すると本当は何が起こるのか？"

ハートビートの全面停止」が危険な理由

多くのチュートリアルはこれを直接示唆している：

"バックグラウンドでハートビートをすべて無効にする"

これは以下のシナリオで行われる。非常にお勧めできない::

複数著者のサイト
モールバックオフィス
長いエッセイを頻繁に書く
オンラインエディターの使用

考えられる結果は以下の通り：

オートセーブの失敗
プロンプトなしでコンフリクトを編集する
ログイン状態の異常
高まるデータ損失のリスク

VIII.このような問題を正しく理解するための考え方のまとめ

この3つのポイントを覚えておくべきだ：

ハートビートはインフラであり、ゴミのようなコードではない
CPUスパイクは通常、プラグイン/ロジックの問題で、Heartbeatによって増幅される。
最適化は「スイッチオフ」ではなく、「コントロール」と「ポジショニング」に重点を置いている。

結論：鼓動は敵ではない、コントロールを失うことが問題なのだ！

あなたのサイトのバックエンドが遅くなり、CPUが急上昇した場合：

最初にハートビートをオフにしないでください。
まずは、このことを理解してほしい。きっかけは？
その上で、次のことが必要かどうかを判断する。回数制限、ページ数制限、マウントロジックの削減

真のプロフェッショナルな最適化とは、決して「機能をオフにする」ことではない。
そうではなく、「機能すべきところにのみ機能を出現させる」のである。

お問い合わせ
チュートリアルが読めない？無料でお答えします！個人サイト、中小企業サイトのための無料ヘルプ！	カスタマーサービス WeChat
① 電話：020-2206-9892
② QQ咨询：1025174874
三 Eメール：info@361sale.com
④ 勤務時間: 月～金、9:30～18:30、祝日休み