Un sito che sul computer dell’ufficio scorre senza intoppi può risultare lento appena aperto da uno smartphone in mobilità, con una connessione meno stabile e un processore meno potente. La domanda che il titolare si pone, di solito dopo aver controllato l’hosting, è se il problema dipenda dal server o da qualcos’altro.
Nella maggior parte dei casi la causa sta nel modo in cui il tema, i plugin e le immagini del sito sono organizzati, non nella potenza del server che lo ospita. I Core Web Vitals, le tre metriche che Google usa per misurare il caricamento, la reattività e la stabilità visiva di una pagina, aiutano a capire dove intervenire prima di cambiare hosting o rifare il sito.
Ecco l’indice dei contenuti della presente risorsa:
Perché un sito WordPress può essere lento anche con un buon hosting
Un hosting performante riduce il tempo di risposta del server (il cosiddetto TTFB), ma non decide da solo la velocità percepita da chi visita il sito. Il caricamento dipende anche da quante richieste il browser deve gestire per costruire la pagina: fogli di stile, script, font, immagini non compresse. Un tema che carica librerie non utilizzate su ogni pagina, o un plugin che inserisce codice JavaScript anche dove non serve, può vanificare un server veloce. Capita spesso su piani hosting condivisi, dove le risorse vengono ripartite tra molti siti diversi e un picco di traffico su uno di questi rallenta tutti gli altri.
Chi valuta un cambio di hosting solo per problemi di lentezza rischia di intervenire nel punto sbagliato: prima conviene distinguere se il rallentamento avviene al primo contatto con il server o dopo, nel caricamento degli elementi della pagina (i criteri per scegliere un hosting WordPress adeguato aiutano a capire quando il server è davvero la causa).
Cosa misurano davvero LCP, INP e CLS
Le tre metriche raccolte da Google attraverso i dati reali di navigazione (Chrome User Experience Report) descrivono aspetti diversi dell’esperienza su una pagina. Il Largest Contentful Paint (LCP) misura il tempo necessario a mostrare l’elemento più grande visibile nella prima schermata: un valore entro 2,5 secondi è considerato buono, oltre i 4 secondi la pagina risulta lenta.
L’Interaction to Next Paint (INP) misura il tempo di risposta del sito a un’interazione, come un clic su un filtro prodotti o l’apertura di un menu: sotto i 200 millisecondi la reattività è buona, oltre i 500 diventa percepibile come un ritardo. Dal marzo 2024 l’INP ha sostituito il precedente First Input Delay come metrica ufficiale, perché valuta la reattività lungo tutta la visita e non solo alla prima interazione (i criteri ufficiali pubblicati da Google documentano soglie e metodo di calcolo).
Il Cumulative Layout Shift (CLS) misura invece quanto gli elementi della pagina si spostano in modo imprevisto durante il caricamento, ad esempio quando un banner sui cookie o un’immagine senza dimensioni dichiarate spinge il testo più in basso: un valore sotto 0,1 è considerato accettabile. Le tre soglie vengono valutate al 75esimo percentile delle visite reali, non su una singola prova di caricamento.
Perché il sito sembra scorrevole da computer e si blocca da smartphone
Il computer con cui si controlla il sito ha in genere una connessione stabile via cavo o Wi-Fi e un processore più potente di quello di uno smartphone di fascia media. Lo stesso file JavaScript che il computer elabora in pochi millisecondi può richiedere tempi più lunghi su un telefono, soprattutto se il codice blocca il thread principale del browser mentre la pagina si sta ancora costruendo, come accade spesso con il menu a scomparsa o con gli script dei filtri di ricerca. Le immagini pensate per uno schermo largo, se non vengono ridimensionate per il formato mobile, continuano a pesare sul caricamento anche quando lo spazio visibile è molto più piccolo.
A questo si aggiunge la rete: una connessione dati con latenza variabile penalizza soprattutto le pagine che caricano molte risorse esterne, come font di terze parti o widget di social network incorporati. Per questo un test eseguito solo da computer, magari con una connessione aziendale veloce, restituisce un quadro parziale: la valutazione va sempre condotta anche in condizioni di rete mobile realistiche, riproducibili negli strumenti di sviluppo del browser con una connessione simulata più lenta.
Come verificare se il sito è realmente veloce per chi lo visita
Il rapporto Core Web Vitals disponibile in Google Search Console mostra i dati raccolti dai visitatori reali del sito, aggregati su un periodo di 28 giorni: indica quante pagine rientrano nei valori buoni per LCP, INP e CLS e quali url risultano da migliorare. PageSpeed Insights, invece, restituisce anche una misurazione di laboratorio, utile per individuare quale elemento specifico rallenta la pagina in un singolo test, ma meno rappresentativa dell’esperienza media degli utenti.
Chi gestisce il sito può controllare periodicamente questi due strumenti senza competenze tecniche, annotando quali pagine peggiorano dopo un aggiornamento del tema o l’installazione di un nuovo plugin. Un calo isolato dei tempi di risposta, seguito da un ritorno alla normalità, spesso segnala un picco di traffico o un problema temporaneo dell’hosting; un peggioramento costante nel tempo indica quasi sempre una causa strutturale da individuare.
Su un negozio WooCommerce, la pagina prodotto e quella di checkout meritano un controllo più frequente rispetto a una pagina di solo testo, perché tendono ad accumulare più facilmente immagini non ottimizzate e script legati a pagamenti o recensioni (alcuni controlli di base che chi gestisce il sito può fare autonomamente permettono di individuare i casi più semplici prima di richiedere un intervento tecnico).
Tema pesante e troppi plugin: quanto incidono sui Core Web Vitals
Un tema che include funzioni non utilizzate, come builder visuali con librerie caricate su ogni pagina anche quando non servono, aumenta il peso complessivo del sito indipendentemente dal contenuto pubblicato.
Lo stesso vale per i plugin: non è tanto il numero a incidere sulle prestazioni, quanto la qualità del codice e la frequenza con cui vengono eseguiti a ogni caricamento di pagina. Due plugin scritti male pesano più di dieci plugin ben sviluppati e caricati solo dove servono. Un plugin di cache riduce il tempo di risposta del server e può migliorare l’LCP nelle visite successive alla prima, ma non interviene su un tema che blocca il thread principale del browser, né su un layout che genera spostamenti visivi durante il caricamento dei font: in questi casi il problema è nel codice, non nella configurazione, e la cache da sola non basta.
Quando un tema utilizza tecnologie datate o un builder che genera codice ridondante a ogni sezione, conviene valutare se bastino modifiche mirate o se convenga considerare (le differenze tra un tema pronto e uno sviluppato su misura) prima di continuare ad accumulare correzioni parziali.
Quando conviene ottimizzare e quando serve un intervento più ampio
Il tempo di caricamento incide sul comportamento di chi visita il sito prima ancora che sull’algoritmo di Google: una pagina che risponde con ritardo a un clic scoraggia la compilazione di un modulo di contatto o il completamento di un acquisto, indipendentemente dal posizionamento nei risultati di ricerca. Sul fronte SEO, Google utilizza i Core Web Vitals come uno dei segnali considerati dai propri sistemi di posizionamento (secondo la documentazione ufficiale di Google Search Central), non come un fattore isolato che da solo decide la classifica: un contenuto utile resta la condizione di partenza, ma a parità di contenuto una pagina lenta parte svantaggiata.
Quando i problemi riguardano immagini non compresse, font caricati in modo inefficiente o un plugin di cache mai configurato, un intervento puntuale è spesso sufficiente. In questi casi (un’analisi tecnica mirata alla velocità del sito) individua gli elementi da correggere senza toccare la struttura esistente.
Quando invece il rallentamento dipende dalla struttura del tema, da un accumulo di plugin sovrapposti nel tempo o da un codice personalizzato mai rivisto, la correzione richiede competenze di sviluppo front-end. Restyling e rifacimento non sono la stessa cosa: un restyling può mantenere i contenuti e l’impianto informativo intervenendo su tema e codice, mentre un rifacimento completo si giustifica solo quando l’architettura del sito non regge più le esigenze attuali (una valutazione del sito esistente chiarisce quale intervento sia proporzionato al problema riscontrato).
Prima di decidere se basta un intervento sui plugin o serve una revisione più ampia del tema, una verifica preliminare aiuta a distinguere i due casi. Una consulenza gratuita sulla velocità del sito, richiedibile indicando l’indirizzo del sito e i sintomi osservati, permette di capire se il problema è risolvibile con interventi mirati o richiede un lavoro più esteso sul codice.
Sviluppatore front-end, esperto Wordpress e Woocommerce e consulente digitale, da anni realizza temi personalizzati WP per siti su misura e e-commerce. Supporta privati e agenzie nella programmazione, manutenzione e gestione di progetti con Wordpress.
