Admin-ajax.php consuma troppe risorse: trovare plugin e richieste responsabili

Nei log del server compaiono molte richieste verso wp-admin/admin-ajax.php, la CPU aumenta e il backend rallenta. Bloccare quell’URL non è una soluzione: è l’endpoint attraverso cui WordPress, temi e plugin gestiscono numerose operazioni asincrone. Bisogna identificare quale azione viene richiesta, con quale frequenza e quanto lavoro produce sul server.

Se hai bisogno di supporto tecnico, puoi consultare i servizi di assistenza WordPress e di assistenza per e-commerce esistenti.

Una richiesta AJAX non è necessariamente pesante. Il problema può essere il numero di chiamate, il codice eseguito da una specifica action, una query lenta, più schede amministrative aperte o traffico automatico che richiama un endpoint pubblico.

Perché WordPress usa admin-ajax.php

WordPress instrada attraverso admin-ajax.php molte interazioni che devono inviare o recuperare dati senza ricaricare l’intera pagina. L’endpoint può essere usato nel pannello amministrativo e nel frontend, anche se il percorso contiene wp-admin.

Fra gli utilizzi possibili rientrano:

• salvataggi e controlli dell’editor;
• aggiornamenti periodici dell’interfaccia;
• filtri, ricerche e caricamenti dinamici;
• richieste di plugin ecommerce o moduli;
• azioni personalizzate accessibili agli utenti autenticati;
• endpoint pubblici registrati tramite hook dedicati.

Il nome del file nei log non rivela quale funzione PHP sia stata eseguita. Per arrivare alla causa serve leggere il parametro action della richiesta e collegarlo al codice che registra il relativo handler.

Heartbeat API e richieste AJAX periodiche

La Heartbeat API è un sistema di polling integrato in WordPress. La documentazione ufficiale indica che il browser invia periodicamente dati al server tramite un handler di admin-ajax, con intervalli che possono variare fra 15 e 120 secondi.

Heartbeat supporta funzioni utili come aggiornamenti quasi in tempo reale e coordinamento delle sessioni editoriali. Se più utenti tengono aperte diverse schede del backoffice, le richieste possono aumentare. Tuttavia vedere action=heartbeat non dimostra che Heartbeat sia l’unico problema: plugin e personalizzazioni possono aggiungere elaborazioni ai suoi eventi.

Disabilitare completamente Heartbeat può compromettere funzioni che ne dipendono. Prima di limitarne la frequenza bisogna misurare costo, contesto e funzionalità coinvolte.

Come individuare l’action che consuma CPU

L’analisi parte dai log HTTP e applicativi. Per ogni richiesta sono utili almeno orario, durata, codice di risposta, dimensione, IP, user agent, metodo e parametro action. Se il server registra soltanto il percorso, può essere necessario attivare temporaneamente una diagnostica più precisa nel rispetto dei dati trattati.

Una procedura efficace comprende:

1. raggruppare le richieste per action;
2. misurare frequenza e durata di ogni gruppo;
3. distinguere utenti autenticati, frontend e traffico automatico;
4. associare l’action al plugin, tema o codice custom;
5. profilare query, chiamate HTTP e funzioni eseguite;
6. ripetere il test dopo una sola modifica.

Un’action molto frequente ma rapida può incidere meno di una chiamata sporadica che esegue query costose. Allo stesso modo, un picco provocato da un crawler richiede una risposta diversa rispetto a un autosalvataggio usato da dieci redattori.

Plugin WordPress e handler AJAX inefficienti

Un handler può rallentare perché recupera troppi dati, ripete query in un ciclo, chiama un servizio esterno senza timeout adeguato oppure rigenera a ogni richiesta informazioni che potrebbero essere riutilizzate. La diagnosi deve quindi collegare la richiesta al comportamento interno.

I segnali da cercare includono:

• query identiche ripetute durante la stessa action;
• scansioni di grandi tabelle senza filtri selettivi;
• chiamate esterne sincrone;
• elaborazioni avviate anche quando i parametri non lo richiedono;
• risposte molto grandi;
• action frontend prive di controlli contro abuso e ripetizione;
• polling con intervallo non proporzionato all’utilità.

L’articolo su plugin WordPress, database e query lente approfondisce la parte relativa al database. Nel caso AJAX va aggiunta anche la frequenza: una query moderatamente costosa diventa critica se viene eseguita molte volte al minuto.

Traffico anomalo verso admin-ajax.php

Alcune action sono accessibili anche agli utenti non autenticati. Questo è necessario per moduli, filtri o altre funzioni pubbliche, ma può esporre un’elaborazione a bot e richieste ripetute. Non bisogna bloccare tutto admin-ajax.php; occorre proteggere l’action specifica senza interrompere quelle legittime.

Le contromisure dipendono dal caso e possono includere controlli applicativi, nonce quando appropriati, validazione degli input, rate limiting a livello infrastrutturale o una diversa architettura dell’endpoint. Un nonce WordPress aiuta a verificare l’intenzione della richiesta, ma non sostituisce autorizzazione e controllo delle capacità per operazioni riservate.

Prima di creare regole WAF bisogna conoscere metodi, parametri e utenti leciti. Una regola troppo ampia può rompere checkout, moduli o pannelli amministrativi senza ridurre il costo della funzione responsabile.

Quando limitare Heartbeat e quando correggere il plugin

Ridurre la frequenza di Heartbeat ha senso se le misurazioni dimostrano che il polling è troppo aggressivo rispetto all’uso reale e se le funzioni editoriali restano operative. È invece un rimedio parziale quando un plugin collega a ogni battito una funzione inefficiente.

Correggere o sostituire il plugin è più appropriato quando l’action esegue lavoro non necessario, non scala con il volume dei dati o non gestisce correttamente errori e timeout. Nei progetti custom può essere utile spostare operazioni lunghe in una coda, restituire subito una risposta e monitorare separatamente il processo.

La cache può ridurre alcune letture, ma non va applicata automaticamente a dati personalizzati o sensibili. Un endpoint dinamico richiede una strategia coerente con autenticazione, aggiornamenti e invalidazione.

Quando richiedere una diagnosi di admin-ajax.php

Serve un intervento tecnico quando il provider segnala consumo elevato, il backend rallenta con più utenti, i processi PHP si saturano o una singola action domina i log. Il lavoro utile non è nascondere l’endpoint, ma attribuire il carico e correggere la funzione responsabile.

Se admin-ajax.php sta consumando risorse sul tuo sito, posso analizzare log, action, plugin, query e traffico per distinguere Heartbeat, codice inefficiente e richieste anomale.

Ti auguro buona lettura e mi raccomando, se dopo aver letto questo articolo hai bisogno di aiuto non esitare a contattarmi.

Autore: Graziano De Maio | Titolare di Gdmtech