Per molti proprietari di siti WordPress, ottimizzare le prestazioni significa installare un plugin. WP Rocket, LiteSpeed Cache, Perfmatters, W3 Total Cache, Autoptimize, FlyingPress e molti altri promettono pagine più veloci, punteggi di PageSpeed più alti e Core Web Vitals nello stato buono con pochi clic. Alcuni mantengono in buona parte la promessa, altri meno, e quasi tutti possono fare danni se configurati senza capire cosa fanno.
In questo articolo non facciamo una classifica: le funzioni si sovrappongono, le versioni cambiano e il plugin migliore dipende dal server, dal tema e dal resto del sito. Vediamo invece cosa fanno davvero queste funzioni, quali hanno un effetto concreto sulle metriche degli utenti e quali soprattutto sui punteggi, come evitare conflitti e rotture, e una pratica che in questo settore circola più di quanto si pensi: il cloaking delle prestazioni, cioè servire ai test una pagina diversa da quella che ricevono gli utenti.
Tre famiglie di plugin
Sotto l’etichetta generica di «plugin di ottimizzazione» convivono strumenti con scopi diversi, e confonderli è la prima causa di configurazioni sbagliate.
- Plugin di cache completi. Offrono una cache di pagina e, intorno a questa, una serie di ottimizzazioni del front-end. WP Rocket gestisce la cache di pagina direttamente, con file statici serviti dal server; LiteSpeed Cache usa la cache integrata nei server LiteSpeed, e senza un server compatibile, o il servizio QUIC.cloud, la sua cache di pagina non è disponibile, anche se restano molte funzioni di ottimizzazione. W3 Total Cache e WP Super Cache appartengono alla stessa famiglia.
- Plugin di rifinitura del front-end. Non gestiscono la cache di pagina, ma intervengono su ciò che la pagina carica: disattivazione di script e stili pagina per pagina, rimozione di funzioni superflue di WordPress, ritardo del JavaScript, ottimizzazione di font e immagini. Perfmatters è l’esempio più noto, pensato per essere affiancato a una soluzione di cache.
- Plugin specializzati. Ottimizzazione delle immagini, aggregazione e minificazione dei file, generazione del CSS critico, pulizia del database. Fanno una cosa sola, e spesso si sovrappongono alle funzioni dei plugin delle altre famiglie.
Molti hosting gestiti offrono inoltre una cache di pagina a livello di server, con Varnish, Nginx o LiteSpeed, come abbiamo visto nell’articolo su TTFB e cache di pagina. In quel caso, attivare anche la cache di un plugin è inutile nel migliore dei casi e dannoso nel peggiore: due livelli di cache da svuotare, comportamenti imprevedibili, pagine vecchie servite dopo un aggiornamento.
Le funzioni, una per una
Al di là dei nomi commerciali, le funzioni offerte sono in larga parte le stesse. Conviene valutarle per l’effetto che hanno sugli utenti e per il rischio di rompere qualcosa.
Cache di pagina
È la funzione con il beneficio più alto e il rischio più basso: le pagine vengono servite già pronte, senza eseguire WordPress, con un TTFB di poche decine di millisecondi. Se il server o l’hosting non offrono una cache di pagina, il plugin che la fornisce è il primo da installare. Vanno solo configurate correttamente le esclusioni, come carrello, checkout e area riservata, e le regole di svuotamento quando i contenuti cambiano.
CSS critico e rimozione del CSS inutilizzato
Il CSS critico, cioè gli stili necessari al primo disegno inseriti nell’HTML con il resto caricato in modo non bloccante, può anticipare notevolmente il primo disegno e l’LCP, come abbiamo visto parlando di CSS critico inline ed esterno. La rimozione del CSS inutilizzato va oltre: analizza ogni pagina e toglie le regole che non vengono usate. È efficace sui temi pesanti, ma è anche la funzione che rompe più spesso l’aspetto delle pagine, perché molte regole servono solo in stati che l’analisi non vede: menu aperti, finestre modali, messaggi di errore, elementi aggiunti dal JavaScript, come spiegato nell’articolo sul CSS inutilizzato e gli stati dinamici.
Differimento e ritardo del JavaScript
Il differimento aggiunge l’attributo defer agli script, che vengono scaricati in parallelo ed eseguiti dopo la lettura del documento, senza bloccare il rendering. È una misura sicura nella maggior parte dei casi. Il ritardo all’interazione è molto più aggressivo: gli script non vengono nemmeno scaricati finché l’utente non muove il mouse, tocca lo schermo o scorre la pagina. L’effetto sui test di laboratorio è spettacolare, perché durante il test nessuno interagisce e il JavaScript semplicemente non viene mai caricato.
Proprio per questo va usato con consapevolezza. Sugli utenti reali, il lavoro non scompare: viene spostato al momento della prima interazione. Se il ritardo riguarda script pesanti, il primo tocco dell’utente innesca il download e l’esecuzione di tutto il JavaScript della pagina, e quell’interazione può diventare molto lenta, peggiorando l’INP invece di migliorarlo. La tecnica funziona bene per script di terze parti non essenziali, come chat, pixel e widget, come spiegato nell’articolo sul delay del JavaScript al primo clic; applicata indiscriminatamente a tutto, migliora soprattutto il punteggio.
Immagini, font e preload
Lazy loading, conversione in WebP e AVIF, dimensioni esplicite, font ospitati localmente, preload e preconnect: sono funzioni utili, ma quasi tutte si sovrappongono a ciò che WordPress fa già da solo o a ciò che il tema dovrebbe fare. Il rischio principale è il lazy loading applicato all’immagine LCP, e il preload di troppe risorse, entrambi trattati negli articoli sul lazy loading e su preload, preconnect e fetchpriority.
Minificazione e combinazione
La minificazione rimuove spazi e commenti da CSS e JavaScript: il guadagno, dopo la compressione, è modesto ma quasi senza rischi. La combinazione dei file in un unico foglio di stile o script era importante con HTTP/1.1, quando ogni richiesta aveva un costo elevato; con HTTP/2 e HTTP/3 il vantaggio è in gran parte scomparso, mentre i rischi restano: errori di un singolo script che bloccano tutti gli altri, cache invalidata a ogni modifica di un solo file, ordine di esecuzione alterato. Oggi, in genere, conviene lasciarla disattivata.
Sovrapposizioni e conflitti
Uno degli errori più comuni è installare più plugin con funzioni simili: un plugin di cache con le sue ottimizzazioni del front-end, un secondo per le immagini con il proprio lazy loading, un terzo per il CSS critico, a volte anche le ottimizzazioni della CDN. Il risultato sono funzioni applicate due volte, con effetti imprevedibili: doppio lazy loading che nasconde le immagini, script differiti due volte che si eseguono nell’ordine sbagliato, CSS minificato da un plugin e rielaborato da un altro, cache multiple da svuotare in sequenza.
La regola pratica è semplice: una funzione, un responsabile. Per ogni ottimizzazione si decide chi la gestisce, il server, la CDN, il tema o uno specifico plugin, e la si disattiva altrove. Una tabella con le funzioni e il relativo responsabile, conservata nella documentazione del sito, evita molti problemi alle modifiche successive.
Il cloaking delle prestazioni
C’è una pratica di cui si parla poco ma che chi lavora nel settore incontra con una certa frequenza: servire agli strumenti di test una pagina diversa da quella che ricevono gli utenti. Il meccanismo è semplice. Lighthouse, e quindi PageSpeed Insights, si identifica con un’intestazione User-Agent che contiene la stringa Chrome-Lighthouse. Un plugin, un servizio o un frammento di codice può riconoscerla e, solo in quel caso, restituire una versione alleggerita della pagina: senza script, senza font, senza immagini pesanti, a volte praticamente vuota. Il test misura quella pagina e restituisce un punteggio vicino a 100.
Il termine cloaking viene dalla SEO, dove indica la pratica di mostrare ai motori di ricerca contenuti diversi da quelli mostrati agli utenti, ed è esplicitamente vietata dalle norme di Google contro lo spam. Nel contesto delle prestazioni il bersaglio non è il motore di ricerca ma lo strumento di misura, e l’obiettivo non è il posizionamento ma il punteggio. Il principio, però, è lo stesso: far vedere a chi valuta qualcosa che gli utenti non vedranno mai.
Perché succede
La ragione è commerciale. Il punteggio di PageSpeed è diventato, per molti clienti, la misura della qualità di un sito: facile da verificare, espresso con un numero da 0 a 100, colorato di verde o di rosso. Agenzie e fornitori sono spesso valutati su quel numero, e alcuni prodotti vengono venduti con la promessa esplicita di «100/100 su PageSpeed». Quando il sito reale è lontano da quel risultato, la tentazione di ottenerlo per altre vie esiste, e alcune soluzioni sul mercato l’hanno assecondata, in modo più o meno dichiarato.
Perché non funziona
Il cloaking delle prestazioni migliora un numero che non conta per Google. Le Core Web Vitals usate nella valutazione delle pagine vengono dai dati di campo del Chrome UX Report, raccolti dai browser degli utenti reali, come spiegato nell’articolo sulle differenze tra PageSpeed Insights e Lighthouse. Gli utenti ricevono la pagina vera, e i loro dati riflettono la pagina vera. Il punteggio di laboratorio sale a 100, i dati di campo restano quelli di prima, e nella stessa pagina di PageSpeed Insights, poche righe più in alto, la sezione con i dati reali continua a mostrare valori scarsi.
Il rischio, inoltre, non è solo di inutilità. Se il meccanismo riconosce anche Googlebot, o i servizi di rendering di Google, e serve loro una pagina diversa da quella degli utenti, si rientra nel cloaking in senso proprio, con il rischio di azioni manuali contro il sito. E anche quando riguarda solo Lighthouse, una pagina servita in forma ridotta ai test automatici può creare problemi con altri strumenti che usano lo stesso motore, dai controlli di accessibilità alle anteprime dei social.
Il danno più grave, però, è un altro: il punteggio falso nasconde i problemi reali. Chi guarda solo il numero verde non vede che gli utenti aspettano quattro secondi, non investe dove servirebbe e scopre il problema quando si traduce in perdita di traffico o di conversioni. Per il cliente di un’agenzia, pagare per un punteggio finto significa pagare per non sapere.
Le forme più sottili
Non tutte le forme di ottimizzazione «per il test» sono cloaking esplicito. Alcune tecniche legittime, se portate all’estremo, producono lo stesso effetto: un punteggio che non descrive l’esperienza. Il caso più comune è il ritardo di tutto il JavaScript fino alla prima interazione, visto sopra: Lighthouse non interagisce mai con la pagina, quindi non esegue mai il codice ritardato, e misura una pagina che nessun utente reale vedrà in quello stato, perché ogni utente prima o poi tocca lo schermo. Altri esempi sono l’inserimento di contenuti principali solo dopo un’interazione, per cui l’LCP misurato in laboratorio è un elemento secondario, o la sostituzione dell’immagine principale con un segnaposto leggerissimo che diventa l’elemento LCP al suo posto.
Queste tecniche non violano alcuna norma, e in dosi moderate hanno benefici reali. Ma il criterio per giudicarle è sempre lo stesso: migliorano l’esperienza degli utenti o solo il numero del test? La risposta si trova nei dati di campo.
Come riconoscerlo
Il primo segnale è la distanza tra laboratorio e campo. Un sito con punteggio di laboratorio vicino a 100 e dati di campo nello stato scarso, in modo stabile e su molte pagine, merita un’indagine: le differenze tra i due tipi di dati sono normali, ma non di quella entità. Il secondo controllo è diretto: richiedere la stessa pagina con due intestazioni diverse e confrontare le risposte.
# La stessa pagina vista da un browser e da Lighthouse
UA_BROWSER='Mozilla/5.0 (Linux; Android 14) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Mobile Safari/537.36'
UA_TEST="$UA_BROWSER Chrome-Lighthouse"
curl -s -A "$UA_BROWSER" https://esempio.it/ -o browser.html
curl -s -A "$UA_TEST" https://esempio.it/ -o test.html
wc -c browser.html test.html # dimensioni molto diverse?
grep -c '<script' browser.html test.html # numero di script diverso?
diff <( grep -o 'src="[^"]*"' browser.html ) <( grep -o 'src="[^"]*"' test.html )Se le risposte differiscono in modo sostanziale, la pagina viene servita diversamente ai test. Il controllo va ripetuto anche lato browser, perché il riconoscimento può avvenire in JavaScript, leggendo navigator.userAgent: nei DevTools, nella sezione Network conditions, si può impostare un User-Agent personalizzato che contiene Chrome-Lighthouse e confrontare ciò che viene caricato. Infine, nel codice del tema e dei plugin, la ricerca di stringhe come Lighthouse, PageSpeed o GTmetrix rivela rapidamente eventuali condizioni sospette.
Un’altra verifica utile consiste nel confrontare il test di PageSpeed Insights con un test eseguito con uno strumento diverso, come WebPageTest con un profilo di dispositivo reale, o con un semplice caricamento registrato nei DevTools: se solo il test con Lighthouse restituisce una pagina leggera, il sospetto diventa una certezza.
Come configurare un plugin in modo sensato
Un approccio metodico evita la maggior parte dei problemi, sia di rottura sia di punteggi ingannevoli.
- Misurare prima. Dati di campo per modello di pagina, un test di laboratorio di riferimento e, se possibile, un sistema di Real User Monitoring.
- Partire dalla cache. Cache di pagina a livello di server o, in mancanza, del plugin. È la base, e raramente crea problemi.
- Attivare una funzione alla volta. Dopo ogni attivazione, verificare le pagine principali, compresi menu, moduli, carrello, banner dei cookie e versione mobile, e controllare la console del browser per errori.
- Usare le esclusioni. Escludere dal ritardo gli script necessari all’interazione iniziale, dal lazy loading l’immagine LCP, dalla rimozione del CSS le classi usate negli stati dinamici.
- Una funzione, un responsabile. Disattivare le funzioni duplicate negli altri plugin, nel tema e nella CDN.
- Giudicare sui dati di campo. Dopo 28 giorni, i dati reali dicono se la configurazione ha migliorato l’esperienza, indipendentemente dal punteggio.
Quando il plugin non basta
Un plugin di ottimizzazione lavora sul codice che il sito già produce: può riordinarlo, ritardarlo, comprimerlo, ma non può renderlo più leggero di quanto sia. Un tema con due megabyte di JavaScript, un page builder con un DOM enorme, venti script di terze parti, un server lento senza cache: in questi casi il plugin può attenuare i sintomi, ma le cause restano. Quando, dopo una configurazione attenta, i dati di campo restano lontani dalle soglie, il problema è a monte, e va affrontato nel tema, nei contenuti, negli script o nell’infrastruttura.
Vale anche il contrario: un sito costruito bene, con un tema leggero, pochi plugin e un hosting con cache di pagina, può raggiungere ottime Core Web Vitals senza alcun plugin di ottimizzazione, o con una configurazione minima. Il plugin è uno strumento, non una strategia.
Come valutare chi propone l’ottimizzazione
Per chi commissiona un intervento sulle prestazioni, alcune domande aiutano a distinguere un lavoro serio da uno che punta al numero. Su quali dati verrà misurato il risultato: solo il punteggio di PageSpeed o anche i dati di campo? Quali funzioni verranno attivate, e quali esclusioni sono previste per non rompere il sito? Come verranno verificati menu, moduli, pagamenti e banner dei cookie? Cosa succede all’INP con il ritardo del JavaScript? Un fornitore che risponde parlando solo del punteggio, o che garantisce «100/100» senza aver visto il sito, merita qualche domanda in più.
In sintesi
I plugin di ottimizzazione per WordPress raggruppano funzioni molto diverse: la cache di pagina, che ha il beneficio più alto e il rischio più basso; CSS critico e ritardo del JavaScript, efficaci ma delicati; minificazione e combinazione, oggi di scarso impatto. Funzionano bene quando ogni funzione ha un solo responsabile, viene attivata con metodo e verificata sulle pagine reali e sui dati di campo.
Il cloaking delle prestazioni, cioè servire ai test una pagina alleggerita riconoscendo lo User-Agent di Lighthouse, produce punteggi alti che non corrispondono all’esperienza degli utenti e non cambiano le Core Web Vitals che Google usa, basate sui dati reali. Nel caso peggiore, se coinvolge anche Googlebot, espone il sito a penalizzazioni; in ogni caso nasconde i problemi invece di risolverli. Il punteggio di laboratorio è uno strumento diagnostico: trattarlo come un obiettivo da raggiungere a ogni costo significa perdere di vista le persone che il sito dovrebbe servire.
