Un sito lento ha di solito una di queste cause: immagini troppo pesanti o caricate male, script di terze parti che tengono occupato il browser, CSS e JavaScript che bloccano la visualizzazione, un server che risponde tardi. Prima di cambiare hosting o rifare tutto, misura: PageSpeed Insights ti dice quale metrica non passa e su quali pagine, e la risposta decide da dove cominciare.
Da dove capisco cosa lo rallenta?
Apri PageSpeed Insights e analizza le pagine che contano: la home, una categoria o una pagina servizio, una scheda prodotto o un articolo. In alto trovi i dati degli utenti reali, se il sito ha abbastanza traffico; sotto, il test di laboratorio con l'elenco delle opportunità. I dati reali dicono se il problema esiste, il laboratorio aiuta a capire perché.
Per il caricamento conviene guardare come si scompone l'LCP, la metrica che misura quando compare il contenuto principale: risposta del server, attesa prima che parta l'immagine principale, download, visualizzazione. Se il grosso del tempo è nella risposta del server, comprimere le immagini serve a poco; se è nel download, il problema è il peso della risorsa. La guida all'ottimizzazione dell'LCP spiega come leggere queste quattro parti.
Il significato di LCP, INP e CLS è spiegato nella guida ai Core Web Vitals; il metodo completo per analizzare un sito, pagina per pagina, è nella guida all'audit di performance. Qui ci concentriamo sugli interventi.
Immagini: il primo posto dove guardare
Sono spesso la parte più pesante della pagina e l'intervento con meno effetti collaterali. La checklist:
- Formati moderni: le immagini WebP con perdita di dati sono dal 25 al 34% più piccole dei JPEG di qualità equivalente, secondo la documentazione di Google su WebP; per AVIF, web.dev riporta risparmi superiori al 50% rispetto al JPEG (compressione con AVIF).
- Dimensioni giuste: con gli attributi srcset e sizes il browser scarica la versione adatta allo schermo, invece dell'originale da fotocamera (immagini responsive).
- Caricamento differito solo sotto la parte visibile: le immagini che compaiono all'apertura, e soprattutto quella principale, vanno caricate subito, come raccomanda la guida al lazy loading nativo.
- Priorità all'immagine principale con l'attributo fetchpriority (Fetch Priority). WordPress, dalla versione 6.3, lo aggiunge da solo all'immagine che ritiene più probabilmente quella principale, secondo la nota degli sviluppatori di WordPress.
- Larghezza e altezza sempre dichiarate, così la pagina non salta quando l'immagine arriva (ottimizzare il CLS).
Script di terze parti: chat, pixel e widget
Chat, pixel pubblicitari, mappe, video incorporati e strumenti di analisi aggiungono codice che il browser deve scaricare ed eseguire, spesso da server che non controlli. La guida di web.dev su come caricare in modo efficiente il JavaScript di terze parti indica due strade: toglierli se non portano un valore chiaro, oppure ottimizzarne il caricamento.
In pratica: carica gli script con async o defer quando non servono prima della visualizzazione; fai partire chat, mappe e video solo quando l'utente arriva fino a loro o li apre; ripulisci Google Tag Manager dai tag di campagne concluse. Prima di aggiungere un nuovo strumento di marketing chiediti quanto rallenta la pagina e chi lo toglierà quando non servirà più.
CSS, JavaScript e font: meno codice prima della prima schermata
Il browser non mostra nulla finché non ha scaricato i fogli di stile e gli script sincroni nell'intestazione della pagina. Lighthouse li segnala come richieste che bloccano il rendering e indica la strada: incorporare le risorse critiche, rimandare quelle non critiche, eliminare quello che non si usa (risorse che bloccano il rendering). La differenza tra async e defer è spiegata nella documentazione MDN sul tag script.
Il JavaScript ha un costo che le immagini non hanno: oltre a scaricarlo, il browser deve analizzarlo ed eseguirlo sul thread principale, lo stesso che risponde ai clic. Il code splitting divide il codice in parti caricate solo quando servono (ridurre il JavaScript con il code splitting) e aiuta sia il caricamento sia la reattività.
Per i font usa il formato WOFF2, che web.dev indica come l'unico ormai necessario, carica solo i caratteri e gli stili che usi e precarica i più importanti. Ospitarli sul tuo dominio elimina una connessione esterna, ma secondo la stessa guida il vantaggio è netto solo se il sito usa una CDN e HTTP/2 (buone pratiche per i font).
Il server risponde tardi? TTFB, cache e CDN
Il TTFB, time to first byte, è il tempo che passa prima che arrivi il primo byte della pagina. Come riferimento indicativo web.dev considera buono un TTFB entro 0,8 secondi e scadente oltre 1,8 (guida al TTFB). Se il tuo è alto, tutto il resto parte in ritardo.
La guida all'ottimizzazione del TTFB mette l'hosting al primo posto: quello condiviso è in genere più lento, e il fornitore dovrebbe tenere aggiornati linguaggi, server web e database. Seguono la CDN, che serve le risorse da server vicini all'utente con protocolli moderni e compressione, la cache delle pagine e l'eliminazione dei reindirizzamenti in catena. La stessa guida avverte che parametri di tracciamento diversi negli indirizzi possono impedire alla CDN di usare la copia in cache.
- Su quali versioni di PHP, server web e database gira il sito, e chi le aggiorna?
- C'è una cache delle pagine lato server? Quali pagine esclude, per esempio carrello e area clienti?
- Il sito passa da una CDN? Le risorse statiche hanno intestazioni di cache corrette?
- Le risposte sono compresse con Brotli o gzip?
- Il server supporta HTTP/2 o HTTP/3?
Sono le domande da fare al tuo hosting. Sulle intestazioni di cache la regola di base è semplice: i file che hanno una versione nel nome possono restare nella cache del browser a lungo, anche un anno, mentre l'HTML va ricontrollato a ogni visita, così chi torna vede sempre la versione aggiornata (cache HTTP).
WordPress lento: plugin, page builder e cache
Su WordPress i punti da controllare hanno nomi precisi. La guida all'ottimizzazione di WordPress indica come primo intervento disattivare ed eliminare i plugin non necessari, provando a disattivarli uno alla volta per misurare l'effetto, poi un plugin di cache che serve le pagine come file statici e versioni recenti di PHP.
I page builder possono generare molti più elementi HTML di quelli che servono. Una pagina con un DOM enorme costa di più sia da disegnare sia da aggiornare dopo un clic, e Lighthouse inizia a segnalare il problema sopra gli 800 nodi, secondo la guida di web.dev sulle dimensioni del DOM. Quando tema e page builder sono il collo di bottiglia, leggi il confronto tra page builder e codice su misura.
Come verifichi che il sito sia diventato più veloce?
Subito dopo le modifiche ripeti i test di laboratorio sulle stesse pagine e nelle stesse condizioni, e confrontali con quelli di prima: è la verifica più rapida. I dati degli utenti reali si muovono più lentamente, perché PageSpeed Insights e Search Console li aggregano su una finestra mobile di quattro settimane, come spiega la pagina informazioni su PageSpeed Insights.
Un solo test non basta. Il punteggio di Lighthouse varia anche per ragioni che non dipendono dal sito, come estensioni del browser, rete o annunci che cambiano, e la sua documentazione sul punteggio suggerisce di ragionare su una distribuzione di misure invece che su un numero singolo. Annota la data di ogni intervento: ti servirà per leggere l'andamento dei dati reali.
Quando conviene smettere di ottimizzare e rifare
Se dopo gli interventi principali le metriche restano rosse, o se ogni nuovo contenuto le fa peggiorare di nuovo, il problema è strutturale: tema pesante, decine di plugin che dipendono l'uno dall'altro, hosting inadeguato. A quel punto rifare il sito su una base tecnica diversa può costare meno che continuare a rincorrere i sintomi.
Per Previtali Macchine Utensili abbiamo sviluppato un tema WordPress scritto in codice su misura, una scelta fatta per avere velocità, leggerezza e controllo del design, lasciando al team interno la gestione del catalogo macchine. Nei siti nuovi partiamo da Next.js e React, dove queste ottimizzazioni sono previste dal progetto invece di essere aggiunte dopo.
Se non sai se al tuo sito serve un'ottimizzazione o un rifacimento, scrivici con l'indirizzo: partiamo dai dati reali, pagina per pagina. Come lavoriamo quando un sito va rimesso in forma lo trovi nella pagina restyling siti web.
Domande frequenti
Cambiare hosting basta a velocizzare il sito?
Solo se il problema è il server, cioè se la risposta alla prima richiesta arriva tardi. Se il tempo si perde tra immagini pesanti, script di terze parti o codice che blocca la visualizzazione, un hosting più veloce aiuta poco.
Che punteggio devo raggiungere su PageSpeed Insights?
Il punteggio verde del laboratorio è un buon segnale, ma per Google contano i dati degli utenti reali: LCP, INP e CLS nella fascia buona per la maggior parte delle visite. Una pagina con buoni dati reali e un punteggio giallo è messa meglio del contrario.
Il lazy loading può peggiorare le cose?
Sì, se lo applichi alle immagini visibili appena si apre la pagina, soprattutto a quella principale: il browser ne rimanda il caricamento e il contenuto compare più tardi. Va usato per le immagini più in basso.
Un sito lento perde posizioni su Google?
Le metriche Core Web Vitals sono usate da Google nel ranking, ma la pertinenza dei contenuti viene prima. Il danno più diretto della lentezza è un altro: le persone abbandonano la pagina prima di leggerla o di comprare.
Quanti plugin sono troppi su WordPress?
Non esiste un numero giusto, conta quanto pesa ciascuno. Elimina quelli che non usi e misura la pagina disattivando gli altri uno alla volta, come suggerisce anche la documentazione di WordPress.
