Pregi e difetti di WordPress Heartbeat API

I motivi hanno portato allo sviluppo di questa API, introdotta con la versione 3.6 di WordPress, sono bloccare automaticamente un articolo quando più di un utente tenta di modificarlo e avvisare quando la sessione di log-in è scaduta. Heartbeat si è poi evoluto diventando un vero e proprio sistema di monitoraggio delle attività svolte sul nostro sito, lato backend. Viene migliorata la gestione delle sessioni utente e delle revisioni dei post, è stato introdotto il salvataggio automatico delle bozze, il logout degli amministratori dopo un periodo di inattività e altro ancora.

Azioni comunicate al server tramite una routine di invio dati, un processo ripetuto ad intervalli regolari come i battiti che costituiscono il ciclo cardiaco ed ecco spiegato il nome della API. Il tutto si svolge in background, quasi sempre automaticamente, ed è per questo la maggior parte delle volte che utilizziamo WordPress non ce ne accorgiamo.

Un grande strumento che in alcune situazioni può causare dei problemi. Heartbeat effettua controlli periodici (sulla modifica dei post ogni 15 secondi, sulla Dashboard ogni minuto, ecc) che generano una richiesta POST al server, generalmente innocua, ma che impegna la CPU per un determinato lasso di tempo. Il problema nasce quando il numero di utenti che accede al backend è elevato (è il caso di magazine, blog multi autore e via dicendo) poiché aumenta il numero di impulsi generati dalla API e di conseguenza l’uso delle risorse del server.

Se un fornitore di hosting web pone dei limiti sul numero di processi o di risorse utilizzabili, si potrebbe facilmente superarli incorrendo nella sospensione del servizio.

Il consiglio è quello di installare il plugin Heartbeat Control che vi permette di disattivare completamente Heartbeat, limitarne l’utilizzo su tutto il sito tranne post.php e post-new.php o passare da 15 a 60 secondi di tempo i controlli per non abusare delle risorse del server.