Vai al contenuto 
L'API Heartbeat di WordPress causa silenziosi ping AJAX frequenti tramite admin-ajax.php sull'hosting condiviso. Carico del server e provoca un notevole rallentamento nel backend. Vi mostrerò come ridurre in modo sicuro la frequenza degli heartbeat, diminuire il carico del server WordPress e mantenere funzioni importanti come il salvataggio automatico.
Punti centrali
- Frequenza cardiaca Prorogare in modo mirato anziché disattivare completamente.
- Salvataggio automatico Salvare nell'editor, interrompere i ping non necessari.
- Risorse condivise Proteggere: CPU, RAM, I/O sotto controllo.
- Monitoraggio prima/dopo l'ottimizzazione per effetti chiari.
- Olistico Ottimizzazione: cache, DB, CDN, versione PHP.
Comprendere Heartbeat: una funzione utile ma costosa
L'API Heartbeat invia richieste AJAX periodiche, in genere ogni 15 secondi nella dashboard, per mantenere le sessioni e salvare le bozze; queste Frequenza ha però un prezzo. Ogni ping colpisce admin-ajax.php e attiva processi PHP, accessi al database ed eventualmente plugin hook. Se il browser rimane minimizzato, la comunicazione spesso continua e genera picchi di carico. Le schede aperte moltiplicano le richieste e rallentano il tempo di risposta dell'editor. Su sistemi fortemente condivisi, ciò porta a processi rallentati, salvataggi automatici ritardati e un lavoro soggettivamente „difficile“.
Perché lo shared hosting ne risente particolarmente
Con l'hosting condiviso condivido CPU, RAM e I/O con i siti vicini, motivo per cui le richieste aggiuntive possono rallentare il Capacità esaurirsi più rapidamente. Se più utenti si collegano contemporaneamente o se la dashboard rimane aperta per ore, i ping si sommano e bloccano i worker PHP. Di conseguenza, il TTFB e i tempi di attesa nell'amministrazione aumentano e il carico del server WordPress raggiunge brevi picchi. In caso di carichi simultanei da siti vicini, si verifica una reazione a catena: i cache hit diminuiscono, i blocchi del database aumentano e l'editor appare lento. In questo modo trasformo involontariamente una funzione di comfort in una fonte di carico.
Riconoscere i sintomi tempestivamente
Se noto clic lenti nel backend, un numero anomalo di richieste POST nei DevTools e input discontinui nell'editor, è probabile che la causa sia da ricercarsi nei ping heartbeat. Autisti Anche gli avvisi dell'host relativi a picchi di CPU o limiti di memoria rientrano in questo quadro. Anche Core Web Vitals più deboli nel contesto amministrativo e punteggi PageSpeed in calo possono essere segnali indiretti. Nei log vedo un accumulo di accessi admin-ajax.php con azione „heartbeat“. Se questi effetti si verificano durante l'elaborazione inattiva, le schede in background sprecano risorse preziose.
Quante richieste vengono effettivamente generate? Un breve calcolo
Un intervallo standard di 15 secondi genera quattro ping al minuto per ogni scheda. Tre schede amministrative aperte significano quindi 12 richieste di heartbeat al minuto per ogni redattore. Se due persone lavorano in parallelo, il numero sale a 24 al minuto, ovvero 1.440 all'ora. Impostando l'intervallo nell'amministrazione a 60 secondi, riduco lo stesso carico a tre ping al minuto per persona. Nell'esempio sopra riportato, il numero scende da 24 a 6 al minuto: una riduzione del 75 %. Questo semplice calcolo spiega perché il tempo di risposta percepito migliora significativamente dopo una limitazione.
Assumere il controllo: plugin o codice
Per prima cosa mi baso su una regola chiara: aumentare la frequenza invece di agire alla cieca. spegnere. Con strumenti come Heartbeat Control, WP Rocket o LiteSpeed Cache, imposto 30-60 secondi nell'amministrazione, 120-180 secondi nel frontend e disattivo i ping sulle pagine senza interazione. Chi preferisce il codice può rallentare l'API in modo selettivo. Esempio: impostare gli intervalli su 60 secondi e lasciare solo il salvataggio automatico nell'editor. In questo modo riduco il carico senza compromettere la sicurezza dei contenuti.
// Modifica degli intervalli add_filter('heartbeat_settings', function($settings) { $settings['interval'] = 60; // secondi return $settings; });
// Disattivare Heartbeat, ad esempio nel frontend add_action('init', function() { if ( ! is_admin() ) wp_deregister_script('heartbeat'); }, 1);
Editor a blocchi vs. Classico: cosa fa realmente Heartbeat nell'editor
Nell'editor classico, il salvataggio automatico si basa direttamente su Heartbeat. Nell'editor a blocchi (Gutenberg), il salvataggio automatico funziona principalmente tramite l'API REST, ma Heartbeat continua a svolgere compiti importanti come il post-locking e i controlli di sessione. Conclusione pratica: un prolungamento moderato (30-60 s) non interrompe il salvataggio automatico nell'editor a blocchi, ma può ritardare l'aggiornamento dei blocchi e dei messaggi di stato. Per questo motivo, nell'editor scelgo intervalli più brevi rispetto al resto dell'amministrazione e verifico con bozze reali se i blocchi e gli avvisi funzionano come previsto.
Limitazione selettiva in base allo schermo e al ruolo
Per ottenere il massimo controllo, regolo Heartbeat in base allo schermo (Screen) e, se necessario, ai ruoli degli utenti. In questo modo l'editor rimane veloce, mentre le aree amministrative tranquille non generano praticamente alcun ping.
// 1) Intervalli diversi a seconda dello schermo 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: più frequente per autosave/locking
} else { $settings['interval'] = 60; // resto dell'amministratore } } return $settings; }); // 2) Caricare Heartbeat nell'amministratore solo dove necessario add_action('admin_enqueue_scripts', function($hook) {
$allowed = ['post.php', 'post-new.php', 'site-editor.php']; // Contesti editor if ( ! in_array($hook, $allowed, true) ) { wp_deregister_script('heartbeat'); } }, 1);
// 3) Trattare il frontend in modo differenziato (ad es. per gli utenti registrati) add_action('wp_enqueue_scripts', function() { if ( ! is_user_logged_in() ) { wp_deregister_script('heartbeat'); // Visitatori: nessun heartbeat necessario } }, 1);
// Opzionale: armonizzare l'intervallo di salvataggio automatico add_filter('autosave_interval', function() { return 60; });Con questa configurazione, le funzioni live rimangono attive dove sono utili e scompaiono nelle aree senza interazione. Nel contesto dello shop o del checkout, mantengo Heartbeat attivo in modo mirato e breve, mentre nel resto del frontend rimane disattivato.
Intervalli ragionevoli ed eccezioni
Mantengo l'editor funzionante mentre elimino i ping non necessari dalle pagine tranquille, perché Salvataggio automatico rimane essenziale. 60 secondi nell'amministrazione spesso rappresentano il punto di equilibrio ideale tra sicurezza e carico. Nel frontend, di solito non ho bisogno di Heartbeat, ad eccezione dei componenti live. Per i negozi online o le interfacce utente dinamiche, pianifico cicli più brevi solo dove vengono eseguiti gli input. In questo modo il sito rimane veloce e stabile, senza compromettere i contenuti.
| Contesto | Intervallo consigliato | Suggerimento |
|---|---|---|
| Dashboard in generale | 60 s | Carico diminuisce notevolmente, le sessioni rimangono attive. |
| Post-editor | 30–60 s | Autosave e Locking ancora utilizzabili. |
| Frontend statico | Disattivare | Nessuna interazione, quindi nessun ping necessario. |
| Frontend interattivo (ad es. checkout) | 15–30 s | Solo su interessati Pagine attivare. |
| Schede amministrative aperte a lungo | 90–120 s | Risparmia risorse quando la scheda rimane in background. |
Ottimizzazione del payload Heartbeat: meno dati per ogni ping
Oltre alla frequenza, conta anche la quantità di dati trasmessi. Alcuni plugin aggiungono informazioni aggiuntive a Heartbeat. Tramite i filtri posso ridurre ulteriormente il carico del server, eliminando il payload superfluo o semplificando le risposte.
// 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);Successivamente controllo la dimensione delle risposte heartbeat nei DevTools. Se il payload si riduce, il database e PHP vengono alleggeriti, soprattutto nelle ore di punta.
Ottimizzazione completa: caching, DB, media, PHP
Heartbeat è un tassello del puzzle, ma ottengo risultati concreti solo quando combino caching, manutenzione del database e ottimizzazione dei media per ottenere il massimo. Carico ridurre ulteriormente. Il caching delle pagine e degli oggetti riduce le query al database nel flusso amministrativo. Riduco sistematicamente le immagini e attivo il lazy loading. Pulisco regolarmente revisioni, transienti e sessioni. Inoltre, controllo la versione PHP e rimuovo i componenti aggiuntivi non necessari; approfondisco l'argomento con questa guida su Antipattern dei plugin.
Nel database faccio attenzione alle opzioni autoloaded, alle revisioni gonfiate e ai transienti obsoleti. Un limite massimo per le revisioni impedisce una crescita incontrollata senza compromettere la sicurezza. Il caching degli oggetti (ad es. Redis) è particolarmente utile nell'area amministrativa, perché le richieste ricorrenti trovano più rapidamente i loro dati. Inoltre, un numero inferiore di plugin attivati significa meno hook che possono essere attivati da ogni chiamata heartbeat.
WP-Cron e Heartbeat: unire le due cose
Molte installazioni utilizzano Heartbeat indirettamente, mentre WP-Cron attiva attività in parallelo, il che nei momenti di picco può causare il Lavoratore inoltre. Controllo quindi i cron job, riassumo le frequenze ed evito eventi non necessari. In caso di carico costante, passo al cron di sistema reale e disattivo le chiamate wp-cron.php da parte dei visitatori. Ciò stabilizza i tempi di risposta e protegge l'interfaccia di amministrazione. Chi desidera approfondire l'argomento troverà consigli pratici nel mio articolo su Ottimizzare WP-Cron.
PHP Worker, concorrenza e code AJAX
Le richieste AJAX sono in concorrenza con le visualizzazioni delle pagine, motivo per cui un numero limitato di worker PHP può tempo di attesa notevolmente aumentato. Se le chiamate heartbeat si accumulano, il backend sembra bloccarsi, anche se il server rimane raggiungibile. Pertanto, punto a ping meno frequenti ma più significativi e a cache che alleggeriscano il carico di PHP. Quando i progetti crescono, valuto contingenti di worker più elevati o cambio tariffa. Chi desidera comprendere l'interazione può leggere la mia guida su Equilibrio dei worker PHP.
Comportamento di navigazione e utilizzo: schede in background e limitazione del timer
I browser moderni limitano i timer nelle schede in background, ma le chiamate heartbeat non scompaiono completamente, diventano solo più rare. Il fattore decisivo è il numero di finestre, profili e dispositivi aperti contemporaneamente. Sensibilizzo i redattori: chiudere le schede di amministrazione non necessarie, evitare lunghi periodi di inattività e, in caso di dubbio, salvare le bozze prima di lasciare il posto di lavoro. La limitazione tecnica tramite codice integra in modo ottimale queste regole di comportamento.
Ricerca degli errori: conflitti tipici e test sicuri
Se dopo una limitazione si verificano dei problemi, controllo innanzitutto: il post-locking funziona? I timeout di sessione vengono ancora segnalati? Il checkout nei moduli in tempo reale funziona in modo stabile? Disattivo temporaneamente singole fasi di ottimizzazione, eseguo test con diversi ruoli e passo dall'editor classico a quello a blocchi. In DevTools filtro la rete per „action=heartbeat“ e osservo l'intervallo, la durata e la dimensione. Dal lato server, i log PHP e di errore forniscono indicazioni nel caso in cui gli hook dei plugin rallentino Heartbeat in modo imprevisto.
Monitoraggio e piano di test: come misuro l'effetto
Inizio con un profilo precedente: numero di richieste admin-ajax.php al minuto, percentuale di CPU, RAM e tempo di risposta dell'editor per Base . Successivamente, imposto nuovi intervalli e ripeto le misurazioni con lo stesso utilizzo. Nel browser DevTools verifico se i ping sono meno frequenti e più rapidi. Nel pannello di hosting osservo se i picchi di carico si appiattiscono. Solo quando i risultati sono stabili, trasferisco le impostazioni sui sistemi live.
Valori target e valutazione
Come obiettivo nell'amministrazione mi propongo: intervallo di 60 s sugli schermi generali, 30-60 s nell'editor, meno di 300 ms TTFB per le risposte heartbeat e una dimensione media di risposta inferiore a 10 KB, a seconda dei plugin. Sotto carico (più utenti, più schede) non dovrebbero verificarsi lunghe code; il carico di lavoro dei worker rimane uniforme, invece di diventare irregolare. Se raggiungo questo obiettivo, il team editoriale noterà immediatamente la differenza.
Quando è opportuno effettuare un upgrade dell'hosting
Anche con una configurazione corretta, un progetto può utilizzare le risorse comuni di un piano tariffario. esplodere. Più redattori simultanei, checkout dello shop, ricerca o widget di chat aumentano il carico AJAX. In questi casi calcolo i costi: perdita di tempo nel team vs. sovrapprezzo per più lavoratori, RAM e CPU. Spesso vale la pena effettuare un aggiornamento non appena i redattori vengono bloccati quotidianamente. Inizio con il piano successivo e verifico se l'elaborazione rimane fluida.
Riassumendo brevemente
L'API Heartbeat offre preziose funzionalità in tempo reale, ma appesantisce l'hosting condiviso se non imposto intervalli e contesti. controllo. Con cicli più lunghi nell'amministrazione, frontend disattivato e salvataggio automatico attivo nell'editor, riduco notevolmente le richieste. Il caching, l'ordine del database, i plugin snelli e una versione PHP aggiornata stabilizzano ulteriormente il sistema. In combinazione con un WP-Cron pulito e un numero sufficiente di PHP-Worker, i clic lenti nel backend scompaiono. In questo modo mantengo il comfort e la sicurezza e allo stesso tempo riduco il carico sul mio hosting.
