Passer au contenu 
L'API WordPress Heartbeat provoque des ralentissements sur les hébergements mutualisés en raison de fréquents pings AJAX via admin-ajax.php. Charge du serveur et entraîne ainsi un ralentissement notable du backend. Je vais vous montrer comment réduire en toute sécurité la fréquence des pulsations, diminuer la charge du serveur WordPress et conserver des fonctions importantes telles que l'enregistrement automatique.
Points centraux
- fréquence cardiaque Prolonger de manière ciblée plutôt que désactiver complètement.
- enregistrement automatique Conserver dans l'éditeur, arrêter les pings inutiles.
- Ressources partagées Protéger : CPU, RAM, E/S sous surveillance.
- Suivi avant/après optimisation pour des effets clairs.
- Holistique Optimisation : mise en cache, base de données, CDN, version PHP.
Comprendre Heartbeat : une fonctionnalité utile, mais coûteuse
L'API Heartbeat envoie des requêtes AJAX périodiques, généralement toutes les 15 secondes dans le tableau de bord, afin de maintenir les sessions et de sauvegarder les brouillons ; ces Fréquence a toutefois un coût. Chaque ping atteint admin-ajax.php et déclenche des processus PHP, des accès à la base de données et, le cas échéant, des hooks de plugin. Si le navigateur reste minimisé, la communication se poursuit souvent et génère des pics de charge. Les onglets ouverts multiplient les requêtes et ralentissent le temps de réponse de l'éditeur. Sur les systèmes fortement partagés, cela entraîne des processus ralentis, des sauvegardes automatiques tardives et un travail subjectivement „ laborieux “.
Pourquoi l'hébergement mutualisé souffre particulièrement
Sur l'hébergement mutualisé, je partage le CPU, la RAM et les E/S avec les sites voisins, c'est pourquoi les requêtes supplémentaires ralentissent les Capacité plus rapidement. Si plusieurs utilisateurs se connectent en même temps ou si le tableau de bord reste ouvert pendant des heures, les pings s'accumulent et bloquent les workers PHP. Le TTFB et les temps d'attente dans l'administration augmentent alors, et la charge du serveur WordPress atteint rapidement des pics. En cas de charges simultanées provenant de sites voisins, une réaction en chaîne se produit : les hits de cache diminuent, les verrous de base de données augmentent, l'éditeur semble lent. Je transforme ainsi involontairement une fonction pratique en une source de charge.
Reconnaître les symptômes à temps
Si je remarque des clics laborieux dans le backend, un nombre inhabituel de requêtes POST dans les DevTools et des saisies saccadées dans l'éditeur, tout porte à croire que les pings Heartbeat sont à l'origine du problème. Pilote Les avertissements de l'hôte concernant les pics d'utilisation du processeur ou les limites de mémoire vive s'inscrivent également dans ce tableau. Des Core Web Vitals plus faibles dans le contexte administratif et une baisse des scores PageSpeed peuvent également être des signaux indirects. Dans les journaux, je constate une accumulation d'accès à admin-ajax.php avec l'action „ heartbeat “. Si ces effets se produisent en dehors des périodes d'activité, les onglets en arrière-plan gaspillent des ressources précieuses.
Combien de requêtes sont réellement générées ? Un rapide calcul
Un intervalle standard de 15 secondes génère quatre pings par minute et par onglet. Trois onglets d'administration ouverts signifient donc 12 requêtes de pulsation par minute, par rédacteur. Si deux personnes travaillent en parallèle, cela fait déjà 24 par minute, soit 1 440 par heure. Si je règle l'intervalle dans l'administration sur 60 secondes, je réduis la même charge à trois pings par minute et par personne. Dans l'exemple ci-dessus, le nombre passe de 24 à 6 par minute, soit une réduction de 75 %. Ce simple calcul explique pourquoi le temps de réponse perçu s'améliore considérablement après une réduction.
Prendre le contrôle : plugins ou code
Je mise d'abord sur une règle claire : augmenter la fréquence plutôt que d'agir à l'aveuglette. éteindre. À l'aide d'outils tels que Heartbeat Control, WP Rocket ou LiteSpeed Cache, je règle 30 à 60 secondes dans l'administration, 120 à 180 secondes dans l'interface utilisateur et désactive les pings sur les pages sans interaction. Si vous préférez le code, vous pouvez ralentir l'API de manière sélective. Exemple : réglez les intervalles sur 60 secondes et ne laissez que l'enregistrement automatique dans l'éditeur. Cela me permet de réduire la charge sans compromettre la sécurité du contenu.
// Ajuster les intervalles add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // secondes return $settings; });
// Désactiver Heartbeat, par exemple dans le frontend add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Éditeur de blocs ou classique : ce que Heartbeat prend réellement en charge dans l'éditeur
Dans l'éditeur classique, la sauvegarde automatique s'appuie directement sur Heartbeat. Dans l'éditeur de blocs (Gutenberg), la sauvegarde automatique s'effectue principalement via l'API REST, mais Heartbeat continue d'assurer des tâches importantes telles que le verrouillage des publications et les vérifications de session. Conclusion pratique : un allongement modéré (30 à 60 secondes) n'interrompt pas l'enregistrement automatique dans l'éditeur de blocs, mais peut retarder l'affichage des mises à jour des verrous et des messages d'état. C'est pourquoi je choisis des intervalles plus courts dans l'éditeur que dans le reste de l'administration et je teste avec de véritables brouillons si les verrous et les avertissements fonctionnent comme prévu.
Ralentissement sélectif en fonction de l'écran et du rôle
Pour obtenir un contrôle maximal, je régule Heartbeat en fonction de l'écran (Screen) et, si nécessaire, des rôles des utilisateurs. Ainsi, l'éditeur reste rapide, tandis que les zones d'administration calmes ne génèrent pratiquement aucun ping.
// 1) Intervalles différents selon l'écran 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; // Éditeur : plus fréquent pour l'enregistrement automatique/le verrouillage
} else { $settings['interval'] = 60; // reste de l'admin } } return $settings; }); // 2) Charger Heartbeat dans l'admin uniquement là où cela est nécessaire add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Contextes de l'éditeur if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Traiter différemment le frontend (par exemple pour les utilisateurs connectés) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Visiteurs : pas besoin de Heartbeat } }, 1);
// Facultatif : harmoniser l'intervalle d'enregistrement automatique add_filter('autosave_interval', function() { return 60; });Avec cette configuration, les fonctions en direct restent actives là où elles sont utiles et disparaissent dans les zones sans interaction. Dans le contexte de la boutique ou du paiement, je garde Heartbeat actif de manière ciblée et brève, tandis qu'il reste désactivé dans le reste du frontend.
Intervalles raisonnables et exceptions
Je maintiens l'éditeur opérationnel tout en supprimant les pings inutiles sur les pages calmes, car enregistrement automatique reste essentiel. 60 secondes dans l'administration constituent souvent le juste milieu entre sécurité et charge. Dans le frontend, je n'ai généralement pas besoin de Heartbeat, sauf pour les composants en direct. Pour les boutiques ou les interfaces utilisateur dynamiques, je ne prévois des cycles plus courts que là où des saisies sont effectuées. Ainsi, la page reste rapide et stable sans compromettre le contenu.
| Contexte | Intervalle recommandé | Remarque |
|---|---|---|
| Tableau de bord général | 60 s | Dernier diminue nettement, les sessions restent actives. |
| éditeur postal | 30 à 60 s | Les fonctions d'enregistrement automatique et de verrouillage restent disponibles. |
| Frontend statique | Désactiver | Aucune interaction, donc aucun ping nécessaire. |
| Frontend interactif (par exemple, paiement) | 15 à 30 s | Uniquement sur les personnes concernées Pages Activer. |
| Onglets d'administration ouverts depuis longtemps | 90 à 120 s | Économisez des ressources lorsque l'onglet reste en arrière-plan. |
Alléger la charge utile Heartbeat : moins de données par ping
Outre la fréquence, la quantité de données transférées est également importante. Certains plugins ajoutent des informations supplémentaires à Heartbeat. Grâce à des filtres, je peux réduire davantage la charge du serveur en supprimant les charges utiles inutiles ou en simplifiant les réponses.
// 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);Je vérifie ensuite la taille des réponses Heartbeat dans DevTools. Si la charge utile diminue, cela soulage la base de données et PHP, en particulier pendant les heures de pointe.
Optimisation globale : mise en cache, base de données, médias, PHP
Heartbeat est une pièce du puzzle, mais j'obtiens un réel effet lorsque je combine la mise en cache, la maintenance de la base de données et l'optimisation des médias afin d'améliorer les performances globales. Dernier continuer à réduire. La mise en cache des pages et des objets réduit les requêtes de base de données dans le flux d'administration. Je réduis systématiquement la taille des images et j'active le chargement différé. Je nettoie régulièrement les révisions, les transitoires et les sessions. Je vérifie également la version PHP et supprime les modules complémentaires inutiles ; j'approfondis ce sujet avec ce guide sur Antipatterns des plugins.
Dans la base de données, je fais attention aux options autoloaded, aux révisions gonflées et aux transitoires obsolètes. Une limite maximale pour les révisions empêche la prolifération sans compromettre la sécurité. La mise en cache d'objets (par exemple Redis) est particulièrement utile dans la zone d'administration, car les requêtes récurrentes trouvent plus rapidement leurs données. De plus, moins de plugins activés signifie moins de hooks que chaque appel Heartbeat peut déclencher.
Combiner WP-Cron et Heartbeat
De nombreuses installations utilisent Heartbeat indirectement, tandis que WP-Cron déclenche des tâches en parallèle, ce qui, aux heures de pointe, peut entraîner une surcharge du serveur. Travailleur Je vérifie donc les tâches cron, je regroupe les fréquences et j'évite les événements inutiles. En cas de charge permanente, je passe au cron système réel et désactive les appels wp-cron.php par les visiteurs. Cela stabilise les temps de réponse et protège l'interface d'administration. Si vous souhaitez approfondir le sujet, vous trouverez des étapes pratiques dans mon article sur Optimiser WP-Cron.
PHP Worker, concurrence et files d'attente AJAX
Les requêtes AJAX sont en concurrence avec les consultations de pages, c'est pourquoi un nombre limité de workers PHP temps d'attente augmenté sensiblement. Lorsque les appels Heartbeat s'accumulent, le backend semble se bloquer, même si le serveur reste accessible. Je vise donc moins de pings, mais plus pertinents, et des caches qui soulagent PHP. Lorsque les projets prennent de l'ampleur, j'envisage d'augmenter le nombre de workers ou de changer de tarif. Si vous souhaitez comprendre cette interaction, consultez mon guide sur Équilibre des workers PHP.
Comportement de navigation et d'utilisation : onglets en arrière-plan et limitation du débit
Les navigateurs modernes limitent les minuteries dans les onglets en arrière-plan, mais les appels Heartbeat ne disparaissent pas complètement pour autant : ils deviennent simplement moins fréquents. Le nombre de fenêtres, de profils et d'appareils ouverts en parallèle est déterminant. Je sensibilise les rédacteurs : fermer les onglets d'administration inutiles, éviter les longues périodes d'inactivité et, en cas de doute, enregistrer les brouillons avant de quitter le poste de travail. La limitation technique par code complète parfaitement ces règles de conduite.
Dépannage : conflits courants et tests sécurisés
Si des problèmes surviennent après une limitation, je vérifie d'abord : le post-locking fonctionne-t-il ? Les délais d'expiration de session sont-ils toujours signalés ? Le paiement fonctionne-t-il correctement dans les formulaires en temps réel ? Je désactive temporairement certaines étapes d'optimisation, je teste avec différents rôles et je passe de l'éditeur classique à l'éditeur de blocs. Dans DevTools, je filtre le réseau selon „ action=heartbeat “ et observe l'intervalle, la durée et la taille. Côté serveur, les journaux PHP et d'erreurs fournissent des informations si les hooks des plugins ralentissent Heartbeat de manière imprévue.
Plan de surveillance et de test : comment mesurer l'effet
Je commence par un profil avant : nombre de requêtes admin-ajax.php par minute, part du CPU, RAM et temps de réponse de l'éditeur, afin de Base Ensuite, je définis de nouveaux intervalles et répète les mesures dans les mêmes conditions d'utilisation. Dans les outils de développement du navigateur, je vérifie si les pings sont moins fréquents et plus rapides. Dans le panneau d'hébergement, j'observe si les pics de charge s'atténuent. Ce n'est que lorsque les résultats sont stables que je transfère les paramètres vers les systèmes en direct.
Valeurs cibles et évaluation
En tant qu'administrateur, je vise les objectifs suivants : intervalle de 60 s sur les écrans généraux, 30 à 60 s dans l'éditeur, moins de 300 ms TTFB pour les réponses Heartbeat et une taille de réponse moyenne inférieure à 10 Ko, en fonction des plugins. Sous charge (plusieurs utilisateurs, plusieurs onglets), il ne devrait pas y avoir de longues files d'attente ; l'utilisation des travailleurs reste fluide, au lieu de basculer en dents de scie. Si j'y parviens, l'équipe éditoriale ressentira immédiatement la différence.
Quand une mise à niveau de l'hébergement est-elle judicieuse ?
Même avec une configuration propre, un projet peut utiliser les ressources communes d'un tarif. faire exploser. Plusieurs rédacteurs simultanés, le paiement en ligne, la recherche ou les widgets de chat augmentent la charge AJAX. Dans ce cas, je calcule les coûts : perte de temps pour l'équipe vs surcoût pour plus de travailleurs, de RAM et de CPU. Souvent, une mise à niveau vaut la peine dès que les rédacteurs sont bloqués quotidiennement. Je commence par le plan suivant et je teste si le traitement reste fluide.
En bref
L'API Heartbeat offre des fonctionnalités précieuses en temps réel, mais elle sollicite l'hébergement mutualisé si je ne définis pas les intervalles et les contextes. contrôle. Avec des cycles plus longs dans l'administration, le frontend désactivé et l'autosave activé dans l'éditeur, je réduis considérablement les requêtes. La mise en cache, l'organisation de la base de données, des plugins légers et une version PHP actuelle apportent une stabilité supplémentaire. En combinaison avec un WP-Cron propre et suffisamment de PHP-Workers, les clics laborieux dans le backend disparaissent. Je conserve ainsi le confort et la sécurité tout en réduisant la charge sur mon hébergement.
