Core Web Vitals: LCP, INP e CLS

Modulo 4: Velocità, mobile e https · Tempo di lettura: 13 minuti

Obiettivo della lezione: Al termine di questa lezione saprà spiegare i tre Core Web Vitals con le rispettive soglie, indicare la differenza tra dati sul campo e dati di laboratorio, leggere una misurazione con PageSpeed Insights, intervenire sulle cause principali di un punteggio scarso e valutare onestamente quanto pesa la velocità nei risultati di ricerca.

Concetti chiave: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75° percentile, dati sul campo (CrUX), dati di laboratorio (Lighthouse), PageSpeed Insights, rapporto Core Web Vitals in Search Console, TTFB, compressione, width e height nelle immagini, loading="lazy", esperienza sulla pagina

La velocità in tre numeri

"Il mio sito è veloce?" è una domanda vaga. Google e gli sviluppatori di Chrome l'hanno trasformata in tre domande misurabili, i Core Web Vitals:

Alcuni aspetti da comprendere bene:

• LCP misura il momento in cui compare l'elemento visibile più grande. Di solito si tratta di una grande foto in alto (la cosiddetta "hero") o di un ampio blocco di testo. Per Bloemenatelier Lotte è la foto della composizione floreale nella homepage.
• INP considera tutti i clic, i tocchi e le pressioni dei tasti durante la visita e riporta (quasi) la reazione più lenta. Il 12 marzo 2024 INP ha sostituito la metrica precedente FID (First Input Delay), che considerava solo il primo clic e soltanto l'attesa prima dell'elaborazione. Se trova FID in un vecchio articolo, quell'informazione è superata.
• CLS non è un tempo, ma un punteggio senza unità di misura. Aumenta quando gli elementi si spostano mentre si legge: si vuole toccare un pulsante e proprio in quel momento compare un banner sopra, così si tocca qualcos'altro.

Il 75° percentile

Una pagina "supera" i Core Web Vitals quando il 75 percento delle visite ottiene un buon risultato su tutte e tre le metriche, misurate separatamente per dispositivi mobili e desktop. Questo si chiama 75° percentile. Significa che non conta il Suo computer veloce con la fibra ottica, ma l'esperienza della maggior parte dei visitatori, anche di chi usa un telefono meno recente con il 4G.

Dati sul campo e dati di laboratorio

Esistono due tipi di misurazione, e spesso danno numeri diversi.

• I dati sul campo provengono da visitatori reali. Chrome raccoglie in forma anonima (per gli utenti che lo consentono) la velocità delle pagine nel Chrome User Experience Report (CrUX). PageSpeed Insights mostra i dati sul campo degli ultimi 28 giorni. Il rapporto Core Web Vitals in Search Console utilizza la stessa fonte. Se la Sua pagina ha troppo pochi visitatori, PageSpeed Insights mostra i dati dell'intero sito (l'"origine"), e se anche questi sono insufficienti, i dati sul campo non sono disponibili.
• I dati di laboratorio provengono da un test simulato con Lighthouse: un unico caricamento su un telefono e una connessione di livello medio simulati. Lighthouse non può misurare INP (nessuno clicca), e per questo fornisce altri valori, come il Total Blocking Time, che offrono comunque un'indicazione su INP.

Per la valutazione contano i dati sul campo. I dati di laboratorio sono utili per individuare le cause e per verificare subito, dopo un miglioramento, se è servito, senza attendere 28 giorni.

Quanto pesa?

Su questo punto si esagera molto. Ecco che cosa dice Google stessa nella documentazione sull'esperienza sulla pagina:

• "Core Web Vitals are used by our ranking systems": quindi contano.
• Non esiste un "segnale di esperienza sulla pagina" a sé stante. Secondo Google, altri aspetti di una buona esperienza sulla pagina (https, nessun pop-up invadente, usabilità su mobile) non La aiutano direttamente a salire in classifica, ma rendono il Suo sito più piacevole.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Una pagina lenta con la risposta migliore può quindi trovarsi tranquillamente in cima.
• Secondo Google, ottenere un punteggio perfetto solo per la SEO "potrebbe non essere il miglior uso del Suo tempo".

Conclusione: faccia in modo di trovarsi nella zona verde o almeno in quella arancione, soprattutto perché i visitatori abbandonano una pagina lenta o instabile. Inseguire il passaggio da 90 a 100 punti in Lighthouse porta poco nei risultati di ricerca.

Le cause su cui può intervenire da solo

Una prima risposta lenta (TTFB)

Tutto comincia dal momento in cui arriva il primo byte dell'HTML, il Time to First Byte. Il TTFB non è di per sé un Core Web Vital, ma un TTFB lento rende quasi impossibile un buon LCP. web.dev indica come valore di riferimento: buono è 0,8 secondi o meno, scarso è oltre 1,8 secondi. Le cause secondo web.dev: potenza di calcolo insufficiente dell'hosting, assenza di cache (ogni pagina viene ricostruita da zero, tipico di WordPress senza plugin di cache), reindirizzamenti (lezione 4.1) e un server lontano senza CDN.

Anche la compressione rientra in questo ambito: il server dovrebbe inviare HTML, CSS e JavaScript compressi con gzip o Brotli. Lo si riconosce dall'intestazione Content-Encoding: gzip o br. Quasi tutti gli hosting lo fanno di serie, ma un'impostazione errata o un server datato possono disattivarla.

Immagini

Le immagini sono la causa più frequente di un LCP e di un CLS scarsi:

1. Troppo grandi. Una foto larga 4.000 pixel e pesante 5 MB per uno spazio di 800 pixel. La riduca prima del caricamento e utilizzi un formato moderno come WebP o AVIF.

2. Nessuna larghezza e altezza. Senza width e height il browser non sa quanto spazio occupa l'immagine, e il testo sottostante si sposta non appena l'immagine arriva. web.dev consiglia di indicare width e height in ogni <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Caricare in modalità lazy la foto più importante. loading="lazy" fa caricare un'immagine solo quando entra nella schermata. Va benissimo per le foto più in basso, ma web.dev è chiaro: le immagini già visibili all'apertura, e in particolare l'immagine LCP, non vanno caricate in modalità lazy. Altrimenti il browser rimanda proprio la foto che determina il Suo LCP.

Contenuti che si spostano e reazioni lente

Altre cause di CLS secondo web.dev: caratteri che cambiano dimensione durante il caricamento, annunci pubblicitari e widget incorporati che si ingrandiscono da soli, e contenuti inseriti in seguito sopra quelli esistenti (come una barra dei cookie che spinge la pagina verso il basso invece di sovrapporsi). Un INP scarso dipende quasi sempre da troppo JavaScript: temi pesanti, slider, widget di chat e tracker di terze parti. Valuti con occhio critico ogni plugin o servizio incorporato; qui meno è davvero meglio.

In pratica: misurare con PageSpeed Insights

Vada su pagespeed.web.dev, inserisca l'indirizzo della Sua homepage e faccia clic su Analizza. Otterrà due schede (Dispositivi mobili e Desktop). In alto si trova la valutazione dei Core Web Vitals basata sui dati sul campo, se disponibili. Sotto c'è il test Lighthouse con un punteggio e un elenco "Diagnostica" con punti concreti, ad esempio sulle immagini più grandi del necessario o su un'immagine LCP caricata in modalità lazy (i nomi esatti cambiano con le nuove versioni di Lighthouse). Inizi da Dispositivi mobili: lì i risultati sono di solito peggiori, e Google guarda prima alla versione mobile (lezione 4.2).

Se il Suo sito è in Search Console (modulo 2), controlli anche in Esperienza, Segnali web essenziali (Core Web Vitals). Lì vedrà gruppi di pagine simili con il loro stato, anche per pagine che non aveva testato personalmente.

Un sito realizzato con AI Builder indica larghezza e altezza per le immagini di cui sono note le dimensioni, carica la prima foto della pagina subito e con priorità (fetchpriority="high") e le altre in modalità lazy, e al momento della pubblicazione crea una variante larga 800 pixel delle foto grandi. In WordPress aiutano soprattutto un plugin di cache e la riduzione delle immagini; il corso su WordPress approfondisce l'argomento nel modulo 6. Con altri strumenti per creare siti e altri hosting il funzionamento è simile: i pulsanti cambiano, le cause sono le stesse.

Riepilogo

• I Core Web Vitals sono LCP (buono fino a 2,5 s), INP (buono fino a 200 ms, dal marzo 2024 al posto di FID) e CLS (buono fino a 0,1), misurati al 75° percentile per tipo di dispositivo.
• I dati sul campo (CrUX, 28 giorni) determinano la valutazione; i dati di laboratorio (Lighthouse) aiutano a trovare le cause.
• Google utilizza i Core Web Vitals nel posizionamento, ma la pertinenza viene prima: un punteggio perfetto non è un obiettivo in sé.
• Il guadagno maggiore: risposta rapida del server con cache e compressione, immagini leggere con width e height, la foto più importante non caricata in modalità lazy, meno JavaScript di terze parti.

Quiz

Esercizio

Esercizio A4.3: Risposta rapida e immagini leggere. Inserisca l'indirizzo di una pagina. Il programma misura tre volte il tempo fino al primo byte (TTFB) dal nostro server e prende il valore centrale, verifica se l'HTML viene inviato compresso (gzip, Brotli o zstd), conta le immagini senza width e height e controlla che l'immagine principale in alto non venga caricata con loading="lazy". Attenzione: si tratta di una misurazione da un unico punto, non di una misurazione dei Suoi visitatori. Non ha un sito proprio? Utilizzi www.wikipedia.org.

Esercizio D4.3: I Suoi Core Web Vitals. Esegua PageSpeed Insights sulla Sua homepage e su un'altra pagina importante, iniziando da Dispositivi mobili. Annoti per ciascuna pagina: se ci sono dati sul campo (della pagina o dell'intero sito), i valori LCP, INP e CLS dai dati sul campo, il punteggio Lighthouse e l'elemento che Lighthouse indica come elemento LCP. Scelga l'unico miglioramento che secondo Lei porta il risultato maggiore e spieghi perché.

Per approfondire

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Guida di Search Console, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520