ワードプレス

WordPress Heartbeat API：共有ホスティングにおける静かな負荷源

WordPress Heartbeat API は、admin-ajax.php による頻繁な AJAX ピングにより、共有ホスティング上でサイレントエラーを引き起こします。 サーバー負荷 これにより、バックエンドで顕著な遅延が発生します。ハートビート頻度を確実に抑制し、サーバーの負荷を軽減し、自動保存などの重要な機能を維持する方法をご紹介します。.

中心点

心拍数 完全に無効にするのではなく、目的を持って延長する。.
自動保存 エディタに保存し、不要なpingを停止します。.
共有リソース 保護：CPU、RAM、I/O を監視。.
モニタリング 明確な効果を得るための最適化前/最適化後。.
総合的な 最適化：キャッシュ、DB、CDN、PHPバージョン。.

ハートビートを理解する：便利な機能とコスト

Heartbeat API は、セッションを維持し、下書きを保存するために、ダッシュボードでは通常 15 秒ごとに、定期的に AJAX リクエストを送信します。頻度しかし、それには代償が伴います。各 ping は admin-ajax.php に到達し、PHP プロセス、データベースアクセス、場合によってはプラグインフックを起動します。ブラウザが最小化されたままの場合、通信はしばしば継続し、負荷のピークが発生します。開いているタブはリクエストを増加させ、エディタの応答時間を低下させます。共有率の高いシステムでは、プロセスのスロットリング、自動保存の遅延、主観的に「動作が重い」という現象が発生します。.

共有ホスティングが特に影響を受ける理由

共有ホスティングでは、CPU、RAM、I/O を近隣サイトと共有しているため、追加のリクエストにより定員より早く使い切る。複数のユーザーが集まったり、ダッシュボードが何時間も開いたままだったりすると、ping が蓄積して PHP ワーカーがブロックされる。すると、TTFB と管理画面での待ち時間が長くなり、サーバーの負荷が短時間でピークに達する。近隣サイトからの同時負荷により、連鎖反応が発生します。キャッシュヒットは減少し、データベースロックは増加し、エディタの反応は鈍くなります。このようにして、私は意図せずに便利な機能を負荷源に変えてしまうのです。.

症状を早期に発見する

バックエンドでクリックの反応が遅い、DevTools で POST リクエストが異常に多い、エディタでの入力がぎこちない、といった現象が見られる場合、その原因はハートビート ping にある可能性が高いです。 ドライバー ホストの警告も、CPUのピークやメモリ制限について同じことが言えるね。管理画面でのCore Web Vitalsの低下やPageSpeedスコアの低下も間接的な兆候になるかも。ログを見ると、admin-ajax.phpへのアクセスが「heartbeat」アクションで集中しているよ。編集していないときにこういう現象が起きてると、バックグラウンドのタブが貴重なリソースを無駄にしているってことだね。.

実際にいくつのリクエストが発生しているのでしょうか？簡単な計算

15 秒の標準間隔では、タブごとに 1 分間に 4 回の ping が生成されます。3 つの管理タブが開いている場合、編集者 1 人あたり 1 分間に 12 回のハートビートリクエストが発生することになります。2 人が同時に作業している場合、1 分間に 24 回、1 時間に 1,440 回になります。管理画面で間隔を 60 秒に設定すると、同じ負荷が 1 分間に 3 回の ping、1 人あたりに減少します。上記の例では、1 分あたりのリクエスト数が 24 回から 6 回に減少します。これは 75% の削減に相当します。この簡単な計算から、スロットリング後の応答時間が大幅に改善される理由がわかります。.

制御を掌握する：プラグインまたはコード

まず、明確なルールを設定します。盲目的に頻度を増やすのではなく、頻度を増やすことです。 スイッチを切る. Heartbeat Control、WP Rocket、LiteSpeed Cache などのツールを使用して、管理画面では 30～60 秒、フロントエンドでは 120～180 秒に設定し、インタラクションのないページでは ping を無効にします。コードを好む方は、API を選択的に減速させることができます。例：間隔を 60 秒に設定し、エディタでの自動保存のみ残す。これにより、コンテンツの安全性を損なうことなく負荷を軽減することができます。.

// 間隔を調整 add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // 秒 return $settings; });

// フロントエンドなどでハートビートを無効にする add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);

ブロックエディタとクラシックエディタ：エディタでハートビートが実際に担う役割

クラシックエディタでは、自動保存はハートビートに直接依存しています。ブロックエディタ（グーテンベルク）では、自動保存は主に REST API を通じて実行されますが、ハートビートは投稿のロックやセッションチェックなどの重要なタスクを引き続き担当しています。実用上の結論：ブロックエディタでは、適度な延長（30～60 秒）によって自動保存が中断されることはありませんが、ロックやステータスメッセージの更新表示が遅れる場合があります。そのため、エディタでは他の管理画面よりも短い間隔を選択し、実際の草案を使用してロックや警告が期待どおりに機能するかどうかをテストしています。.

画面と役割による選択的なスロットリング

最大限の制御を得るために、画面（スクリーン）や、場合によってはユーザーの役割に応じて Heartbeat を調整しています。これにより、エディタは高速なまま、静かな管理領域では実質的に ping が発生しません。.

// 1) 画面ごとに異なる間隔 add_filter('heartbeat_settings', function($settings) { if ( function_exists('get_current_screen') ) { $screen = get_current_screen();
        if ( $screen && in_array($screen->id, ['post','page','product']) ) { $settings['interval'] = 30; // エディタ：自動保存/ロックのためより頻繁に
        } else { $settings['interval'] = 60; // その他の管理 } } return $settings; }); // 2) 管理者画面では必要な場所のみハートビートをロード add_action('admin_enqueue_scripts', function($hook) {
    $allowed = ['post.php', 'post-new.php', 'site-editor.php']; // エディタコンテキスト if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);

// 3) フロントエンドを差別的に扱う（例：ログインユーザーの場合） add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // 訪問者：ハートビートは不要 } }, 1);

// オプション：自動保存間隔を統一 add_filter('autosave_interval', function() { return 60; });

この設定により、ライブ機能は有用な場所でアクティブなまま、インタラクションのない領域では非表示になります。ショップやチェックアウトのコンテキストでは、ハートビートを意図的にアクティブかつ短く保ち、その他のフロントエンドでは非表示にします。.

意味のある間隔と例外

静かなページで不要なpingを削除しながら、エディタを機能させ続けるよ。 自動保存 これは依然として重要です。管理画面では、60 秒がセキュリティと負荷のバランスに最適な場合が多いです。フロントエンドでは、ライブコンポーネントを除いて、ほとんどの場合ハートビートは必要ありません。ショップや動的な UI では、入力が行われる場所のみ、より短いサイクルを計画しています。これにより、コンテンツを危険にさらすことなく、ページの高速性と安定性を維持することができます。.

コンテクスト	推奨間隔	ヒント
ダッシュボード全般	60秒	負荷明らかに減少、セッションはアクティブなまま。.
ポストエディター	30～60秒	自動保存とロック機能は引き続き利用可能。.
フロントエンド静的	無効化	相互作用がないため、ping は必要ありません。.
フロントエンド対話型（例：チェックアウト）	15～30秒	影響を受けた場合のみページ数有効にする。.
長時間開いている管理者タブ	90～120秒	タブがバックグラウンドにあるときはリソースを節約する。.

ハートビートペイロードの削減：1回のpingあたりのデータ量を削減

周波数に加えて、転送されるデータの量も重要だよ。プラグインによっては、Heartbeat に追加情報を添付するものもあるんだ。フィルターを使って、不要なペイロードをカットしたり、応答を簡略化したりすることで、サーバーの負荷をさらに減らせるよ。.

// Serverantwort für Heartbeat-Anfragen optimieren
add_filter('heartbeat_send', function($response, $data, $screen_id) {
    // Beispiel: große, selten benötigte Blöcke entfernen
    unset($response['irrelevante_status']);
    // Eigene, zu große Daten nicht mitschicken
    if ( isset($data['my_plugin_heavy']) ) {
        unset($data['my_plugin_heavy']);
    }
    return $response;
}, 10, 3);

// Auf eingehende Heartbeat-Daten reagieren (z.B. Logging vermeiden)
add_action('heartbeat_received', function($response, $data, $screen_id) {
    // Teure Vorgänge nur auf relevanten Screens ausführen
    if ( $screen_id !== 'post' ) {
        // ggf. Frühabbruch in eigenen Hooks
    }
}, 10, 3);

その後、DevTools でハートビートレスポンスのサイズを確認します。ペイロードが縮小すると、特にピーク時にデータベースと PHP の負荷が軽減されます。.

総合的な最適化：キャッシュ、DB、メディア、PHP

Heartbeat はパズルのピースのひとつですが、キャッシュ、データベースのメンテナンス、メディアの最適化を組み合わせて、負荷さらに削減します。ページおよびオブジェクトのキャッシュにより、管理フローにおけるデータベースのクエリが削減されます。私は一貫して画像のサイズを縮小し、レイジーローディングを有効にしています。リビジョン、トランジェント、セッションは定期的にクリーンアップしています。さらに、PHP のバージョンを確認し、不要なアドオンを削除しています。このガイドでは、さらに詳しく説明しています。プラグインのアンチパターン.

データベースでは、自動ロードされるオプション、肥大化したリビジョン、および古いトランジェントに注意を払っています。リビジョンの上限を設定することで、セキュリティを犠牲にすることなく、無秩序な増加を防ぐことができます。オブジェクトキャッシュ（Redis など）は、特に管理領域で、繰り返し行われるリクエストがデータをより迅速に見つけられるようになるため、非常に役立ちます。また、有効化されているプラグインが少ないほど、各ハートビートコールがトリガーするフックも少なくなります。.

WP-Cron と Heartbeat を一緒に考える

多くのインストールは間接的にハートビートを利用していますが、WP-Cron はタスクを並行して起動するため、ピーク時には 労働者 さらに、私はクロンジョブをチェックし、頻度をまとめ、不要なイベントを避けています。持続的な負荷がある場合は、実際のシステムクロンに切り替え、訪問者による wp-cron.php の呼び出しを無効にします。これにより、応答時間が安定し、管理インターフェースが保護されます。より深く掘り下げたい方は、私の記事で実用的な手順をご覧いただけます。 WP-Cronの最適化.

PHPワーカー、同時実行性、AJAXキュー

AJAXリクエストはページアクセスと競合するため、PHPワーカーの数が少ないと 待ち時間 顕著に増加します。ハートビートコールが蓄積すると、サーバーはアクセス可能なままでも、バックエンドがフリーズしているように感じられます。そのため、私は、より少ないが、より意味のある ping と、PHP の負荷を軽減するキャッシュを目指しています。プロジェクトが成長したら、より高いワーカー割当を確認するか、料金プランを変更します。この相互作用を理解したい方は、私のガイド「 PHPワーカーのバランス.

ブラウザと利用行動：バックグラウンドタブとタイマースロットリング

最新のブラウザはバックグラウンドタブのタイマーを制限しますが、ハートビートコールが完全に消えるわけではありません。単に頻度が少なくなるだけです。重要なのは、同時に開いているウィンドウ、プロフィール、デバイスの数です。私は編集者に、不要な管理者タブは閉じる、長時間の非アクティブ状態を避ける、疑わしい場合は職場を離れる前に下書きを保存するよう注意を促しています。コードによる技術的な抑制は、これらの行動規範を最適に補完するものです。.

トラブルシューティング：典型的な競合と確実なテスト

スロットリング後に問題が発生した場合、まず最初に確認するのは、ポストロックは機能しているかどうか、セッションタイムアウトは依然として報告されているかどうか、リアルタイムフォームでのチェックアウトは安定しているかどうかです。個々の最適化ステップを一時的に無効にし、さまざまなロールでテストし、クラシックエディタとブロックエディタを切り替えて確認します。 DevTools でネットワークを「action=heartbeat」でフィルタリングし、間隔、継続時間、サイズを観察します。サーバー側では、プラグインのフックがハートビートを予期せず遅延させている場合、PHP ログとエラーログがヒントを提供します。.

モニタリングとテスト計画：効果を測定する方法

まず、以前のプロファイルから始めます。1 分あたりの admin-ajax.php リクエスト数、CPU 使用率、RAM、エディタの応答時間です。 ベース を知っておく必要があります。その後、新しい間隔を設定し、同じ使用状況で測定を繰り返します。ブラウザの DevTools で、ping の頻度が減り、完了が早くなっているかどうかを確認します。ホスティングパネルで、負荷のピークが平準化されているかどうかを確認します。結果が安定してから初めて、設定をライブシステムに転送します。.

目標値と評価

管理画面での目標は、一般画面で60秒間隔、エディタで30～60秒間隔、ハートビート応答で300ミリ秒未満のTTFB、プラグインに依存して平均応答サイズが10KB未満になることです。負荷が高い状態（複数のユーザー、複数のタブ）でも、長いキューが発生することはなく、ワーカーの負荷は、鋸歯状になることなく、スムーズに維持されます。これを達成すれば、編集チームはすぐにその違いを実感できるでしょう。.

ホスティングのアップグレードが有効な場合

クリーンな構成であっても、プロジェクトは料金プランの共有リソースを爆破. 同時編集者、ショップチェックアウト、検索、チャットウィジェットが増えると、AJAXの負荷が高くなります。このような場合、私はコストを計算します。チームでの時間の損失と、追加のワーカー、RAM、CPUの追加費用です。編集者が毎日ブロックされるようになると、多くの場合、アップグレードする価値があります。私は次のプランを開始し、編集がスムーズに進行するかどうかをテストします。.

簡単にまとめると

Heartbeat API は貴重なリアルタイム機能を提供しますが、間隔やコンテキストを設定しない場合、共有ホスティングに負荷がかかります。 コントロール. 。管理画面でのサイクルを長くし、フロントエンドを無効にし、エディタで自動保存を有効にすることで、リクエストを大幅に削減しています。キャッシュ、データベースの整理、スリムなプラグイン、最新の PHP バージョンも安定性に貢献しています。クリーンな WP-Cron と十分な PHP ワーカーを組み合わせることで、バックエンドでの遅いクリックが解消されます。これにより、快適さとセキュリティを維持しながら、ホスティングの負荷を軽減しています。.