Plugin WordPress che rallentano il sito
Cos’è il rallentamento da plugin e perché succede
Quando un sito WordPress rallenta progressivamente man mano che si installano nuovi plugin, la causa non è “avere troppi plugin” in senso numerico — un sito può avere trenta plugin leggeri e restare veloce, o un solo plugin scritto male e diventare lento. Il vero fattore è cosa fa davvero ogni singolo plugin a ogni caricamento di pagina: quante query al database esegue, quanti file carica e se fa chiamate verso servizi esterni durante il caricamento.
La causa più comune: query al database lente o ripetute a ogni caricamento
Il motivo più frequente per cui un plugin rallenta un sito WordPress è l’esecuzione di query al database non ottimizzate, o eseguite più volte quando basterebbe una sola volta, a ogni singola visualizzazione di pagina. Un plugin che, per mostrare un widget “articoli correlati” o un contatore, interroga il database con query complesse su tabelle non indicizzate correttamente, aggiunge un ritardo misurabile a ogni pagina del sito, non solo a quella dove il widget compare.
Seconda causa frequente: script e CSS caricati su tutte le pagine (nominata)
Molti plugin caricano i propri file CSS e JavaScript su ogni pagina del sito per sicurezza, anche quando la funzionalità serve solo su una pagina specifica (es. un plugin di form di contatto che carica il proprio script anche in home page, dove il form non compare). Questo aumenta il peso e il numero di richieste di ogni pagina, anche di quelle che non usano affatto quella funzionalità.
Causa meno comune: chiamate esterne sincrone durante il caricamento (nominata)
Un caso meno frequente ma più critico quando si presenta è un plugin che, durante il caricamento della pagina, contatta un servizio esterno in modo sincrono (es. verifica della licenza, recupero di contatori social, controllo aggiornamenti) e attende la risposta prima di proseguire: se quel servizio esterno è lento o irraggiungibile, l’intero caricamento della pagina si blocca per l’intera durata del timeout.
Come capire quale plugin sta rallentando il sito
Indovinare quale plugin sia responsabile disattivandoli a caso è inefficiente e rischioso su un sito in produzione. Il modo affidabile è misurare cosa fa davvero ogni plugin con uno strumento di diagnostica dedicato.
Step 1: installare Query Monitor e leggere il pannello delle query
Query Monitor è un plugin di diagnostica gratuito che mostra, per ogni caricamento di pagina, quante query al database sono state eseguite, quanto tempo hanno impiegato e — soprattutto — quale plugin le ha generate. Il test è a esito binario: se nel pannello “Queries by Component” un singolo plugin risulta responsabile di una quota sproporzionata del tempo totale di query (es. oltre il 40-50% del tempo, con query dal tempo superiore a 50-100 millisecondi ciascuna), quel plugin è la causa confermata; se le query sono distribuite in modo uniforme tra molti componenti diversi, il rallentamento ha probabilmente un’altra origine, come il tema o l’hosting stesso.
Step 2: verificare se il rallentamento è su tutte le pagine o solo alcune
Query Monitor mostra anche gli script e gli stili caricati (Scripts e Styles nel menu della barra di amministrazione) per la pagina corrente: se un plugin compare nell’elenco anche in pagine dove la sua funzionalità non è utilizzata, quello è un segnale di script caricati ovunque invece che solo dove servono. Va confrontato lo stesso pannello tra una pagina lenta e una pagina più veloce dello stesso sito per capire se la differenza dipende da un plugin specifico attivo solo su alcune pagine (es. un plugin ecommerce sulle pagine prodotto) o da un plugin che pesa ovunque allo stesso modo.
| Sintomo osservato | Causa probabile |
|---|---|
| Un plugin domina il tempo totale query in Query Monitor (>40-50%) | Query al database lente o ripetute generate da quel plugin |
| Stesso plugin compare tra gli script caricati anche su pagine dove non serve | Script/CSS enqueued globalmente invece che solo sulle pagine necessarie |
| TTFB alto su tutte le pagine, tempo query invece basso | Il collo di bottiglia è altrove (hosting, PHP, configurazione server), non i plugin |
| Rallentamento presente solo su pagine specifiche (es. pagine prodotto, pagine con form) | Plugin attivo/pesante solo su quel tipo di contenuto, non globale |
| Pagina che si blocca per alcuni secondi in modo incostante, non sempre uguale | Chiamata esterna sincrona di un plugin verso un servizio che risponde in modo variabile |
Vale anche la pena controllare se il sito usa un object cache persistente (Redis o Memcached): senza di esso, query ripetute che potrebbero essere messe in cache vengono rieseguite a ogni caricamento, amplificando l’effetto di un plugin già inefficiente — una variabile spesso trascurata quando si valuta “quanto pesa” un singolo plugin.
Risolvere il rallentamento: isolare e sostituire il plugin responsabile
Per il caso più comune — un plugin con query al database lente identificato tramite Query Monitor — il percorso più diretto è confermare l’impatto reale prima di decidere se disattivarlo o sostituirlo.
Step 1: disattivare temporaneamente solo il plugin sospettato
Su un ambiente di staging, o in un momento di basso traffico se non è disponibile uno staging, disattivare temporaneamente solo il plugin identificato da Query Monitor e ricaricare la stessa pagina misurando il tempo di caricamento totale con lo stesso strumento (o con PageSpeed Insights).
Step 2: confrontare il tempo query prima e dopo
Se il tempo totale delle query cala in modo significativo dopo la disattivazione, l’impatto del plugin è confermato numericamente, non solo percepito. A questo punto va valutato se la funzionalità di quel plugin è indispensabile: se lo è, si cerca un’alternativa più leggera con la stessa funzione; se non lo è, si rimuove definitivamente.
Step 3: se il plugin è necessario, limitarne il caricamento alle pagine giuste
Quando il plugin va mantenuto ma carica script/CSS ovunque, molti plugin offrono un’impostazione per limitare il caricamento alle sole pagine dove serve (es. solo sulla pagina “Contatti” per un plugin di form); in assenza di questa opzione nel plugin stesso, un plugin “asset manager” dedicato permette di disattivare manualmente lo script di quel plugin sulle pagine dove non è necessario.
Verifica finale osservabile
Dopo l’intervento, ripetere la lettura di Query Monitor sulla stessa pagina: il tempo totale di query deve mostrare una riduzione misurabile in millisecondi, non una semplice impressione soggettiva di maggiore velocità, e il plugin corretto non deve più comparire tra gli script caricati sulle pagine dove non è utilizzato.
Caso particolare: rallentamento dopo un aggiornamento di un plugin già installato
Quando il sito rallenta improvvisamente senza aver installato nulla di nuovo, ma dopo un aggiornamento automatico di un plugin esistente, la causa più probabile è che quella versione abbia introdotto nuove query o nuove chiamate esterne non presenti nella versione precedente. In questo scenario il changelog del plugin (visibile nella pagina del plugin su WordPress.org o nel pannello di WordPress) spesso indica esplicitamente nuove funzionalità aggiunte, utile per capire cosa verificare per primo con Query Monitor.
Non riesci a capire quale plugin rallenta il sito? Intervento tecnico a distanza
Isolare con precisione l’impatto di un plugin richiede di leggere correttamente i dati di Query Monitor e confrontarli in modo sistematico tra pagine diverse, un lavoro che richiede tempo se fatto per la prima volta. Se dopo aver provato non riesci a individuare con certezza il responsabile, o preferisci non rischiare di disattivare plugin critici su un sito in produzione, è possibile richiedere una verifica diretta: invia l’accesso al sito e viene eseguita un’analisi con strumenti di profiling per individuare esattamente quale plugin, quale query o quale chiamata esterna sta rallentando le pagine.
Domande frequenti sui plugin che rallentano WordPress
Avere molti plugin installati (anche disattivati) rallenta il sito? I plugin disattivati non eseguono codice a ogni caricamento pagina, quindi non incidono sulla velocità di per sé, ma vale la pena rimuoverli comunque: occupano spazio e possono rappresentare un rischio di sicurezza se non aggiornati.
Query Monitor stesso rallenta il sito se lasciato attivo? Sì, seppur in modo contenuto: essendo uno strumento di diagnostica aggiunge un piccolo overhead di misurazione. Va usato per la diagnosi e poi disattivato (o limitato al proprio utente amministratore) su un sito in produzione con traffico reale.
Come faccio a sapere se un plugin è “leggero” prima di installarlo? Non esiste una garanzia assoluta prima dell’uso reale sul proprio sito, ma la pagina del plugin su WordPress.org, le recensioni e la frequenza degli aggiornamenti danno un’indicazione; la verifica definitiva resta comunque misurare l’impatto reale con Query Monitor dopo l’installazione.
Un plugin di cache risolve il problema di un plugin lento? Solo in parte: la cache di pagina evita di rieseguire query per i visitatori che vedono una pagina già in cache, ma non risolve il problema per le pagine dinamiche (carrello, form, aree utente) dove la cache non si applica, e il plugin lento continuerà a pesare lì.
Perché il sito è lento solo per gli utenti loggati (es. amministratori)? Perché le pagine cache-ate normalmente servono ai visitatori non loggati, mentre chi è autenticato riceve quasi sempre una versione non cache-ata della pagina: se il rallentamento sparisce da disconnessi, la causa è quasi certamente legata alla cache che maschera il problema solo per i visitatori normali.
Vuoi risolverlo con un intervento diretto? Se preferisci non passare ore a leggere query e confrontare pagine da solo, → Contatta il servizio tecnico: invia l’accesso al sito e viene individuato con precisione quale plugin, query o chiamata esterna sta causando il rallentamento, con la correzione applicata senza disattivare funzionalità necessarie.