Come velocizzare un sito web usando Core Web Vitals e dati reali

Spesso i siti web vengono velocizzati nell’ordine sbagliato: qualcuno installa un plugin di ottimizzazione, attiva ogni opzione e poi cerca di capire perché il modulo non funziona più. L’ordine corretto è misurare, formulare un’ipotesi, apportare una sola modifica, verificare il funzionamento e misurare di nuovo.

In una versione precedente descrivevo anche approcci che oggi non raccomando più, come eseguire localmente gli script di terze parti o adottare in generale AMP e PWA. Portavano miglioramenti parziali nei test di laboratorio, ma aggiungevano il rischio di codice obsoleto, aggiornamenti non funzionanti e manutenzione più complessa. Un sito moderno dovrebbe essere veloce nella sua versione principale.

Cosa misurare oggi

Per i Core Web Vitals, Google utilizza tre metriche stabili:

• LCP: caricamento del contenuto principale; un buon valore è fino a 2.5 secondi.
• INP: risposta alle interazioni; un buon valore è inferiore a 200 millisecondi.
• CLS: spostamenti imprevisti del layout; un buon valore è al massimo 0.1.

Le soglie si applicano al 75° percentile e sono riepilogate nella panoramica ufficiale Core Web Vitals per la Ricerca Google. I risultati dei visitatori reali in Search Console o CrUX hanno la precedenza su un singolo test di laboratorio eseguito sul mio portatile.

Gli strumenti di laboratorio restano importanti: mostrano il waterfall, il thread principale, il codice inutilizzato e candidati concreti alla correzione. I dati sul campo indicano che esiste un problema; il laboratorio aiuta a spiegare perché.

Definisci prima l’ambito del problema

1. Confronta mobile e desktop.
2. Separa i template: home page, articolo, servizio, elenco, modulo e negozio online.
3. Controlla Paesi, dispositivi e fonti di traffico veloci e lenti.
4. Individua i gruppi di URL con dati sul campo scadenti.
5. Acquisisci una traccia di laboratorio ripetibile per una pagina rappresentativa.

Una home page veloce non significa che il sito sia veloce. Una visita lenta su un vecchio telefono non significa che l’intero sistema debba essere riscritto.

Interventi con l’impatto più frequente

1. Server e HTML

Misura il tempo al primo byte e dividilo in DNS, connessione, attesa del server e reindirizzamenti. Le attese lunghe possono dipendere dall’hosting, dal database, da una pagina non memorizzata nella cache, da un’API lenta o da catene di reindirizzamenti. Attiva una cache delle pagine adatta per i contenuti pubblici e una cache degli oggetti dove ha senso. Escludi correttamente dalla cache gli utenti autenticati, i carrelli e la personalizzazione.

2. Immagine principale

LCP spesso coincide con l’immagine hero. Fornisci una dimensione adeguata alla visualizzazione, usa srcset, compressione e i moderni WebP o AVIF con un fallback sensato. Non caricare in modalità lazy l’immagine principale; applica il lazy loading alle immagini sotto la prima viewport. Imposta larghezza e altezza dell’immagine, così il browser riserva lo spazio e il CLS resta basso.

3. CSS e font

Rimuovi con attenzione gli stili inutilizzati e mantieni piccolo il CSS critico. Limita i font ai pesi e ai set di caratteri necessari, memorizza a lungo nella cache i file locali e precarica solo un font realmente necessario nelle fasi iniziali. Precaricare dieci font crea semplicemente un’altra coda.

4. JavaScript e interazione

Dividi i bundle di grandi dimensioni, rimanda il codice non critico e carica i servizi di terze parti solo quando servono e il consenso lo consente. async e defer non sono formule magiche: verifica l’ordine e le dipendenze degli script. Suddividi le attività lunghe del thread principale e non far attendere un clic agli strumenti di analisi.

5. Servizi di terze parti

Chat, heatmap, pixel pubblicitari, video e strumenti A/B aggiungono richieste di rete e lavoro per il processore. Ogni script deve avere un responsabile e una ragione aziendale. Non caricarlo in modo sincrono nell’header solo perché la guida d’installazione è più breve. L’analisi può essere gestita tramite Google Tag Manager, ma il container non può risolvere da solo i problemi di prestazioni.

WordPress: meno livelli, più controllo

La documentazione di WordPress raccomanda di intervenire sulle prestazioni attraverso hosting, quantità e qualità dei plugin, immagini, cache e rete di distribuzione. Leggi la panoramica sull’ottimizzazione e la spiegazione separata della cache.

• Aggiorna prima WordPress, PHP, il tema e i plugin in staging.
• Rimuovi i plugin inutilizzati e gli strumenti sovrapposti per cache o minificazione.
• Analizza le query del database e le chiamate esterne lente.
• Pianifica la manutenzione del database, ma non eliminare alla cieca revisioni o metadati.
• Dopo ogni ottimizzazione, testa moduli, ricerca, accesso e flusso d’acquisto.

Discuto della scelta sensata degli add-on nell’articolo sui migliori plugin per WordPress.

Cosa non fare

• Non scaricare sul tuo server gli script di analisi o pubblicitari di altri solo per migliorare un punteggio; potresti perdere aggiornamenti di sicurezza e funzionalità.
• Non impostare una cache di un anno per un file soggetto a modifiche senza includere la versione nel nome.
• Non rimuovere CSS o JavaScript da un report automatico senza testare ogni template.
• Non valutare il successo solo con Lighthouse. Google afferma esplicitamente che buoni Core Web Vitals da soli non garantiscono posizionamenti elevati o un’ottima esperienza utente.
• Non velocizzare un sito nascondendo contenuti o funzioni di cui il cliente ha bisogno.

Un piano di quattro settimane

1. Settimana 1: baseline dei dati sul campo, misurazioni di laboratorio ed elenco dei template.
2. Settimana 2: server, cache, reindirizzamenti e risorse LCP più grandi.
3. Settimana 3: immagini, font, CSS, JavaScript e servizi di terze parti.
4. Settimana 4: test di regressione, nuove misurazioni, monitoraggio e documentazione.

Per ogni modifica registra data, URL, metrica prima e dopo, impatto funzionale e possibilità di rollback. Tieni traccia anche del tasso di conversione, del completamento dei moduli e degli errori; una pagina più veloce che vende meno non è un’ottimizzazione conclusa.

Inizia controllando le basi tecniche e l’analisi del sito con un audit tecnico e GA4. Se devi stabilire le priorità degli interventi in base a impatto e costi, contattami tramite contatti.