Ga naar de inhoud 
De WordPress Heartbeat API veroorzaakt op shared hosting door frequente AJAX-pings via admin-ajax.php stilte Serverbelasting en leidt daarmee tot een merkbare vertraging in de backend. Ik laat zien hoe ik de heartbeat-frequentie veilig kan temperen, de serverbelasting van WordPress kan verlagen en belangrijke functies zoals autosave kan behouden.
Centrale punten
- Hartslagfrequentie doelgericht verlengen in plaats van volledig deactiveren.
- Automatisch opslaan bewaren in de editor, onnodige pings stoppen.
- Gedeelde bronnen Bescherm: CPU, RAM, I/O in het oog.
- Controle voor/na optimalisatie voor duidelijke effecten.
- Holistische Optimalisatie: caching, DB, CDN, PHP-versie.
Heartbeat begrijpen: handige functie met kosten
De Heartbeat API verzendt periodieke AJAX-verzoeken, doorgaans elke 15 seconden in het dashboard, om sessies te behouden en ontwerpen op te slaan; deze Frequentie heeft echter zijn prijs. Elke ping raakt admin-ajax.php en activeert PHP-processen, databasetoegang en eventueel plugin-hooks. Als de browser geminimaliseerd blijft, gaat de communicatie vaak door en ontstaan er pieken in de belasting. Open tabbladen vermenigvuldigen de verzoeken en vertragen de reactietijd van de editor. Op sterk gedeelde systemen leidt dit tot vertraagde processen, late autosaves en subjectief „traag“ werken.
Waarom shared hosting bijzonder te lijden heeft
Bij shared hosting deel ik CPU, RAM en I/O met naburige sites, waardoor extra verzoeken de Capaciteit sneller uitputten. Als er meerdere gebruikers tegelijkertijd actief zijn of als het dashboard urenlang open blijft staan, stapelen de pings zich op en blokkeren ze PHP-workers. Daardoor stijgen de TTFB en de wachttijden in de admin, en de server load wordpress klimt in korte pieken. Bij gelijktijdige belasting van naburige sites ontstaat een kettingreactie: cache-hits nemen af, databaselocks nemen toe, de editor werkt traag. Zo verander ik onbedoeld een comfortfunctie in een bron van belasting.
Symptomen tijdig herkennen
Als ik trage klikken in de backend, opvallend veel POST-verzoeken in de DevTools en schokkerige invoer in de editor merk, wijst veel op de heartbeat-pings als Bestuurders Hostwaarschuwingen vanwege CPU-pieken of geheugenlimieten passen ook in het plaatje. Ook zwakkere Core Web Vitals in de admin-context en dalende PageSpeed-scores kunnen indirecte signalen zijn. In logs zie ik een toename van admin-ajax.php-toegangen met „heartbeat“-actie. Als deze effecten optreden bij inactieve bewerking, verspillen achtergrondtabbladen waardevolle bronnen.
Hoeveel verzoeken worden er werkelijk gegenereerd? Een korte berekening
Een standaardinterval van 15 seconden genereert vier pings per minuut per tabblad. Drie geopende admin-tabbladen betekenen dus 12 heartbeat-verzoeken per minuut – per redacteur. Als twee personen parallel werken, zijn dat er al 24 per minuut, dus 1.440 per uur. Als ik het interval in de admin instel op 60 seconden, verminder ik dezelfde belasting tot drie pings per minuut per persoon. In het bovenstaande voorbeeld daalt het aantal van 24 naar 6 per minuut: een vermindering van 75 %. Deze eenvoudige berekening verklaart waarom de gevoelde reactietijd na een beperking aanzienlijk is verbeterd.
Controle overnemen: plug-ins of code
Ik ga eerst uit van een duidelijke regel: frequentie verhogen in plaats van blindelings uitschakelen. Met tools zoals Heartbeat Control, WP Rocket of LiteSpeed Cache stel ik in de admin 30-60 seconden in, in de frontend 120-180 seconden en deactiveer ik pings op pagina's zonder interactie. Wie de voorkeur geeft aan code, kan de API selectief afremmen. Voorbeeld: intervallen instellen op 60 seconden en alleen in de editor autosave laten staan. Zo verminder ik de belasting zonder in te boeten aan veiligheid voor de inhoud.
// Intervallen aanpassen add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // seconden return $settings; });
// Heartbeat bijvoorbeeld in de frontend deactiveren add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Blok-editor versus Classic: wat Heartbeat echt doet in de editor
In de Classic Editor is Autosave rechtstreeks gebaseerd op Heartbeat. In de blok-editor (Gutenberg) werkt Autosave voornamelijk via de REST-API, maar Heartbeat blijft belangrijke taken uitvoeren, zoals post-locking en sessiecontroles. Conclusie voor de praktijk: een matige verlenging (30-60 s) onderbreekt Autosave in de blok-editor niet, maar kan het bijwerken van vergrendelingen en statusmeldingen vertragen. Daarom kies ik in de editor kortere intervallen dan in de rest van de admin en test ik met echte ontwerpen of vergrendelingen en waarschuwingen naar verwachting werken.
Selectieve beperking op basis van scherm en rol
Om maximale controle te krijgen, regel ik Heartbeat afhankelijk van het scherm (Screen) en indien nodig van gebruikersrollen. Zo blijft de editor snel, terwijl rustige admin-gebieden vrijwel geen pings genereren.
// 1) Verschillende intervallen afhankelijk van het scherm 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: vaker voor autosave/locking
} else { $settings['interval'] = 60; // overige admin } } return $settings; }); // 2) Heartbeat in admin alleen laden waar nodig add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Editor-contexten if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Frontend gedifferentieerd behandelen (bijv. voor ingelogde gebruikers) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Bezoekers: geen Heartbeat nodig } }, 1);
// Optioneel: autosave-interval harmoniseren add_filter('autosave_interval', function() { return 60; });Met deze opzet blijven live-functies actief waar ze nuttig zijn en verdwijnen ze in gebieden zonder interactie. In de winkel- of checkout-context houd ik Heartbeat gericht actief en kort, in de rest van de frontend blijft het uitgeschakeld.
Zinvolle intervallen en uitzonderingen
Ik houd de editor functioneel terwijl ik onnodige pings op rustige pagina's verwijder, want Automatisch opslaan blijft essentieel. 60 seconden in Admin is vaak de ideale balans tussen veiligheid en belasting. In de frontend heb ik Heartbeat meestal helemaal niet nodig, met uitzondering van live-componenten. Bij winkels of dynamische UI's plan ik alleen kortere cycli waar invoer plaatsvindt. Zo blijft de pagina snel en stabiel, zonder de inhoud in gevaar te brengen.
| Context | Aanbevolen interval | Tip |
|---|---|---|
| Algemeen dashboard | 60 s | Belasting daalt aanzienlijk, sessies blijven actief. |
| Post-editor | 30–60 s | Automatisch opslaan en vergrendelen blijven bruikbaar. |
| Frontend statisch | Deactiveren | Geen interactie, dus geen pings nodig. |
| Interactieve frontend (bijv. checkout) | 15–30 s | Alleen op betrokken Pagina's activeren. |
| Lang geopende admin-tabbladen | 90–120 s | Bespaar bronnen wanneer het tabblad op de achtergrond blijft. |
Heartbeat-payload opschonen: minder gegevens per ping
Naast de frequentie is ook de hoeveelheid overgedragen gegevens van belang. Sommige plug-ins voegen extra informatie toe aan Heartbeat. Met filters kan ik de serverbelasting verder verminderen door onnodige payload weg te laten of antwoorden te vereenvoudigen.
// 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);Vervolgens controleer ik in DevTools de grootte van de heartbeat-responses. Als de payload kleiner wordt, ontlast dat de database en PHP, vooral tijdens piekuren.
Holistische optimalisatie: caching, DB, media, PHP
Heartbeat is een puzzelstukje, maar ik bereik echt effect als ik caching, databasebeheer en media-optimalisatie combineer om de Belasting verder te verlagen. Pagina- en objectcaching verminderen databasequery's in de admin-flow. Ik verklein consequent afbeeldingen en activeer lazy loading. Ik ruim regelmatig revisies, transients en sessies op. Daarnaast controleer ik de PHP-versie en verwijder ik onnodige add-ons; ik ga dieper in op deze handleiding voor Plugin-antipatterns.
In de database let ik op automatisch geladen opties, opgeblazen revisies en verouderde transiënten. Een bovengrens voor revisies voorkomt wildgroei zonder dat dit ten koste gaat van de veiligheid. Objectcaching (bijv. Redis) helpt vooral in het admin-gedeelte, omdat terugkerende verzoeken sneller hun gegevens vinden. En: minder geactiveerde plug-ins betekenen minder hooks die elke heartbeat-call kan activeren.
WP-Cron en Heartbeat samen gebruiken
Veel installaties maken indirect gebruik van Heartbeat, terwijl WP-Cron parallel taken activeert, wat tijdens piekuren de Werknemer extra bindt. Ik controleer daarom de cron-taken, voeg frequenties samen en vermijd onnodige gebeurtenissen. Bij een permanente belasting schakel ik over op echte systeem-cron en deactiveer ik wp-cron.php-oproepen door bezoekers. Dit stabiliseert de responstijden en beschermt de admin-interface. Wie zich hier verder in wil verdiepen, vindt praktische stappen in mijn artikel over WP-Cron optimaliseren.
PHP-Worker, concurrency en AJAX-wachtrijen
AJAX-verzoeken concurreren met paginaweergaven, waardoor een beperkt aantal PHP-workers de wachttijd merkbaar toegenomen. Als heartbeat-oproepen zich opstapelen, lijkt het alsof de backend vastloopt, hoewel de server bereikbaar blijft. Ik streef daarom naar minder, maar zinvollere pings en naar caches die PHP ontlasten. Als projecten groeien, kijk ik naar hogere worker-contingenten of verander ik het tarief. Wie de interactie wil begrijpen, leest mijn handleiding over PHP-Worker Balance.
Browser- en gebruiksgedrag: achtergrondtabbladen en timer-throttling
Moderne browsers beperken timers in achtergrondtabbladen, maar heartbeat-oproepen verdwijnen hierdoor niet volledig – ze worden alleen minder frequent. Het is van cruciaal belang hoeveel vensters, profielen en apparaten tegelijkertijd geopend zijn. Ik maak redacteuren hierop attent: sluit onnodige admin-tabbladen, vermijd langdurige inactiviteit en sla in geval van twijfel concepten op voordat je je werkplek verlaat. De technische beperking via code vormt een optimale aanvulling op deze gedragsregels.
Foutopsporing: typische conflicten en betrouwbare tests
Als er na een beperking problemen optreden, controleer ik eerst: werkt post-locking? Worden sessietime-outs nog gemeld? Werkt het afrekenen in realtimeformulieren stabiel? Ik schakel tijdelijk afzonderlijke optimalisatiestappen uit, test met verschillende rollen en schakel tussen Classic en Block Editor. In DevTools filter ik het netwerk op „action=heartbeat“ en observeer ik het interval, de duur en de grootte. Aan de serverzijde geven PHP- en errorlogs aanwijzingen als hooks van plugins Heartbeat onverwacht vertragen.
Monitoring en testplan: zo meet ik het effect
Ik begin met een profiel van vóór de update: aantal admin-ajax.php-verzoeken per minuut, CPU-gebruik, RAM en reactietijd van de editor om de Basis kennen. Daarna stel ik nieuwe intervallen in en herhaal ik de metingen onder dezelfde omstandigheden. In Browser-DevTools controleer ik of pings minder vaak voorkomen en sneller worden voltooid. In het hostingpaneel kijk ik of pieken in de belasting afvlakken. Pas als de resultaten stabiel zijn, breng ik de instellingen over naar live systemen.
Streefwaarden en evaluatie
Als doel streef ik in Admin naar: interval 60 s op algemene schermen, 30-60 s in de editor, minder dan 300 ms TTFB voor heartbeat-responses en een gemiddelde responsgrootte van minder dan 10 KB – afhankelijk van plug-ins. Onder belasting (meerdere gebruikers, meerdere tabbladen) mogen er geen lange wachtrijen ontstaan; de werkbelasting blijft gelijkmatig, in plaats van te dalen en stijgen. Als ik dat bereik, merkt het redactieteam het verschil meteen.
Wanneer is een hostingupgrade zinvol?
Zelfs met een schone configuratie kan een project de gemeenschappelijke bronnen van een tarief gebruiken. ontploffen. Meer gelijktijdige redacteuren, winkelkassa's, zoek- of chatwidgets verhogen de AJAX-belasting. In dergelijke gevallen bereken ik de kosten: tijdverlies in het team versus meerprijs voor meer werknemers, RAM en CPU. Vaak is een upgrade de moeite waard zodra redacteuren dagelijks worden geblokkeerd. Ik begin met het volgende plan en test of de bewerking soepel blijft verlopen.
Kort samengevat
De Heartbeat API biedt waardevolle realtime functies, maar belast shared hosting als ik intervallen en contexten niet controle. Met langere cycli in de admin, een gedeactiveerde frontend en actieve autosave in de editor verminder ik het aantal verzoeken aanzienlijk. Caching, database-ordening, slanke plug-ins en een actuele PHP-versie zorgen voor extra stabiliteit. In combinatie met een schone WP-Cron en voldoende PHP-workers verdwijnen de trage klikken in de backend. Zo behoud ik comfort en veiligheid en verminder ik tegelijkertijd de belasting van mijn hosting.
