Perché un sito WordPress diventa lento e come intervenire davvero

Un sito WordPress lento raramente ha una sola causa.

Può dipendere dall’hosting, da immagini troppo pesanti, dal tema, dai plugin, da JavaScript che occupa troppo il browser, da una configurazione della cache poco efficace o, più spesso, dalla combinazione di diversi problemi.

La soluzione, quindi, non è necessariamente installare un altro plugin di ottimizzazione.

Prima bisogna capire dove si trova realmente il collo di bottiglia.

WordPress stesso indica hosting, configurazione, tema, plugin, quantità e dimensione delle immagini tra i fattori che possono influire sulle prestazioni. La documentazione ufficiale raccomanda di intervenire in modo selettivo su queste aree, insieme a caching, database e infrastruttura.

Il metodo corretto è meno spettacolare della promessa “velocizza WordPress in cinque minuti”, ma tende a funzionare meglio:

misurare → individuare la causa → intervenire → verificare nuovamente.

Come capire se un sito WordPress è davvero lento

Il primo errore è affidarsi a un solo numero.

Google PageSpeed Insights è uno strumento molto utile, ma contiene informazioni differenti che vanno interpretate correttamente.

Da una parte ci sono i dati raccolti dagli utenti reali, provenienti dal Chrome User Experience Report quando sono disponibili. Dall’altra ci sono i test di laboratorio, che simulano il caricamento della pagina in condizioni controllate e aiutano soprattutto nella diagnosi.

Questo spiega perché può capitare di ottenere risultati diversi tra:

• PageSpeed Insights;
• Lighthouse;
• Search Console;
• il proprio computer;
• smartphone e desktop;
• test effettuati in momenti differenti.

Non significa necessariamente che uno degli strumenti stia sbagliando.

Stanno osservando aspetti e condizioni diverse.

Dati reali e test di laboratorio non sono la stessa cosa

I dati reali raccontano cosa è successo agli utenti che hanno effettivamente visitato il sito.
I test di laboratorio sono invece estremamente utili per scoprire perché una pagina presenta determinate criticità.
Per una diagnosi seria servono entrambi.

Se PageSpeed mostra un punteggio basso, la domanda non dovrebbe essere:

Come porto questo numero a 100?

Dovrebbe essere:

Quale problema sta causando questo risultato e cosa percepisce realmente l’utente?

È una differenza meno cosmetica di quanto sembri.

Core Web Vitals: LCP, INP e CLS

Google utilizza tre metriche principali per valutare alcuni aspetti dell’esperienza reale degli utenti: Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift.

I valori considerati “buoni” sono:

Google valuta questi valori utilizzando il 75° percentile delle visite quando dispone di dati sufficienti.

Vediamoli in pratica.

LCP: quando il contenuto principale arriva troppo tardi

Il Largest Contentful Paint misura quanto rapidamente diventa visibile uno degli elementi principali della pagina.
Molto spesso può trattarsi di:

• immagine hero;
• grande fotografia;
• banner;
• blocco di testo principale.

Quando l’LCP è elevato, le cause possono trovarsi tanto nel frontend quanto nel server. Un’immagine enorme può rallentarlo.
Ma può rallentarlo anche un server che impiega troppo tempo prima di iniziare a inviare la pagina.
Ecco perché ottimizzare soltanto l’immagine non risolve necessariamente il problema.

INP: quando clicchi e il sito sembra pensarci

Interaction to Next Paint misura la reattività della pagina alle interazioni dell’utente.
Un pulsante che reagisce in ritardo, un menu che si apre lentamente o un’interfaccia che sembra bloccarsi possono indicare un problema di questo tipo.

JavaScript eccessivo o attività molto lunghe sul thread principale del browser possono compromettere l’INP. Google considera buono un valore entro 200 millisecondi per almeno il 75% delle visite.

CLS: quando la pagina si sposta mentre la stai usando

Il Cumulative Layout Shift misura gli spostamenti inattesi degli elementi.
Il classico caso è questo: stai per premere un pulsante, compare improvvisamente un’immagine o un banner e il pulsante si sposta. Google indica tra le cause frequenti immagini o iframe senza dimensioni definite, contenuti inseriti dinamicamente e web font.

Un CLS elevato non significa soltanto una pagina meno elegante, significa soprattutto una pagina meno prevedibile da usare.

Perché un sito WordPress diventa lento

Non è quasi mai corretto dire semplicemente:

WordPress è lento.

WordPress è una piattaforma sulla quale possono essere costruiti siti estremamente differenti.
A incidere sono soprattutto come è stato costruito il progetto e cosa gli è stato aggiunto nel tempo.

La stessa documentazione WordPress cita esplicitamente infrastruttura hosting, tema, plugin e immagini tra gli elementi che possono avere un impatto sostanziale sulle performance.

Hosting e risposta del server

Prima ancora che il browser possa mostrare immagini, testi o animazioni, il server deve rispondere. Se questa fase è lenta, tutto il resto parte in ritardo.

CPU disponibili, memoria, configurazione PHP, database, caching server, carico della macchina e tipo di hosting possono incidere sulle prestazioni. WordPress sottolinea inoltre che un persistent object cache può ridurre le richieste ripetute al database e migliorare tempi di risposta come il TTFB.

Per questo la scelta di hosting e registrazione del dominio non dovrebbe essere considerata completamente separata dalle prestazioni del sito. Un plugin può ottimizzare molte cose, mon può trasformare all’infinito un’infrastruttura insufficiente.

Immagini troppo pesanti

È una delle cause più comuni e anche una delle più semplici da evitare.
Caricare una fotografia da 5000 pixel dentro uno spazio che sullo schermo ne occupa 900 significa chiedere al browser di scaricare informazioni che non utilizzerà.

Bisogna intervenire su:

• dimensioni;
• compressione;
• formato;
• immagini responsive;
• lazy loading quando opportuno.

WordPress raccomanda esplicitamente di ottimizzare le immagini e prendere in considerazione formati moderni come WebP.
Oggi può essere valutato anche AVIF quando compatibilità e workflow lo rendono conveniente.

Ma c’è un’eccezione importante.

Non tutte le immagini devono essere caricate in lazy load

Il lazy loading è molto utile per le immagini che si trovano più in basso nella pagina.
Applicarlo indiscriminatamente all’immagine principale visibile appena si apre il sito può invece ritardare proprio l’elemento che dovrebbe comparire prima.

L’ottimizzazione delle performance non consiste nell’attivare tutte le opzioni disponibili, ma nel capire a cosa servono.

Plugin: il problema non è quanti sono, ma cosa fanno

“Non installare più di dieci plugin” è una regola piuttosto grossolana.
Dieci plugin ben sviluppati e caricati soltanto dove servono possono incidere meno di un singolo plugin molto pesante.

Bisogna valutare:

• PHP eseguito;
• query al database;
• JavaScript;
• CSS;
• richieste esterne;
• asset caricati inutilmente su tutte le pagine.

WordPress raccomanda comunque di rimuovere i plugin non necessari e di disattivarli selettivamente durante la diagnosi per verificare se uno di essi incide sensibilmente sulle prestazioni.

Il punto quindi non è fare una gara a chi installa meno plugin, ma non caricare ciò che non serve.

Tema e page builder rallentano WordPress?

Possono farlo.
Un tema complesso o un page builder possono produrre più HTML, CSS e JavaScript rispetto a una soluzione minimale.
Ma la conclusione:

page builder = sito lento

è troppo semplice.

Conta come vengono utilizzati.

Una pagina piena di slider, animazioni, effetti, componenti duplicati e widget esterni sarà più difficile da ottimizzare indipendentemente dal builder scelto.
La documentazione WordPress sottolinea che anche il tema può avere un impatto molto significativo sulle prestazioni.
Quindi la domanda corretta non è:

Posso utilizzare un page builder?

Ma:

Quanto codice e quante funzionalità sto caricando per ottenere questa pagina?

CSS e JavaScript: quando il browser deve fare troppo lavoro

Una pagina può iniziare a caricarsi velocemente e diventare comunque poco reattiva.
CSS e soprattutto JavaScript possono impegnare il browser durante il rendering e le interazioni.

Alcune ottimizzazioni comuni consistono nel:

• rimuovere risorse inutilizzate;
• caricare asset solo nelle pagine in cui servono;
• differire JavaScript non critico;
• ritardare alcune risorse di terze parti;
• ridurre librerie e componenti non necessari.

Sono interventi che vanno però testati.

Ritardare indiscriminatamente tutti gli script può rendere ottimo un test automatico e contemporaneamente rompere menu, slider, form, tracking o altre funzioni.
Un risultato numerico migliore non compensa un sito che ha smesso di funzionare.

I font possono rallentare un sito?

Sì, soprattutto quando vengono caricati troppi font, pesi e varianti.
Un progetto che utilizza due famiglie tipografiche non ha necessariamente bisogno di scaricare quindici file.

Si può intervenire riducendo:

• famiglie;
• pesi;
• varianti;
• caratteri inutilizzati.

Quando opportuno è possibile ospitare i font localmente e utilizzare strategie di caricamento coerenti con il progetto.
Anche qui vale la stessa regola: non esiste una configurazione automaticamente migliore per qualsiasi sito.

Il database può rendere WordPress lento?

Può contribuire, soprattutto in siti che cambiano molto nel tempo.
Revisioni, transient, log, sessioni, dati lasciati da plugin e opzioni caricate automaticamente possono aumentare la quantità di lavoro necessaria.

WordPress dedica una parte specifica della propria documentazione all’ottimizzazione del database e alle opzioni autoload, proprio perché configurazioni molto pesanti possono incidere sulle prestazioni.

Questo non significa che bisogna premere ogni settimana “ottimizza database” dentro un plugin: prima bisogna capire se il database rappresenta davvero il problema.

E prima di intervenire direttamente sui dati, un backup verificato non è un vezzo.

Un plugin di cache può risolvere un sito WordPress lento?

Può migliorarlo parecchio. Ma non può risolvere qualsiasi problema.

La cache evita di ripetere inutilmente parte del lavoro necessario a generare e trasferire una pagina. WordPress la considera uno degli interventi con il miglior rapporto fra beneficio e complessità e documenta differenti livelli di caching: pagina, browser, oggetti e server.

Plugin come WP Rocket, LiteSpeed Cache o strumenti equivalenti possono quindi essere molto efficaci.
Ma immagini enormi rimangono immagini enormi.

Un server lento rimane un server lento.
Un plugin che genera richieste inefficienti continuerà a generarle.
JavaScript eccessivo deve comunque essere scaricato ed eseguito.

E un layout instabile non diventa automaticamente stabile perché abbiamo attivato la cache.

La cache è uno strumento. Non una diagnosi.

Perché WordPress è lento soprattutto su mobile?

È molto frequente vedere un sito soddisfacente su desktop e decisamente meno brillante su smartphone.
Il dispositivo mobile può avere:

• processore meno potente;
• rete più variabile;
• viewport differente;
• layout responsive più complesso;
• componenti specifici per mobile.

Inoltre PageSpeed distingue chiaramente l’analisi mobile da quella desktop.

Un sito testato dal computer dell’ufficio, collegato in fibra e già presente nella cache del browser, non rappresenta necessariamente l’esperienza di chi lo apre per la prima volta dal telefono.

Per questo l’ottimizzazione dovrebbe partire spesso proprio dal mobile.

PageSpeed 100/100 è davvero necessario?

No.

E questa volta non è una scusa inventata dagli sviluppatori quando compare un 93.
Google stesso afferma che ottenere risultati perfetti nei Core Web Vitals o negli strumenti di test non garantisce le prime posizioni e precisa che cercare un punteggio perfetto esclusivamente per motivi SEO potrebbe non essere il miglior utilizzo del tempo.

I Core Web Vitals vengono utilizzati dai sistemi di ranking, ma Google valuta la page experience nel suo complesso e continua soprattutto a cercare di mostrare contenuti pertinenti e utili.
Quindi:

100 con un sito graficamente impoverito o con funzioni compromesse non è necessariamente migliore di 92 con un’esperienza eccellente.

L’obiettivo è avere un sito rapido, stabile, reattivo e adatto a ciò che deve fare.
Il punteggio serve a individuare problemi.

CDN: serve sempre?

Una CDN distribuisce risorse attraverso più nodi geografici e può ridurre distanza e carico sul server origin.

WordPress la include tra le tecniche utili per alleggerire la distribuzione di immagini, CSS, JavaScript e altri file statici. Alcune soluzioni possono gestire anche cache dell’intera pagina.

Non significa però che ogni piccolo sito locale debba obbligatoriamente utilizzare un’architettura internazionale complicatissima.

Come sempre, la soluzione deve essere proporzionata al problema.

Cosa fare quando PageSpeed segnala decine di problemi

Non partire dall’elenco dall’alto verso il basso. Bisogna stabilire delle priorità.
Il metodo che utilizziamo può essere sintetizzato così.

1. Misurare

PageSpeed Insights, Search Console e strumenti di sviluppo permettono di individuare metriche e anomalie.

2. Capire quale elemento genera il problema

Se l’LCP è scarso, bisogna trovare l’elemento LCP.
Se il CLS è elevato, bisogna individuare cosa si sposta.
Se l’INP è scarso, bisogna scoprire quale interazione o attività blocca il browser.

3. Individuare la causa

L’immagine è troppo grande? Arriva tardi dal server? Un CSS ne impedisce il rendering? JavaScript sta occupando il browser?

4. Intervenire sul problema reale

Solo a questo punto ha senso scegliere impostazione, codice o strumento appropriato.

5. Verificare

Ogni modifica deve essere nuovamente testata. Alcune ottimizzazioni migliorano una metrica e ne peggiorano un’altra.
Altre possono compromettere funzionalità che un test sintetico non utilizza.
Il ciclo quindi non è:

installa → attiva → dimentica.

È:

misura → modifica → verifica.

Velocità, SEO e visibilità su Google

Le performance fanno parte dell’esperienza della pagina e i Core Web Vitals vengono utilizzati nei sistemi di ranking di Google. Ma Google chiarisce anche che non esiste un unico “page experience signal” e che ottenere ottimi valori non garantisce automaticamente un buon posizionamento.

È quindi sbagliato affrontare le performance separandole completamente dalla SEO e dal posizionamento sui motori di ricerca.

Un sito velocissimo con contenuti irrilevanti non risolve il problema, mentre un sito con ottimi contenuti ma frustrante da utilizzare lascia comunque spazio di miglioramento.

SEO tecnica, contenuti ed esperienza utente devono lavorare insieme.

Quando conviene ottimizzare e quando rifare il sito

Non tutti i siti lenti devono essere rifatti. Molto spesso è possibile ottenere miglioramenti importanti intervenendo su:

• hosting;
• immagini;
• asset;
• plugin;
• caching;
• configurazioni;
• database;
• struttura delle pagine.

In altri casi, però, il problema è più profondo.

Un sito costruito molti anni prima, con componenti non più mantenuti, architettura estremamente pesante e numerosi interventi stratificati può richiedere così tante correzioni da rendere ragionevole valutare una nuova progettazione e realizzazione del sito web.

È una decisione che non dovrebbe essere presa soltanto guardando PageSpeed.
Bisogna confrontare costo dell’ottimizzazione, stato tecnico, obiettivi futuri e durata prevedibile dell’intervento.

Per orientarsi anche dal punto di vista economico abbiamo approfondito separatamente quanto costa realizzare un sito web professionale e quali elementi incidono realmente sul preventivo.

Un sito WordPress veloce parte dalla diagnosi

Velocizzare WordPress non significa attivare tutte le opzioni disponibili in un plugin. Significa capire quali risorse rallentano il caricamento, quali attività rendono la pagina poco reattiva e quali elementi provocano instabilità.

Hosting, immagini, tema, plugin, JavaScript, CSS, font, database e cache possono tutti contribuire al risultato finale. La documentazione ufficiale WordPress conferma proprio la necessità di valutare il sistema nel suo complesso.

A volte basta un intervento relativamente semplice, altre volte serve mettere mano a più livelli del progetto.

La parte importante è sapere la differenza prima di iniziare a cambiare impostazioni.