Zum Inhalt springen 
Die WordPress Heartbeat API sendet in kurzen Abständen AJAX-Requests über admin-ajax.php, sichert Entwürfe in Echtzeit und verhindert Bearbeitungskonflikte – zugleich kann sie den wp backend load deutlich erhöhen. In diesem Beitrag zeige ich dir Nutzen, Risiken und konkrete Stellschrauben, mit denen du die Performance spürbar entlastest, ohne wichtige Funktionen zu verlieren.
Zentrale Punkte
- Nutzen: Autosave, Post-Locking, Live-Infos im Dashboard
- Risiken: CPU-Spitzen, Last auf admin-ajax.php, zähes Backend
- Frequenzen: 15/60/120 Sekunden je nach Kontext
- Optimierung: Intervalle erhöhen, Frontend drosseln, Plugins
- Hosting: Genug PHP-Worker und gutes Caching
Was die Heartbeat API tut und warum sie wichtig ist
Die Heartbeat API hält den Editor und das Dashboard durch häufige Requests in Echtzeit synchron. Ich profitiere von automatischer Sicherung, Kollisionsschutz beim Schreiben und Benachrichtigungen, ohne Seiten neu zu laden. Besonders im Team sorgt Post-Locking dafür, dass niemand fremde Arbeit versehentlich überschreibt, was spürbar Stress aus Redaktionsprozessen nimmt. Damit diese Vorteile greifen, läuft im Hintergrund ein stetiger Datenaustausch über admin-ajax.php. Das fühlt sich komfortabel an, verbraucht aber auf schwachen Hosts schnell Ressourcen.
Standardintervalle und typische Lastspitzen
Im Editor feuert Heartbeat typischerweise alle 15 Sekunden, im Dashboard alle 60 Sekunden und im Frontend etwa alle 120 Sekunden, was die Frequenz klar vorgibt. Bleiben mehrere Admin-Fenster offen, addieren sich die Calls und belegen PHP-Worker. Sobald Speicher oder CPU knapp werden, reagiert das Backend träge und Eingaben erscheinen mit Verzögerung. Im Tagesgeschäft passiert das oft unbemerkt: ein Tab pro Beitrag, dazu Medien, Formulare, Plugin-Seiten – schon entsteht eine dichte Request-Wolke. Wer diese Intervalle gezielt streckt, nimmt Last vom Server, ohne die wichtigsten Komfortfunktionen zu verlieren.
Risiken: wp backend load, CPU und admin-ajax.php
Jeder Heartbeat-Call startet PHP, lädt WordPress und verarbeitet Aufgaben – das klingt klein, skaliert aber bei mehreren Redakteuren extrem, was den wp backend load hochtreibt. Besonders Shared Hosting zeigt dann CPU-Spitzen, ausgelastete Worker und Verzögerungen im Editor. Ich erkenne solche Muster oft an stockendem Tippen und langsamer Autosave-Anzeige. Detaillierte Hintergründe zu dieser stillen Lastquelle habe ich hier erklärt: stille Lastquelle. Wer diese Effekte ignoriert, riskiert schlechte Core Web Vitals durch langsame Admin-Reaktionszeiten und indirekte Auswirkungen auf Veröffentlichungsprozesse.
Einfluss auf die WordPress Performance in Redaktions-Workflows
Die größte Bremse ist nicht die Datenmenge, sondern die Anzahl der Anfragen und deren Gleichzeitigkeit. Mehrere offene Editoren erzeugen parallel Heartbeat-Requests, die Caches häufig umgehen, weil sie dynamische Daten benötigen. So entstehen Wartezeiten, obwohl die Seite selbst schnell lädt, was Redaktionen als „zähes Backend“ wahrnehmen. Hier hilft es, HTTP-Requests priorisieren und Heartbeat-Intervalle zu strecken, damit weniger PHP-Instanzen gleichzeitig laufen. Ich halte deshalb Editor-Registerkarten schlank und schließe inaktive Tabs konsequent, was die Reaktionszeit merklich stabilisiert.
Best-Practice: Drosseln statt Abschalten
Ich erhöhe zuerst das Intervall, statt Heartbeat rigoros abzuschalten, um Autosave und Post-Locking zu behalten. Ein Intervall von 60 bis 120 Sekunden senkt die Last oft deutlich, ohne die Redaktion zu stören. Für die schnelle Entlastung auf dem Frontend entferne ich Heartbeat dort komplett, da Besucher es selten benötigen. Wer noch weiter gehen will, kann den Editor moderat drosseln und das Dashboard stärker begrenzen. So bleibt die Benutzerführung flüssig, während der Server mehr Luft bekommt.
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 60; // Sekunden im Editor/Dashboard
return $settings;
});
add_action('init', function() {
if ( ! is_admin() ) wp_deregister_script('heartbeat'); // Frontend drosseln
}, 1);
Kontextspezifische Regeln im Admin
Je präziser ich steuere, desto geringer sind Nebenwirkungen. Ich unterscheide Editor, Dashboard und andere Admin-Seiten und vergebe dort unterschiedliche Intervalle. Der Editor bleibt relativ schnell, das Dashboard wird stärker gebremst.
add_action('admin_init', function () {
add_filter('heartbeat_settings', function ($settings) {
if ( ! is_admin() ) return $settings;
if ( function_exists('get_current_screen') ) {
$screen = get_current_screen();
// Editor (Beiträge/Seiten) moderat
if ( $screen && in_array($screen->base, ['post', 'post-new']) ) {
$settings['interval'] = 45;
return $settings;
}
// Dashboard eher langsam
if ( $screen && $screen->base === 'dashboard' ) {
$settings['interval'] = 120;
return $settings;
}
}
// Sonstige Admin-Seiten
$settings['interval'] = 60;
return $settings;
}, 10);
});
So bleiben Post-Locking und Autosave im Editor zuverlässig, während im Dashboard Live-Widgets weniger häufig „pollen“ und den Server schonen.
Lastspitzen pro Tab begrenzen (JavaScript)
Viele Lastspitzen entstehen durch inaktive Browser-Tabs. Ich setze im Admin ein kleines Script ein, das Heartbeat automatisch verlangsamt, wenn der Tab im Hintergrund liegt, und wieder beschleunigt, wenn ich zurückkehre.
add_action('admin_enqueue_scripts', function () {
wp_add_inline_script(
'heartbeat',
"document.addEventListener('visibilitychange', function () {
if (window.wp && wp.heartbeat) {
if (document.hidden) {
wp.heartbeat.interval('slow'); // ~120s
} else {
wp.heartbeat.interval('standard'); // ~60s
}
}
});"
);
});
Damit reduziere ich parallele Heartbeats spürbar, ohne Funktionen zu verlieren. Wichtig: Ich teste danach gezielt Autosave und gleichzeitige Bearbeitung.
Gezielte Payload-Steuerung statt Datenballast
Neben der Frequenz zählt der Inhalt. Einige Plugins hängen große Datenpakete an Heartbeat. Ich halte die Nutzlast schlank, indem ich nur wirklich benötigte Werte sende und auf dem Server unnötige Schlüssel entferne.
// Client: gezielt Daten registrieren
jQuery(function ($) {
if (window.wp && wp.heartbeat) {
wp.heartbeat.enqueue('meine_app', { thin: true }, true);
$(document).on('heartbeat-tick', function (event, data) {
if (data && data.meine_app_response) {
// Antwort effizient verarbeiten
}
});
}
});
// Server: Antwort verschlanken
add_filter('heartbeat_send', function ($response, $data) {
// Entferne schwere/unnötige Keys aus der Antwort
unset($response['unnoetige_daten']);
return $response;
}, 10, 2);
add_filter('heartbeat_received', function ($response, $data) {
// Eingehende Daten prüfen/validieren
return $response;
}, 10, 2);
Diese Feinsteuerung vermeidet Datenballast pro Request und verringert CPU- und I/O-Druck, vor allem bei vielen gleichzeitig aktiven Redakteuren.
Block-Editor (Gutenberg): Besonderheiten im Blick
Im Block-Editor laufen zusätzliche Prozesse wie regelmäßige Draft-Sicherungen und Statusprüfungen. Ich vermeide unnötige Parallelität: kein Massen-Editing in vielen Tabs, Medien-Uploads nacheinander, und ich plane lange Sessions mit klaren Speicherrhythmen. Drosselung im Dashboard fällt stärker aus als im Editor, damit Schreibprozesse nicht „hakeln“. Außerdem beobachte ich, ob einzelne Block-Plugins überproportional häufig Heartbeat/Live-Checks auslösen, und reduziere deren Live-Features im Zweifel.
Edge Cases: WooCommerce, Formulare, Page Builder
- WooCommerce-Admin nutzt Live-Komponenten. Ich drossele, schalte aber Heartbeat in Shop-relevanten Masken nicht vollständig ab, um Bestands- oder Session-Effekte nicht zu stören.
- Formular-Builder mit „Live-Previews“ nutzen oft Heartbeat oder eigene Polling-Mechanismen. Ich teste: Vorschau, Spam-Schutz, Upload – und reguliere deren Aktualisierung separat.
- Page Builder mit Live-Statistiken im Dashboard entlaste ich, indem ich die Widgets ausblende oder deren Aktualisierung seltener erlaube.
Server- und Hosting-Faktoren
Heartbeat belastet PHP-Worker, daher achte ich auf ausreichende Kontingente und schnelles I/O. Object Cache (Redis/Memcached) entlastet PHP-Aufrufe, obwohl Heartbeat dynamisch bleibt. Beim Hosting schaue ich auf Worker-Anzahl, CPU-Reserven und Limits pro Prozess, damit Editor-Sessions nicht ins Stocken geraten. Gute Anbieter liefern klare Metriken, damit ich Last und Engpässe erkenne. Die folgende Übersicht zeigt typische Unterschiede und was sie für die Performance bedeuten.
| Hosting-Anbieter | PHP-Worker | Heartbeat-Optimierung | Geeignet für Redaktionen |
|---|---|---|---|
| webhoster.de | Unbegrenzt | Exzellent | Ja |
| Andere | Begrenzt | Mittel | Teilweise |
PHP-/FPM-Parameter, die ich prüfe
- PHP-FPM: Ausreichende pm.max_children, passende pm.max_requests (z. B. 300–1000) und sinnvolle pm.process_idle_timeout.
- OPcache: Genug Speicher (z. B. 128–256 MB), hohe opcache.max_accelerated_files, validate_timestamps aktiv mit praktikablem Intervall.
- request_terminate_timeout nicht zu knapp, damit lange Editier-Requests nicht abgebrochen werden.
- „Slowlog“ aktivieren, um Ausreißer bei admin-ajax.php zu finden.
CDN/Firewall: typische Stolperfallen
Im Admin-Bereich lasse ich CDN-Caches konsequent aus, setze keine aggressiven Rate Limits auf admin-ajax.php und verhindere, dass Botschutz-Maßnahmen Heartbeat blockieren. Andernfalls drohen fehlerhafte Autosaves, ablaufende Sessions ohne Hinweis oder flackernde Post-Locks. Eine saubere Ausnahme-Rule für den Admin sorgt für stabile Arbeitsbedingungen.
Monitoring und Diagnose
Zur Diagnose prüfe ich Request-Flüsse, Antwortzeiten und wie viele Instanzen von admin-ajax.php parallel laufen, um Spitzen sichtbar zu machen. Tools wie Debug-Plugins und Server-Logs zeigen mir, wann das Backend ins Stolpern gerät. Ich achte zusätzlich auf Sessions, denn blockierende Sitzungen verlängern Bearbeitungen künstlich. Wer mehr verstehen will, schaut sich das Thema PHP Session Locking an, weil es mit Heartbeat-Effekten kollidieren kann. Nach jeder Änderung teste ich Editor, Medien-Upload und Login, damit keine Nebenwirkung unbemerkt bleibt.
Schritt-für-Schritt-Tuning-Plan
- Ist-Zustand messen: Anzahl paralleler admin-ajax.php-Aufrufe, Antwortzeiten, CPU/Worker-Auslastung, Tabs/Benutzer im Peak.
- Frontend entlasten: Heartbeat im Frontend deaktivieren, kritische Frontend-Funktionen gegenprüfen.
- Kontextregeln setzen: Editor moderat (45–60s), Dashboard langsam (90–120s), Rest 60s. Inaktive Tabs auf „slow“.
- Payload schlank halten: Überflüssige Keys entfernen, große Live-Widgets im Dashboard reduzieren oder deaktivieren.
- Serverseitig nachziehen: PHP-FPM/OPcache prüfen, Object Cache aktivieren, sinnvolle Worker-Reserven einplanen.
Praxis-Checkliste für unterschiedliche Szenarien
Für Soloschaffende mit gelegentlichen Updates lasse ich Heartbeat im Editor auf 60–90 Sekunden und deaktiviere es im Frontend. In kleinen Redaktionen mit mehreren Tabs setze ich 60–120 Sekunden und schule das Team, inaktive Fenster zu schließen. Auf trafficstarken Seiten mit vielen Redakteuren erhöhe ich Worker, aktiviere Object Cache und drossele Dashboard-Heartbeat stärker als den Editor. Wenn das Dashboard trotz Drosselung zäh bleibt, prüfe ich Plugins mit Live-Widgets und reduziere deren Aktualisierungen. Erst wenn alle Stellschrauben nicht greifen, schalte ich Heartbeat temporär ab und sichere Workflows durch manuelle Speicher-Disziplin.
Fazit: So halte ich Heartbeat im Zaum
Ich nutze die Stärken der WordPress Heartbeat API – Autosave, Post-Locking, Live-Informationen – und zügle gleichzeitig die Last. Der erste Hebel bleibt das Intervall: strecken, messen, nachjustieren. Dann entlaste ich das Frontend, setze Regeln pro Kontext und halte Tabs schlank. Auf Server-Seite sorge ich für genügend Worker, solide Caching-Schichten und transparente Metriken. So bleibt mein Backend reaktionsschnell, während alle Komfort-Funktionen erhalten bleiben.
