WordPress Heartbeat API și consumul de resurse

WordPress Heartbeat API este un mecanism integrat în WordPress care permite browserului să comunice periodic cu serverul fără ca utilizatorul să reîncarce pagina.

Este utilizat pentru funcții utile din WordPress, precum autosave, verificarea sesiunii de autentificare, blocarea unui articol atunci când acesta este editat de alt utilizator și diferite funcționalități implementate de pluginuri.

În anumite situații, aceste request-uri periodice pot contribui la creșterea consumului de CPU și a numărului de procese active, în special atunci când există mai mulți administratori conectați simultan, multe tab-uri WordPress deschise sau pluginuri care folosesc intensiv Heartbeat API.

Totuși, simpla existență a request-urilor către admin-ajax.php nu înseamnă automat că WordPress Heartbeat este cauza unui consum ridicat.

În acest articol vom vedea cum funcționează Heartbeat API, cum îl identificăm și cum putem verifica dacă are într-adevăr impact asupra resurselor website-ului.

Ce este WordPress Heartbeat API?

WordPress Heartbeat API este un sistem de comunicare periodică între browser și server.

Atunci când anumite pagini WordPress sunt deschise, JavaScript-ul din browser poate trimite periodic date către server.

Procesul poate fi reprezentat simplificat astfel:

Browser
   ↓
WordPress Heartbeat
   ↓
POST /wp-admin/admin-ajax.php
   ↓
PHP / WordPress
   ↓
Răspuns JSON
   ↓
Browser

Conform documentației oficiale WordPress, intervalele Heartbeat pot fi cuprinse între aproximativ 15 și 120 de secunde, în funcție de context și configurație.

Fiecare request trebuie procesat de WordPress și de PHP, iar pluginurile pot adăuga propriile operațiuni în cadrul Heartbeat API.

La ce este folosit Heartbeat API?

Heartbeat API nu există doar pentru a genera request-uri. WordPress îl utilizează pentru funcționalități importante.

Printre acestea se pot afla:

salvarea automată a conținutului;
post locking atunci când mai mulți utilizatori încearcă să editeze același articol;
verificarea sesiunii de autentificare;
actualizarea anumitor informații din wp-admin;
comunicarea aproape în timp real între browser și server;
funcționalități implementate de pluginuri și teme.

Din acest motiv, dezactivarea completă a Heartbeat API nu trebuie făcută automat doar pentru că apar request-uri către admin-ajax.php.

Ce este admin-ajax.php?

Request-urile Heartbeat sunt procesate prin:

/wp-admin/admin-ajax.php

Acest fișier este endpoint-ul AJAX clasic al WordPress.

Este important însă să facem o diferență:

admin-ajax.php nu este utilizat exclusiv de Heartbeat API.

Pluginurile și temele WordPress îl pot utiliza pentru numeroase operațiuni AJAX, precum:

formulare;
filtre de produse;
căutări live;
încărcarea unor informații fără refresh;
operațiuni WooCommerce;
funcționalități din wp-admin;
request-uri personalizate ale pluginurilor.

Prin urmare, dacă observi sute sau mii de request-uri către:

admin-ajax.php

nu poți concluziona doar din URL că toate provin de la WordPress Heartbeat API.

Cum identifici request-urile WordPress Heartbeat?

Cea mai simplă metodă este utilizarea Developer Tools din browser.

Autentifică-te în WordPress și deschide:

Developer Tools → Network

Apoi filtrează request-urile după:

admin-ajax.php

Lasă pagina deschisă pentru câteva minute.

Dacă Heartbeat API este activ în acel context, vei observa request-uri POST periodice către:

/wp-admin/admin-ajax.php

Selectează unul dintre request-uri și verifică datele trimise.

Pentru Heartbeat vei putea identifica parametrul:

action=heartbeat

Acesta este un indicator mult mai precis decât simpla apariție a URL-ului admin-ajax.php.

De ce poate Heartbeat API să consume resurse?

Un request Heartbeat nu este doar un fișier static descărcat de browser.

Request-ul ajunge la WordPress, ceea ce presupune pornirea procesării PHP și încărcarea componentelor necesare aplicației.

În funcție de website, în timpul procesării pot fi încărcate:

WordPress Core;
pluginurile active;
anumite componente ale temei;
hook-uri adăugate de pluginuri;
operațiuni asupra bazei de date.

Dacă un singur administrator are o pagină deschisă, impactul este în general redus.

Situația se poate schimba însă atunci când există:

mai mulți administratori sau editori conectați;
mai multe tab-uri wp-admin deschise simultan;
un interval Heartbeat foarte redus;
pluginuri care execută operațiuni complexe la fiecare Heartbeat;
request-uri care durează mult;
un website deja foarte solicitat.

Exemplu: mai multe tab-uri WordPress deschise

Să presupunem că un utilizator are deschise simultan:

Dashboard
Editare articol
Editare pagină
WooCommerce
Pagina unui plugin

Dacă mai multe dintre aceste pagini execută Heartbeat, browserul poate genera request-uri periodice către server din fiecare context.

Dacă există și mai mulți utilizatori conectați simultan, numărul request-urilor poate crește.

Acest lucru nu înseamnă neapărat că va exista o problemă de performanță, însă merită investigat atunci când este corelat cu un consum ridicat de CPU sau Entry Processes.

Heartbeat API și LiteSpeed Cache

Pe serverele shared NameBox este utilizat LiteSpeed Enterprise, iar website-urile WordPress pot utiliza LiteSpeed Cache.

Page Cache este foarte eficient pentru paginile publice care pot fi livrate direct din cache fără executarea completă a WordPress.

Heartbeat funcționează însă prin request-uri POST către:

/wp-admin/admin-ajax.php

Aceste request-uri dinamice nu trebuie confundate cu accesarea unei pagini publice aflate în cache.

LiteSpeed Cache nu poate transforma pur și simplu un request Heartbeat într-o pagină statică din cache, deoarece browserul comunică dinamic cu aplicația.

Din acest motiv, un website poate avea un cache excelent pentru frontend și totuși să înregistreze activitate PHP în wp-admin.

Pentru mai multe informații despre LiteSpeed poți consulta articolul LiteSpeed vs Apache: Care este mai rapid?.

Cum verifici consumul de resurse în cPanel?

Pe serverele NameBox care utilizează cPanel și CloudLinux, consumul unui cont poate fi verificat direct din cPanel.

Accesează:

cPanel → Metrics → Resource Usage

Aici poți verifica valori precum:

CPU – consumul procesorului;
PMEM – memoria fizică;
I/O – viteza operațiunilor de citire și scriere;
IOPS – numărul operațiunilor I/O;
EP – Entry Processes;
NPROC – numărul proceselor.

CloudLinux este componenta care izolează și monitorizează resursele contului. Heartbeat API este o funcție WordPress care poate genera request-uri PHP, iar aceste request-uri pot contribui la resursele măsurate de CloudLinux.

Pentru un ghid detaliat poți consulta Monitorizare resurse cPanel.

Cum corelezi Heartbeat cu Resource Usage?

Nu modifica WordPress Heartbeat doar pentru că observi un consum ridicat.

Mai întâi încearcă să corelezi evenimentele.

De exemplu:

10:00 → consum normal
10:15 → utilizator intră în wp-admin
10:20 → mai multe tab-uri WordPress deschise
10:25 → CPU crește
10:30 → wp-admin este închis
10:35 → CPU revine la normal

Un astfel de comportament justifică o investigație suplimentară.

Dacă spike-ul de CPU apare însă în fiecare noapte la ora 02:00, iar nimeni nu utilizează wp-admin, este mult mai probabil să trebuiască investigate cron job-uri, backup-uri, importuri sau alte procese.

Pentru diferențiere poți consulta și articolul Cron Jobs în cPanel: Ce sunt și cum funcționează?.

Cum verifici admin-ajax.php în access log?

Dacă ai acces root la un server cPanel, poți verifica request-urile direct în logurile domeniului.

Într-un mediu cPanel, logurile domeniilor pot fi găsite în:

/var/log/apache2/domlogs/

Pentru un domeniu:

grep 'admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | tail -100

Pentru request-uri POST:

grep '"POST /wp-admin/admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | tail -100

Pentru a număra request-urile identificate în log:

grep '"POST /wp-admin/admin-ajax.php' /var/log/apache2/domlogs/exemplu.ro | wc -l

Înlocuiește:

exemplu.ro

cu domeniul investigat.

Access log-ul standard nu conține în mod normal corpul POST al request-ului. Prin urmare, din această linie nu poți determina întotdeauna dacă request-ul admin-ajax.php este Heartbeat sau o altă operațiune AJAX.

Pentru identificarea exactă a:

action=heartbeat

este mai simplu să utilizezi Developer Tools sau instrumente de debugging la nivel de WordPress.

Pentru mai multe exemple de analiză a logurilor poți consulta articolul Raw Access Logs și AWStats în cPanel.

admin-ajax.php consumă mult? Nu presupune că este Heartbeat

Aceasta este una dintre cele mai importante verificări.

Să presupunem că identifici:

5.000 request-uri → /wp-admin/admin-ajax.php

Acestea pot proveni de la:

Heartbeat API;
WooCommerce;
filtre de produse;
pluginuri de căutare;
formulare;
page builders;
pluginuri de statistică;
pluginuri de securitate;
alte funcționalități AJAX.

Reducerea Heartbeat nu va rezolva problema dacă majoritatea request-urilor provin de fapt de la un plugin.

Când merită să modifici WordPress Heartbeat?

Nu există un motiv să modifici Heartbeat API pe fiecare instalare WordPress.

Merită investigată frecvența atunci când:

wp-admin generează un consum ridicat și constant;
există mulți editori conectați simultan;
se observă foarte multe request-uri Heartbeat;
un plugin folosește Heartbeat pentru operațiuni costisitoare;
request-urile admin-ajax.php se suprapun;
Resource Usage indică spike-uri corelate cu activitatea wp-admin.

Dacă website-ul funcționează normal și nu există consum neobișnuit, nu este necesară optimizarea Heartbeat doar pentru a reduce numărul request-urilor.

Cum modifici intervalul Heartbeat fără să îl dezactivezi?

WordPress oferă filtrul:

heartbeat_settings

prin care intervalul poate fi modificat.

De exemplu:

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

În acest exemplu, intervalul este setat la:

60 secunde

WordPress documentează intervale Heartbeat între 15 și 120 de secunde.

Codul trebuie adăugat într-un plugin custom sau într-o zonă corespunzătoare de cod a website-ului. Dacă este introdus în functions.php, este recomandată utilizarea unei teme child pentru a evita pierderea modificării la actualizarea temei.

Nu recomandăm modificarea intervalului fără să existe mai întâi o problemă identificată.

Cum controlezi Heartbeat din LiteSpeed Cache?

Dacă website-ul utilizează pluginul LiteSpeed Cache for WordPress, există și o metodă grafică.

Accesează în WordPress:

LiteSpeed Cache → Toolbox → Heartbeat

În această zonă pot exista setări separate pentru:

Frontend Heartbeat;
Backend Heartbeat;
Editor Heartbeat.

LiteSpeed permite configurarea intervalului în intervalul:

15 – 120 secunde

În funcție de setare, valoarea:

poate dezactiva Heartbeat pentru zona respectivă.

Nu recomandăm setarea valorii 0 fără testare.

Documentația LiteSpeed avertizează că modificarea sau dezactivarea Heartbeat poate afecta task-uri WordPress declanșate prin AJAX.

Backend, Editor și Frontend Heartbeat

LiteSpeed Cache permite controlul separat pentru diferite zone tocmai pentru că impactul dezactivării poate fi diferit.

Editor Heartbeat

Este zona în care trebuie acordată cea mai mare atenție.

Editorul WordPress utilizează Heartbeat pentru funcții asociate cu:

autosave;
edit locking;
sincronizarea anumitor informații;
verificarea sesiunii.

Dezactivarea completă poate afecta experiența editorilor.

Backend Heartbeat

Acesta poate fi folosit în alte zone din wp-admin și de diferite pluginuri.

Dacă dorești să reduci frecvența, este preferabil să testezi mai întâi un interval mai mare în loc să îl dezactivezi complet.

Frontend Heartbeat

Unele pluginuri pot încărca Heartbeat și pe frontend pentru funcționalități dinamice.

Dacă un website nu utilizează astfel de funcții, impactul poate fi diferit față de editor, dar și această zonă trebuie testată înainte de dezactivare.

De ce nu recomandăm dezactivarea completă?

Poți găsi numeroase tutoriale care recomandă pur și simplu:

Disable WordPress Heartbeat

ca metodă de „optimizare”.

Această abordare este prea generală.

Heartbeat face parte din WordPress Core și poate fi utilizat atât de WordPress, cât și de pluginuri.

O dezactivare completă poate avea efecte precum:

autosave-ul nu mai funcționează corect;
edit locking nu mai funcționează normal;
anumite notificări din wp-admin nu se actualizează;
pluginurile care depind de Heartbeat pot avea probleme;
funcționalitățile AJAX asociate pot fi afectate.

O soluție mai sigură este:

identificare → măsurare → reducere interval → testare

și nu:

consum mare → dezactivare completă

Heartbeat API și eroarea 508 Resource Limit Is Reached

Pe un server CloudLinux, fiecare cont poate avea limite pentru resurse precum CPU, memorie, I/O, procese și Entry Processes.

Request-urile Heartbeat sunt request-uri dinamice și necesită procesare.

Dacă există suficient de multe request-uri simultane sau acestea rulează lent, pot contribui la consumul contului.

Totuși, Heartbeat nu trebuie considerat automat cauza unei erori 508.

Eroarea poate fi asociată și cu:

trafic ridicat;
boți;
pluginuri lente;
request-uri AJAX diferite de Heartbeat;
cron job-uri;
importuri;
interogări SQL lente;
API-uri externe;
procese PHP care rămân active prea mult.

Pentru o investigație completă poți consulta articolul Resource Limit Is Reached: Ce înseamnă eroarea 508?.

Heartbeat API și CPU ridicat în WordPress

Dacă observi CPU ridicat în Resource Usage, verifică dacă acesta coincide cu activitatea din wp-admin.

Un Heartbeat normal care se finalizează rapid nu ar trebui privit automat ca o problemă.

Este mai important timpul necesar pentru procesarea request-ului.

Dacă un plugin adaugă operațiuni complexe la fiecare Heartbeat, un simplu request poate implica:

mai multe interogări SQL;
procesarea unor date;
actualizarea unor opțiuni;
comunicarea cu un API extern;
executarea unor hook-uri suplimentare.

În această situație, problema reală poate fi pluginul sau codul executat la Heartbeat, nu API-ul WordPress în sine.

Cum identifici dacă un plugin contribuie la problemă?

Dacă ai confirmat că Heartbeat generează consum ridicat, următorul pas este identificarea componentelor care se execută odată cu request-ul.

Poți verifica:

pluginurile instalate recent;
pluginurile care afișează informații în timp real;
pluginurile de statistică;
pluginurile de backup;
pluginurile de securitate;
pluginurile WooCommerce;
funcții custom adăugate în functions.php;
pluginuri care folosesc hook-urile Heartbeat.

Nu dezactiva toate pluginurile direct pe un website de producție fără un plan de testare.

Ideal, verificarea se realizează într-un mediu de test sau prin dezactivarea controlată a componentelor suspecte.

Heartbeat API nu este WP-Cron

WordPress Heartbeat API și WP-Cron sunt două mecanisme diferite.

Heartbeat API presupune comunicarea periodică dintre browser și server atunci când o pagină care folosește Heartbeat este deschisă.

WP-Cron este sistemul WordPress pentru executarea task-urilor programate.

De exemplu:

Heartbeat:
Browser → admin-ajax.php → WordPress

WP-Cron:
Request WordPress → wp-cron.php → task programat

Ambele pot genera procesare PHP, dar trebuie investigate separat.

Ce rol are CloudLinux?

CloudLinux nu generează și nu controlează WordPress Heartbeat.

Rolul său este diferit.

CloudLinux permite izolarea conturilor și monitorizarea sau limitarea unor resurse precum:

CPU;
memorie;
I/O;
IOPS;
Entry Processes;
numărul proceselor.

Dacă un website generează multe request-uri PHP, indiferent dacă provin de la Heartbeat, vizitatori, boți sau cron-uri, acestea pot fi reflectate în consumul afișat în Resource Usage.

Pentru o explicație mai detaliată poți consulta articolul Resurse pachet găzduire: CPU, RAM, I/O și Entry Processes.

Ce rol are LiteSpeed?

LiteSpeed Enterprise este web serverul utilizat pe infrastructura shared NameBox.

LiteSpeed poate servi foarte eficient paginile cache-uite și poate reduce numărul execuțiilor PHP necesare pentru traficul public.

Totuși, request-urile POST și operațiunile dinamice precum Heartbeat trebuie tratate separat de page cache.

Din acest motiv, optimizarea WordPress trebuie analizată ca un ansamblu:

page cache;
PHP;
baza de date;
pluginuri;
AJAX;
Heartbeat;
cron job-uri;
resursele contului.

Poți consulta și ghidul nostru despre optimizarea WordPress.

Checklist: Heartbeat chiar este cauza consumului?

Înainte să modifici configurația, verifică următoarele:

Există multe request-uri către admin-ajax.php?
Request-urile conțin action=heartbeat?
La ce interval sunt trimise?
Câți utilizatori sunt conectați în wp-admin?
Există multe tab-uri WordPress deschise?
CPU crește exact în perioada respectivă?
Entry Processes cresc în același interval?
Request-urile durează mult?
Există pluginuri care folosesc Heartbeat?
Problema dispare atunci când wp-admin nu mai este utilizat?

Dacă răspunsul este da la mai multe dintre aceste întrebări, modificarea frecvenței Heartbeat poate merita testată.

Ce configurație recomandăm ca punct de pornire?

Nu există o valoare universală pentru toate website-urile WordPress.

Pentru un website care prezintă consum neobișnuit, abordarea recomandată este:

identifică mai întâi request-urile Heartbeat;
corelează ora cu Resource Usage;
identifică eventualele pluginuri implicate;
nu dezactiva Heartbeat dacă nu este necesar;
testează creșterea intervalului înainte de dezactivare;
acordă o atenție specială Heartbeat-ului din editor;
testează autosave și editarea articolelor după modificare.

Dacă utilizezi LiteSpeed Cache, poți începe verificarea din:

LiteSpeed Cache → Toolbox → Heartbeat

În loc să dezactivezi complet funcția, poți testa un interval mai mare și verifica ulterior Resource Usage.

Nu optimiza WordPress doar după numărul de request-uri

Două website-uri pot genera același număr de request-uri Heartbeat și pot avea un consum complet diferit.

Un request care se finalizează în câteva zeci de milisecunde nu are același impact ca unul care execută interogări lente și rămâne activ câteva secunde.

De aceea, investigația trebuie să coreleze:

număr request-uri
+
durată procesare
+
CPU
+
Entry Processes
+
pluginuri
+
bază de date

și nu doar numărul de accesări ale admin-ajax.php.

WordPress Heartbeat este util, dar trebuie monitorizat corect

WordPress Heartbeat API este o funcționalitate normală a WordPress și nu trebuie tratată automat ca o problemă de performanță.

În majoritatea cazurilor, request-urile periodice au un rol util și permit funcționarea corectă a unor componente din wp-admin.

Problemele pot apărea atunci când există multe sesiuni simultane, intervale foarte scurte sau pluginuri care execută operațiuni costisitoare la fiecare Heartbeat.

Pe infrastructura NameBox, consumul poate fi corelat cu datele din cPanel → Resource Usage, iar website-urile care utilizează LiteSpeed Cache pot controla separat Heartbeat pentru frontend, backend și editor.

Înainte să dezactivezi funcția, identifică exact request-urile, verifică impactul asupra CPU și proceselor și testează mai întâi reducerea frecvenței.

Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel.