Un hébergeur mutualisé a un jour alerté un de nos clients : son site générait un nombre anormal de requêtes vers admin-ajax.php, en dehors de toute campagne ou pic de trafic visible. L’enquête a mené à une poignée d’utilisateurs qui laissaient l’éditeur d’article ouvert dans un onglet toute la journée, pendant leur pause déjeuner comme pendant leurs réunions. Chaque onglet ouvert envoyait une requête Heartbeat toutes les quinze secondes, sans interruption.
Que fait réellement le Heartbeat
Le Heartbeat API, introduit dans WordPress 3.6, maintient une communication régulière entre le navigateur et le serveur via admin-ajax.php. Il sert à plusieurs usages légitimes : verrouiller un article en cours d’édition pour éviter que deux personnes n’écrasent le travail l’une de l’autre, rafraîchir les notifications de session, ou encore signaler l’expiration prochaine du cookie de connexion. Le problème n’est pas le mécanisme en lui-même, mais sa fréquence par défaut et son absence de coupure automatique sur les pages où il n’apporte rien.
Mesurer l’impact avant d’agir
Avant de modifier quoi que ce soit, quantifiez le phénomène. Sur un site avec une équipe éditoriale de dix personnes travaillant huit heures par jour, un Heartbeat à 15 secondes génère environ 19 200 requêtes quotidiennes rien que pour l’édition, sans compter le tableau de bord. Sur un hébergement mutualisé facturé au nombre de requêtes PHP, ce chiffre a un coût réel.
grep "admin-ajax.php" /var/log/nginx/access.log | wc -lAjuster la fréquence avec heartbeat_settings
Plutôt que de couper le Heartbeat, la première option consiste à espacer ses battements. Le filtre heartbeat_settings permet de fixer un intervalle minimal, entre 15 et 120 secondes :
function wpm_heartbeat_settings( $settings ) {
$settings['interval'] = 60;
return $settings;
}
add_filter( 'heartbeat_settings', 'wpm_heartbeat_settings' );Un intervalle de 60 secondes réduit la charge d’un facteur quatre par rapport au réglage par défaut, tout en restant assez réactif pour le verrouillage d’édition et l’expiration de session.
Couper le Heartbeat là où il ne sert à rien
Sur le tableau de bord d’administration (wp-admin/index.php), le Heartbeat n’apporte généralement aucune fonctionnalité critique pour la majorité des sites, sauf si un widget de tableau de bord dépend explicitement de lui. On peut le désactiver spécifiquement sur cet écran :
function wpm_disable_heartbeat_dashboard() {
global $pagenow;
if ( 'index.php' === $pagenow && ! is_admin() ) {
return;
}
if ( 'index.php' === $pagenow ) {
wp_deregister_script( 'heartbeat' );
}
}
add_action( 'init', 'wpm_disable_heartbeat_dashboard', 1 );Sur l’écran d’édition d’article, en revanche, gardez le Heartbeat actif : le désactiver purement et simplement supprime la protection contre l’écrasement de contenu par deux rédacteurs travaillant sur le même article, une fonctionnalité que les équipes éditoriales remarquent vite si elle disparaît.
Le piège du plugin qui coupe tout sans distinction
Plusieurs extensions grand public proposent de « désactiver le Heartbeat » d’un simple interrupteur, sans distinguer les contextes. Le résultat : le verrouillage d’édition cesse de fonctionner, et deux personnes peuvent écraser leur travail respectif sans avertissement. Avant d’installer ce type d’extension, vérifiez qu’elle propose au minimum un réglage distinct pour le tableau de bord, l’éditeur et le front (via la variante REST utilisée par certains blocs dynamiques).
- Mesurez le volume réel de requêtes avant d’intervenir : le problème n’est pas toujours là où on l’imagine.
- Espacez la fréquence avant de couper complètement, l’intervalle par défaut est rarement justifié.
- Ne coupez jamais le Heartbeat sur l’écran d’édition sans comprendre l’impact sur le verrouillage.
- Vérifiez qu’aucune extension tierce (édition collaborative, notifications temps réel) ne dépend du Heartbeat avant de le restreindre.
Couper un mécanisme sans savoir à quoi il sert coûte toujours plus cher, en support client, que la charge serveur qu’on cherchait à économiser.
En résumé
Le Heartbeat mérite d’être ajusté, rarement d’être supprimé en bloc. Un intervalle de 60 secondes en édition et une désactivation ciblée sur le tableau de bord couvrent la majorité des cas, avec un risque minimal pour les fonctionnalités qui en dépendent réellement.
