Lass uns zusammen starten
Von der Idee zur Umsetzung – gemeinsam, effizient, individuell.
Stell dir vor, du öffnest einen deiner wichtigsten Blogartikel und plötzlich ist er leer. Oder du wirfst einen Blick in deine Datenbank und findest dort hunderte identische Kopien desselben Beitrags, die innerhalb weniger Minuten erstellt wurden. Was wie ein Hackerangriff aussieht, ist oft hausgemacht: Ein falsch konfigurierter „Herzschlag“ im Hintergrund von WordPress. Ein Klassiker in Sachen WordPress Performance: Die Heartbeat API. Was PHP-Worker entlasten soll, führt im modernen Block-Editor oft zu einer gefährlichen Kettenreaktion und Datenverlust.
Die sogenannte Heartbeat API ist ein mächtiges Werkzeug, das im Verborgenen arbeitet. Doch wer versucht, diesen Puls ohne Fachwissen zu drosseln, riskiert eine gefährliche Kettenreaktion im Block-Editor. In diesem Beitrag erfährst du, warum gut gemeinte Performance-Optimierung manchmal zum Daten-Killer wird und wie du dein System sicher konfigurierst.
Der WordPress-Mythos im Check
Behauptung: „Die Heartbeat API ist unnötiger Ballast. Wer sie radikal drosselt oder deaktiviert, bekommt sofort eine schnellere Website.“
Die bittere Wahrheit: Wer den Puls zu weit senkt, riskiert, dass der Block-Editor (Gutenberg) die Orientierung verliert. Die Folge sind keine Millisekunden Ersparnis, sondern im schlimmsten Fall hunderte Geister-Revisionen und verschwundene Inhalte.
Was ist die WordPress Heartbeat API eigentlich?
Die Heartbeat API (eingeführt mit WordPress 3.6) ist die Standleitung zwischen deinem Browser und dem Server, während du im Backend arbeitest. Sie sorgt dafür, dass WordPress „lebt“, auch wenn du gerade nicht auf Speichern klickst. Sie steuert:
- Autosave: Deine Arbeit wird im Hintergrund gesichert.
- Post-Locking: Sie zeigt dir an, wenn ein Kollege gerade denselben Artikel bearbeitet.
- Sitzungs-Management: Sie verhindert, dass du plötzlich ausgeloggt wirst.
Technisch passiert das über regelmäßige Anfragen (POST-Requests) an die Datei admin-ajax.php. Standardmäßig schlägt dieser Puls alle 15 bis 60 Sekunden.
Das Problem: Wenn der Server außer Atem gerät
Jeder dieser Herzschläge ist ein uncachebarer Request. Das bedeutet: Dein Server muss jedes Mal das komplette WordPress-System inklusive aller Plugins und Themes „hochfahren“, um zu antworten. Das verbraucht wertvolle PHP-Worker.
Bei einer aktiven Redaktion mit vielen gleichzeitigen Nutzern entstehen so hunderte Anfragen pro Minute. Die Folge: Die PHP-Worker sind mit Hintergrund-Rauschen beschäftigt, während echte Besucher deiner Website in der Warteschlange landen. Die Seite wird quälend langsam.
Kurz erklärt: Was sind PHP-Worker?
Stell dir PHP-Worker wie Kellner in einem Restaurant vor. Jeder Besucher und jede Hintergrund-Anfrage braucht einen Kellner, um bearbeitet zu werden. Ein Kellner kann immer nur eine Aufgabe gleichzeitig erledigen. Wenn viele Redakteure gleichzeitig im Backend arbeiten und der Heartbeat sehr oft „schlägt“, sind alle Kellner mit diesen Hintergrund-Anfragen beschäftigt. Echte Besucher müssen dann warten – die Website wird langsam.
Warnung aus der Praxis: Die „Revisions-Explosion“
Viele Performance-Ratgeber (und Plugins wie WP Rocket) empfehlen, den Heartbeat einfach massiv zu drosseln. Doch genau hier lauert die Falle!
Wir haben kürzlich einen Fall beobachtet, bei dem eine unbedachte Drosselung zu massivem Datenchaos führte:
Das Phänomen:
Ein einziger Artikel hatte plötzlich über 476 Revisionen. Davon waren hunderte identische Speicherstände innerhalb weniger Minuten.
Was war passiert?
Der moderne Block-Editor (Gutenberg) verlässt sich für die Synchronisation blind auf den Heartbeat. Wenn das Intervall zu stark gedrosselt wird (z. B. durch Plugins auf über 2 Minuten), verliert der Editor die Verbindung zum Server-Status. Er „glaubt“, die letzte Speicherung sei fehlgeschlagen, gerät in Panik und triggert sofort einen neuen Speicherprozess.
Die fatalen Folgen:
- Inhalts-Verlust: Bei diesen massenhaften „Panik-Speicherungen“ werden Inhalte oft „sanitised“ (bereinigt). Dabei flogen im Testfall plötzlich Custom-HTML-Blöcke (wie Iframes) raus – der Block wurde leer gespeichert.
- Datenbank-Müll: Hunderte identische Revisionen blähen die Datenbank auf und machen das Backend extrem träge.
- Dauerschleife: Der Editor verfängt sich in einem Loop aus Speichern, Fehlermeldung und erneutem Speichern.
WordPress Performance optimieren: Heartbeat API sicher zähmen
Damit dir das nicht passiert, solltest du strategisch vorgehen. Wichtiger Hinweis: Diese Anpassungen greifen tief in das System ein. Wenn du dich dabei unwohl fühlst, ziehe unbedingt einen Fachmann hinzu. Ein kleiner Tippfehler kann deine Seite komplett lahmlegen.
Schritt 1: Die System-Ebene (wp-config.php)
Hier legst du die Grundregeln fest. Du erreichst diese Datei nur via FTP im Hauptverzeichnis deiner WordPress-Installation. Füge den Code oberhalb der Zeile /* That's all, stop editing! Happy publishing. */ ein.
// Autosave-Intervall hochsetzen (passend zur Heartbeat-Drosselung)
define( 'AUTOSAVE_INTERVAL', 120 );
// Revisionen limitieren, um die Datenbank im Ernstfall zu schützen
define( 'WP_POST_REVISIONS', 10 );Schritt 2: Die Anpassungs-Ebene (Child-Theme)
Änderungen am Verhalten von WordPress gehören ausschließlich in ein Child-Theme. Schreibe niemals Code direkt in ein Haupt-Theme (Parent-Theme), da dieser beim nächsten Update gelöscht wird. Von „Code-Snippet-Plugins“ raten wir aus Sicherheitsgründen ab, da sie oft unnötige Angriffsflächen bieten.
Füge diesen Code in die functions.php deines Child-Themes ein:
// 1. Heartbeat im Frontend deaktivieren (hier ist er meist unnötig)
add_action( 'init', function() { if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' ); } });
// 2. Heartbeat-Intervall im Backend moderat drosseln
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60;
return $settings; });Das Zusammenspiel: Warum die Werte zusammenpassen müssen
Vielleicht fragst du dich: „Warum muss ich beide Werte anpassen?“ Das liegt daran, dass Heartbeat und Autosave wie Taktgeber funktionieren, die Hand in Hand arbeiten sollten.
- Der Heartbeat (Puls): Er prüft im Hintergrund den Status (z. B. „Ist die Verbindung noch da?“, „Bearbeitet gerade jemand anderes?“).
- Das Autosave (Speichern): Es schreibt den tatsächlichen Inhalt in die Datenbank.
Die goldene Regel: Das Autosave-Intervall sollte mindestens so groß oder größer sein als das Heartbeat-Intervall. In unserem Beispiel haben wir den Heartbeat auf 60 Sekunden und das Autosave auf 120 Sekunden gesetzt. Das entspannt den Server spürbar. Würdest du den Heartbeat extrem drosseln (z. B. auf 120 Sek.), das Autosave aber bei 60 Sek. lassen, „rennt“ die Speicherung dem Status-Check davon – und genau das triggert oft die oben beschriebene Revisions-Explosion.
Fazit: Stabilität vor Millisekunden
Die Heartbeat API zu drosseln ist ein mächtiges Werkzeug für die Server-Performance, aber kein Spielzeug für schnelle Klicks. Wer hier zu aggressiv vorgeht, riskiert nicht nur eine zugemüllte Datenbank, sondern echten Datenverlust im Block-Editor. Wer die WordPress Performance durch die Heartbeat API verbessern will, muss das Zusammenspiel von Server-Ressourcen und Editor-Stabilität verstehen, statt blind Regler nach links zu schieben.
Mein Rat für eine sichere Optimierung:
- Revisionen begrenzen: Limitiere immer zuerst die Anzahl der gespeicherten Versionen in der
wp-config.php. Das ist die wichtigste Versicherung für deine Datenbank. - Gezielt deaktivieren: Schalte den Heartbeat im Frontend ab, aber lass ihm im Backend genug Spielraum zum Arbeiten.
- Vorsicht bei Plugins: Vertraue nicht blind auf die Standard-Einstellungen von Plugins wie WP Rocket. Prüfe kritisch, ob dein Editor noch stabil läuft.
Ein Wort zur Vorsicht
Wenn du dich beim Bearbeiten von Systemdateien unwohl fühlst oder kein Child-Theme nutzt, lass diese Änderungen bitte unbedingt von einem Fachmann durchführen. Ein kleiner Tippfehler – wie ein vergessenes Semikolon – kann ausreichen, um deine Website komplett lahmzulegen („White Screen of Death“).
Sicherheitstipp: Bearbeite Dateien niemals über den internen Editor im WordPress-Backend. Nutze immer den Zugriff via FTP. Nur so kannst du im Ernstfall eine fehlerhafte Datei sofort durch eine Sicherungskopie ersetzen und deine Seite innerhalb von Sekunden wiederbeleben.
Ein stabiler Puls und sichere Inhalte sind am Ende viel mehr wert als die letzte Millisekunde theoretischer Zeitersparnis.
FAQ
Kann ich die Heartbeat API nicht einfach komplett deaktivieren?
Theoretisch ja, aber wir raten dringend davon ab. Ohne Heartbeat funktionieren das automatische Speichern (Autosave) und die Sperrung von Beiträgen (Post-Locking) nicht mehr. Wenn du dann vergisst manuell zu speichern oder zwei Personen gleichzeitig an einem Text arbeiten, ist Datenverlust vorprogrammiert.
Warum bietet WP Rocket die Drosselung an, wenn sie gefährlich sein kann?
Was passiert, wenn ich kein Child-Theme habe?
Verliere ich Text, wenn ich das Autosave-Intervall auf 120 Sekunden hochsetze?
Hilft die Drosselung auch gegen eine langsame
admin-ajax.php?Übrigens: Dieser Artikel ist Teil unserer Reihe „WordPress-Mythen“. Wir räumen mit gefährlichen Halbwahrheiten auf, die zwar oft als Performance-Tipps verkauft werden, deiner Seite aber mehr schaden als nützen. Hier findest du weitere Mythen im Check.
