Velocità del sito e Core Web Vitals

La velocità di un sito influenza sia il crawl budget che i robot gli dedicano, sia l'esperienza reale dei visitatori: un sito lento viene esplorato meno spesso e meno a fondo, e perde visitatori ancora prima che abbiano letto il contenuto. I Core Web Vitals sono lo strumento standard per misurare questa velocità in modo comparabile da un sito all'altro.

Perché la velocità influenza il crawl budget e l'esperienza

Il crawl budget indica il numero di pagine che un robot è disposto a esplorare sul tuo sito in un dato periodo di tempo. Questo budget non è illimitato: dipende in parte dalla capacità del tuo server di rispondere rapidamente. Si osserva generalmente che un sito lento o instabile spinge i robot a ridurre la frequenza di passaggio e il numero di pagine esplorate per visita, il che rallenta meccanicamente la scoperta di nuovi contenuti e il loro aggiornamento nell'indice.

Sul fronte utente, l'effetto è più diretto: un tempo di caricamento lungo aumenta il tasso di abbandono ancora prima che il contenuto venga visualizzato. Per un obiettivo GEO, questo conta doppiamente: una pagina lenta ha meno probabilità di essere esplorata da un crawler IA, e meno probabilità di essere letta fino in fondo da un utente che clicca a partire da una risposta generata.

Le tre metriche Core Web Vitals spiegate

Google ha definito tre metriche che, insieme, formano i Core Web Vitals:

• LCP (Largest Contentful Paint): il tempo necessario per visualizzare l'elemento più grande visibile a schermo (spesso un'immagine principale o un titolo). Obiettivo generalmente consigliato: sotto i 2,5 secondi.
• INP (Interaction to Next Paint): il ritardo tra un'interazione dell'utente (clic, pressione di un tasto) e il corrispondente aggiornamento visivo. Questa metrica ha sostituito il FID (First Input Delay) nel 2024. Obiettivo generalmente consigliato: sotto i 200 millisecondi.
• CLS (Cumulative Layout Shift): la misura degli spostamenti visivi inattesi durante il caricamento (un pulsante che si sposta un attimo prima che tu ci clicchi sopra, ad esempio). Obiettivo generalmente consigliato: sotto 0,1.

Queste soglie sono riferimenti indicativi comunicati da Google, non regole assolute valide in ogni contesto: un sito con molto contenuto interattivo complesso può tollerare margini leggermente diversi a seconda del suo utilizzo.

Misurare con PageSpeed Insights (e perché non basta)

pagespeed.web.dev è lo strumento di riferimento per testare una pagina specifica. Fornisce due tipi di dati, da non confondere:

• I dati sul campo (Field Data), provenienti dal Chrome User Experience Report, che riflettono l'esperienza reale dei tuoi visitatori negli ultimi 28 giorni — disponibili solo se il tuo sito riceve traffico Chrome sufficiente.
• I dati di laboratorio (Lab Data), generati durante un test simulato nel momento in cui avvii l'analisi — utili per la diagnosi, ma che possono variare da un test all'altro a seconda delle condizioni di rete simulate.

Il report Core Web Vitals di Google Search Console, visto in una lezione precedente, completa questo strumento offrendo una vista aggregata sull'intero sito anziché pagina per pagina, il che aiuta a stabilire le priorità per template piuttosto che per singolo URL.

Mobile e desktop: due realtà distinte

I Core Web Vitals vengono valutati separatamente per mobile e desktop, e i risultati spesso divergono in modo netto tra i due. Dato che la maggior parte del traffico web avviene oggi da mobile, e che Google utilizza l'indicizzazione "mobile-first" (è la versione mobile della tua pagina a fungere da riferimento per l'esplorazione e la valutazione), è consigliabile trattare i risultati mobile come prioritari in caso di scelta. Un sito che ottiene buoni punteggi su desktop ma punteggi mediocri su mobile resta, dal punto di vista di Google, un sito con un problema di velocità da correggere.

Le correzioni più frequenti e il loro ordine di priorità

Nella maggior parte degli audit, i guadagni più rapidi derivano da:

1. Compressione e ridimensionamento delle immagini: servire le immagini nella dimensione effettivamente visualizzata, in un formato moderno (WebP o AVIF), con caricamento differito (lazy loading) per le immagini fuori schermo.
2. Riduzione del JavaScript bloccante: rimandare il caricamento degli script non essenziali al rendering iniziale (chat online, widget di terze parti, pixel pubblicitari secondari).
3. Riserva di spazio per gli elementi dinamici: definire dimensioni esplicite per immagini, video e pubblicità prima del loro caricamento, per evitare spostamenti di layout (CLS).
4. Caching e CDN: utilizzare una content delivery network per avvicinare i file statici ai visitatori, e configurare una cache del browser adeguata.
5. Scelta dell'hosting: un hosting condiviso economico resta spesso il fattore limitante più difficile da correggere senza cambiare soluzione tecnica.

Monitorare l'impatto nel tempo

Dopo ogni correzione significativa, riverifica con PageSpeed Insights e monitora il report Core Web Vitals di Search Console nelle settimane successive piuttosto che nell'ora successiva: i dati sul campo si basano su una finestra scorrevole di 28 giorni e non reagiscono istantaneamente a un cambiamento.

Una volta sotto controllo la velocità, la base tecnica del sito è sostanzialmente posta. È il momento di affrontare il controllo dell'accesso dei robot con la lezione su il file robots.txt e il controllo dei crawler IA, per poi capire nel dettaglio come un motore legge una pagina.