Zum Inhalt springen 
Die WordPress Heartbeat API verursacht auf Shared Hosting durch häufige AJAX-Pings über admin-ajax.php stille Serverlast und führt damit zu spürbarer Verzögerung im Backend. Ich zeige, wie ich die Heartbeat-Frequenz sicher zähme, den server load wordpress senke und wichtige Funktionen wie Autosave erhalte.
Zentrale Punkte
- Heartbeat-Frequenz zielgerichtet verlängern statt komplett deaktivieren.
- Autosave im Editor bewahren, unnötige Pings stoppen.
- Shared Ressourcen schützen: CPU, RAM, I/O im Blick.
- Monitoring vor/nach Optimierung für klare Effekte.
- Ganzheitliche Optimierung: Caching, DB, CDN, PHP-Version.
Heartbeat verstehen: Nützliche Funktion mit Kosten
Die Heartbeat API sendet periodische AJAX-Requests, typischerweise alle 15 Sekunden im Dashboard, um Sessions zu halten und Entwürfe zu sichern; diese Frequenz hat jedoch ihren Preis. Jeder Ping trifft admin-ajax.php und löst PHP-Prozesse, Datenbankzugriffe und ggf. Plugin-Hooks aus. Bleibt der Browser minimiert, läuft die Kommunikation oft weiter und erzeugt Lastspitzen. Offene Tabs vervielfachen die Anfragen und drücken die Reaktionszeit des Editors. Auf stark geteilten Systemen führt das zu gedrosselten Prozessen, späten Autosaves und subjektiv „zähem“ Arbeiten.
Warum Shared Hosting besonders leidet
Auf Shared Hosting teile ich CPU, RAM und I/O mit Nachbarseiten, weshalb zusätzliche Requests die Kapazität schneller ausschöpfen. Kommen mehrere Nutzer zusammen oder bleibt das Dashboard stundenlang offen, summieren sich Pings und blockieren PHP-Worker. Dann steigen TTFB und Wartezeiten im Admin, und der server load wordpress klettert in kurze Peaks. Bei gleichzeitigen Lasten von Nachbarsites entsteht eine Kettenreaktion: Cache-Hits sinken, Datenbank-Locks nehmen zu, der Editor wirkt träge. So verwandle ich eine Komfortfunktion unbeabsichtigt in eine Lastquelle.
Symptome rechtzeitig erkennen
Merke ich zähe Klicks im Backend, auffällig viele POST-Requests in den DevTools und ruckelige Eingaben im Editor, deutet vieles auf die Heartbeat-Pings als Treiber hin. Host-Warnungen wegen CPU-Spitzen oder Arbeitsspeicher-Limits passen ebenfalls ins Bild. Auch schwächere Core Web Vitals im Admin-Kontext und sinkende PageSpeed-Scores können indirekte Signale sein. In Logs sehe ich Häufungen von admin-ajax.php Zugriffe mit „heartbeat“-Action. Treten diese Effekte bei inaktiver Bearbeitung auf, verschwenden Hintergrund-Tabs wertvolle Ressourcen.
Wie viele Requests entstehen wirklich? Eine kurze Rechnung
Ein Standardintervall von 15 Sekunden erzeugt pro Tab vier Pings pro Minute. Drei geöffnete Admin-Tabs bedeuten damit 12 Heartbeat-Requests pro Minute – pro Redakteur. Arbeiten zwei Personen parallel, sind es bereits 24 pro Minute, also 1.440 pro Stunde. Stelle ich das Intervall im Admin auf 60 Sekunden, reduziere ich dieselbe Last auf drei Pings pro Minute und Person. In obigem Beispiel sinkt die Anzahl von 24 auf 6 pro Minute: eine Reduktion um 75 %. Diese einfache Rechnung erklärt, warum die gefühlte Reaktionszeit nach einer Drosselung signifikant verbessert.
Kontrolle übernehmen: Plugins oder Code
Ich setze zuerst auf eine klare Regel: Frequenz erhöhen statt blind abschalten. Mit Tools wie Heartbeat Control, WP Rocket oder LiteSpeed Cache stelle ich im Admin 30–60 Sekunden ein, im Frontend 120–180 Sekunden und deaktiviere Pings auf Seiten ohne Interaktion. Wer Code bevorzugt, kann die API selektiv ausbremsen. Beispiel: Intervalle auf 60 Sekunden setzen und nur im Editor Autosave belassen. So reduziere ich Last, ohne Sicherheit für Inhalte zu verlieren.
// Intervalle anpassen
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 60; // Sekunden
return $settings;
});
// Heartbeat z.B. im Frontend deaktivieren
add_action('init', function() {
if ( ! is_admin() ) wp_deregister_script('heartbeat');
}, 1);
Block-Editor vs. Classic: Was Heartbeat im Editor wirklich übernimmt
Im Classic Editor stützt sich Autosave direkt auf Heartbeat. Im Block-Editor (Gutenberg) läuft Autosave primär über die REST-API, doch Heartbeat übernimmt weiterhin wichtige Aufgaben wie Post-Locking und Session-Checks. Fazit für die Praxis: Eine moderate Verlängerung (30–60 s) bricht Autosave im Block-Editor nicht, kann aber das Aktualisieren von Sperren und Statusmeldungen verzögert anzeigen. Deshalb wähle ich im Editor kürzere Intervalle als im restlichen Admin und teste mit echten Entwürfen, ob Sperren und Warnungen erwartungsgemäß funktionieren.
Selektives Drosseln nach Screen und Rolle
Um maximale Kontrolle zu bekommen, reguliere ich Heartbeat abhängig vom Bildschirm (Screen) und ggf. von Benutzerrollen. So bleibt der Editor schnell, während ruhige Admin-Bereiche praktisch keine Pings erzeugen.
// 1) Unterschiedliche Intervalle je nach Screen
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; // Editor: häufiger für Autosave/Locking
} else {
$settings['interval'] = 60; // übriges Admin
}
}
return $settings;
});
// 2) Heartbeat im Admin nur dort laden, wo nötig
add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Editor-Kontexte
if ( ! in_array($hook, $allowed, true) ) {
wp_deregister_script('heartbeat');
}
}, 1);
// 3) Frontend differenziert behandeln (z.B. für eingeloggte User)
add_action('wp_enqueue_scripts', function() {
if ( ! is_user_logged_in() ) {
wp_deregister_script('heartbeat'); // Besucher: kein Heartbeat nötig
}
}, 1);
// Optional: Autosave-Intervall harmonisieren
add_filter('autosave_interval', function() { return 60; });Mit diesem Setup bleiben Live-Funktionen dort aktiv, wo sie Nutzen stiften, und verschwinden in Bereichen ohne Interaktion. Im Shop- oder Checkout-Kontext halte ich Heartbeat gezielt aktiv und kurz, im restlichen Frontend bleibt es aus.
Sinnvolle Intervalle und Ausnahmen
Ich halte den Editor funktionsfähig, während ich unnötige Pings auf ruhigen Seiten streiche, denn Autosave bleibt essenziell. 60 Sekunden im Admin trifft oft den Sweet Spot zwischen Sicherheit und Last. Im Frontend brauche ich Heartbeat meist gar nicht, mit Ausnahmen für Live-Komponenten. Bei Shops oder dynamischen UIs plane ich kürzere Zyklen nur dort, wo Eingaben laufen. So bleibt die Seite schnell und stabil, ohne Inhalte zu gefährden.
| Kontext | Empfohlenes Intervall | Hinweis |
|---|---|---|
| Dashboard allgemein | 60 s | Last sinkt deutlich, Sessions bleiben aktiv. |
| Post-Editor | 30–60 s | Autosave und Locking weiter nutzbar. |
| Frontend statisch | Deaktivieren | Keine Interaktion, also keine Pings nötig. |
| Frontend interaktiv (z.B. Checkout) | 15–30 s | Nur auf betroffenen Seiten aktivieren. |
| Lang geöffnete Admin-Tabs | 90–120 s | Ressourcen sparen, wenn der Tab im Hintergrund bleibt. |
Heartbeat-Payload entschlacken: weniger Daten pro Ping
Neben der Frequenz zählt die Menge der übertragenen Daten. Einige Plugins hängen zusätzliche Informationen an Heartbeat an. Über Filter kann ich die Serverlast weiter reduzieren, indem ich unnötige Payload abschneide oder Antworten vereinfache.
// 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);Ich kontrolliere danach in den DevTools die Größe der Heartbeat-Responses. Schrumpft die Payload, entlastet das Datenbank und PHP, besonders in Peak-Zeiten.
Ganzheitliche Optimierung: Caching, DB, Medien, PHP
Heartbeat ist ein Puzzleteil, doch echte Wirkung erreiche ich, wenn ich Caching, Datenbank-Pflege und Medien-Optimierung kombiniere, um die Last weiter zu senken. Page- und Object-Caching reduzieren Datenbankabfragen im Admin-Flow. Ich verkleinere Bilder konsequent und aktivere Lazy Loading. Revisions, Transients und Sessions räume ich regelmäßig auf. Zudem prüfe ich die PHP-Version und entferne unnötige Add-ons; tiefer gehe ich mit diesem Leitfaden zu Plugin-Antipatterns.
In der Datenbank achte ich auf autoloaded Options, aufgeblähte Revisions und veraltete Transients. Eine Obergrenze für Revisionen verhindert Wildwuchs, ohne Sicherheit aufzugeben. Objekt-Caching (z. B. Redis) hilft gerade im Admin-Bereich spürbar, weil wiederkehrende Anfragen schneller ihre Daten finden. Und: Weniger aktivierte Plugins bedeuten weniger Hooks, die jeder Heartbeat-Call anstoßen kann.
WP-Cron und Heartbeat zusammendenken
Viele Installationen nutzen Heartbeat indirekt, während WP-Cron parallel Tasks auslöst, was in Spitzenzeiten die Worker zusätzlich bindet. Ich prüfe daher die Cron-Jobs, fasse Häufigkeiten zusammen und vermeide unnötige Events. Bei dauerhafter Last stelle ich auf echten System-Cron um und deaktiviere wp-cron.php Aufrufe durch Besucher. Das stabilisiert Antwortzeiten und schützt die Admin-Oberfläche. Wer tiefer einsteigen will, findet praktische Schritte in meinem Beitrag zu WP-Cron optimieren.
PHP-Worker, Concurrency und AJAX-Queues
AJAX-Requests laufen in Konkurrenz zu Seitenaufrufen, weshalb eine knappe Anzahl an PHP-Workern die Wartezeit spürbar erhöht. Stapeln sich Heartbeat-Calls, friert das Backend gefühlt ein, obwohl der Server erreichbar bleibt. Ich ziele daher auf weniger, aber sinnvollere Pings und auf Caches, die PHP entlasten. Wenn Projekte wachsen, prüfe ich höhere Worker-Kontingente oder wechsle den Tarif. Wer das Zusammenspiel verstehen will, liest meinen Leitfaden zur PHP-Worker Balance.
Browser- und Nutzungsverhalten: Hintergrund-Tabs und Timer-Throttling
Moderne Browser drosseln Timer in Hintergrund-Tabs, doch Heartbeat-Calls verschwinden damit nicht vollständig – sie werden lediglich seltener. Entscheidend ist, wie viele Fenster, Profile und Geräte parallel geöffnet sind. Ich sensibilisiere Redakteure: Nicht benötigte Admin-Tabs schließen, lange Inaktivität vermeiden und im Zweifel Entwürfe speichern, bevor man den Arbeitsplatz verlässt. Die technische Drosselung per Code ergänzt diese Verhaltensregeln optimal.
Fehlersuche: typische Konflikte und sichere Tests
Kommt es nach einer Drosselung zu Problemen, prüfe ich zuerst: Funktioniert Post-Locking? Werden Session-Timeouts noch gemeldet? Läuft der Checkout in Echtzeit-Formularen stabil? Ich deaktiviere temporär einzelne Optimierungsschritte, teste mit verschiedenen Rollen und wechsle zwischen Classic und Block-Editor. In den DevTools filtere ich das Netzwerk nach „action=heartbeat“ und beobachte Intervall, Dauer und Größe. Serverseitig liefern PHP- und Error-Logs Hinweise, falls Hooks von Plugins Heartbeat ungeplant verlangsamen.
Monitoring und Testplan: So messe ich den Effekt
Ich starte mit einem Vorher-Profil: Anzahl der admin-ajax.php Requests pro Minute, CPU-Anteil, RAM und Editor-Reaktionszeit, um die Basis zu kennen. Danach setze ich neue Intervalle und wiederhole Messungen unter gleicher Nutzung. In Browser-DevTools prüfe ich, ob Pings seltener kommen und schneller abschließen. Im Hosting-Panel beobachte ich, ob Lastspitzen abflachen. Erst wenn die Ergebnisse stabil sind, übertrage ich die Einstellungen auf Live-Systeme.
Zielwerte und Auswertung
Als Ziel strebe ich im Admin an: Intervall 60 s auf allgemeinen Screens, 30–60 s im Editor, unter 300 ms TTFB für Heartbeat-Responses und eine durchschnittliche Response-Größe unter 10 KB – abhängig von Plugins. Unter Last (mehrere Nutzer, mehrere Tabs) sollten keine langen Queues entstehen; die Worker-Auslastung bleibt glatt, statt in Sägezähne zu kippen. Erreiche ich das, spürt das Redaktionsteam den Unterschied sofort.
Wann ein Hosting-Upgrade sinnvoll ist
Selbst mit sauberer Konfiguration kann ein Projekt die gemeinsamen Ressourcen eines Tarifs sprengen. Mehr gleichzeitige Redakteure, Shop-Checkout, Suche oder Chat-Widgets treiben AJAX-Last hoch. In solchen Fällen rechne ich die Kosten: Zeitverlust im Team vs. Mehrpreis für mehr Worker, RAM und CPU. Oft lohnt ein Upgrade, sobald Redakteure täglich blockiert werden. Ich starte mit dem nächsten Plan und teste, ob die Bearbeitung flüssig bleibt.
Kurz zusammengefasst
Die Heartbeat API liefert wertvolle Echtzeit-Funktionen, belastet Shared Hosting jedoch, wenn ich Intervalle und Kontexte nicht steuere. Mit längeren Zyklen im Admin, deaktiviertem Frontend und aktivem Autosave im Editor senke ich die Anfragen deutlich. Caching, Datenbank-Ordnung, schlanke Plugins und eine aktuelle PHP-Version stabilisieren zusätzlich. In Kombination mit sauberem WP-Cron und ausreichend PHP-Workern verschwinden die zähen Klicks im Backend. So halte ich Komfort und Sicherheit und senke gleichzeitig die Last auf meinem Hosting.
