I Core Web Vitals, conosciuti in italiano come Segnali web essenziali, sono tre metriche definite da Google per valutare alcuni aspetti dell’esperienza degli utenti durante la navigazione di un sito web. Misurano la velocità con cui viene visualizzato il contenuto principale, la reattività della pagina alle interazioni e la stabilità degli elementi presenti sullo schermo.
Un sito può caricarsi rapidamente e presentare comunque problemi di usabilità. Può, ad esempio, mostrare subito il contenuto ma impiegare troppo tempo a rispondere al clic su un pulsante. Oppure può visualizzare immagini e testi che cambiano posizione mentre la pagina viene caricata.
Google utilizza i Core Web Vitals anche nei propri sistemi di ranking, ma il loro superamento non garantisce un buon posizionamento nei risultati di ricerca. Le prestazioni costituiscono uno degli aspetti da valutare insieme alla pertinenza dei contenuti e alla qualità complessiva del sito.
Vediamo quali sono i parametri attualmente utilizzati, i valori di riferimento, gli strumenti per misurarli e gli interventi che possono migliorare le prestazioni di un sito web.
Cosa sono i Core Web Vitals
I Core Web Vitals sono un sottoinsieme dei Web Vitals, un insieme più ampio di metriche sviluppato da Google per analizzare le prestazioni delle pagine web dal punto di vista degli utenti.
La loro caratteristica principale è la possibilità di essere misurati durante le visite reali, attraverso browser compatibili e strumenti di raccolta dei dati. Questo permette di valutare le prestazioni effettivamente riscontrate dagli utenti, anziché basarsi esclusivamente su test effettuati in ambienti controllati.
Le tre metriche attualmente utilizzate sono:
- Largest Contentful Paint (LCP): misura il tempo necessario per visualizzare l’elemento di contenuto più grande nell’area visibile della pagina.
- Interaction to Next Paint (INP): misura la reattività della pagina alle interazioni dell’utente.
- Cumulative Layout Shift (CLS): misura gli spostamenti imprevisti degli elementi durante la navigazione.
Queste metriche analizzano aspetti differenti. Una pagina può ottenere un buon risultato LCP ma presentare un INP elevato a causa di JavaScript particolarmente impegnativo. Allo stesso modo, un sito veloce può avere un CLS scarso se immagini, banner o altri elementi vengono inseriti senza riservare preventivamente lo spazio necessario.
Core Web Vitals e Page Experience
I Core Web Vitals rientrano negli aspetti che Google considera quando valuta l’esperienza offerta dalle pagine web, comunemente indicata come Page Experience.
Quest’ultima comprende anche caratteristiche come la sicurezza della connessione HTTPS, la corretta visualizzazione sui dispositivi mobili e l’assenza di elementi invasivi che ostacolano la consultazione dei contenuti.
Non esiste però un singolo punteggio Page Experience che determini automaticamente il posizionamento di una pagina. Google utilizza diversi segnali all’interno dei propri sistemi di ranking.
Perché desktop e mobile possono avere risultati diversi
Le prestazioni dipendono anche dal dispositivo utilizzato, dalla potenza del processore, dalla connessione di rete e dal comportamento del browser.
Uno smartphone con risorse limitate può impiegare più tempo a eseguire JavaScript rispetto a un computer desktop. Una connessione mobile instabile può rallentare il download delle risorse, mentre un layout responsive può caricare elementi differenti a seconda della dimensione dello schermo.
Per questo motivo Google distingue le misurazioni desktop da quelle mobile. Un sito che supera le soglie su desktop potrebbe non rispettarle sui dispositivi mobili.
Quali sono i tre Core Web Vitals di Google
Largest Contentful Paint (LCP): velocità di visualizzazione del contenuto principale
Il Largest Contentful Paint misura il tempo trascorso dall’inizio della navigazione fino al rendering dell’elemento di contenuto più grande presente nell’area visibile della pagina.
L’elemento considerato può essere un’immagine, un blocco di testo o un altro contenuto idoneo alla misurazione. Non coincide necessariamente con il primo elemento visualizzato e può cambiare durante il caricamento.
Per esempio, una pagina può mostrare rapidamente il menu di navigazione e il titolo, ma impiegare diversi secondi per visualizzare l’immagine principale. Se quest’ultima è l’elemento più grande nell’area visibile, sarà probabilmente quella a determinare il valore LCP.
Google considera buono un LCP pari o inferiore a 2,5 secondi.
Quali fattori possono peggiorare l’LCP
- Tempi elevati di risposta del server.
- Immagini principali troppo pesanti o non correttamente dimensionate.
- Fogli CSS e script che ritardano il rendering.
- Risorse principali individuate troppo tardi dal browser.
- Caricamento ritardato dell’immagine LCP tramite lazy loading.
- Rendering del contenuto principale dipendente dall’esecuzione di JavaScript.
Un errore abbastanza comune consiste nell’applicare il lazy loading indiscriminatamente a tutte le immagini, compresa quella principale visibile immediatamente all’apertura della pagina.
Il lazy loading è utile per le immagini fuori dallo schermo, ma può peggiorare l’LCP quando ritarda il caricamento dell’elemento principale.
Come migliorare l’LCP
Il primo intervento consiste nell’identificare quale elemento viene utilizzato per la misurazione. Una volta individuato, si possono analizzare i tempi di risposta del server, il download della risorsa e gli eventuali ritardi di rendering.
Se l’elemento LCP è un’immagine, conviene utilizzare dimensioni appropriate, compressione efficiente e formati moderni come WebP o AVIF. Quando opportuno, si può attribuire una priorità elevata alla risorsa attraverso l’attributo HTML fetchpriority="high".
Se invece l’LCP è rappresentato da un blocco di testo, occorre verificare che i fogli di stile e i font non ne ritardino inutilmente la visualizzazione.
Per approfondire la gestione delle immagini è disponibile la guida WebP e AVIF: i formati immagine per il web.
Interaction to Next Paint (INP): reattività della pagina
L’Interaction to Next Paint misura il tempo che intercorre tra un’interazione dell’utente e il successivo aggiornamento visivo della pagina.
Le interazioni considerate comprendono clic del mouse, tocchi sullo schermo e pressioni dei tasti. Lo scorrimento della pagina e il semplice movimento del puntatore non vengono considerati direttamente come interazioni INP.
Questa metrica permette di individuare situazioni in cui una pagina appare caricata, ma risponde lentamente ai comandi.
Si consideri un e-commerce nel quale viene premuto il pulsante “Aggiungi al carrello”. Se il browser è impegnato nell’esecuzione di uno script e il pulsante non mostra rapidamente alcun cambiamento, l’utente potrebbe pensare che il comando non sia stato ricevuto.
L’INP misura la latenza delle interazioni durante la visita e restituisce un valore rappresentativo delle interazioni più lente, con una gestione specifica dei valori anomali. Non è quindi la semplice media dei tempi di risposta.
Un valore INP pari o inferiore a 200 millisecondi viene considerato buono.
Perché l’INP può essere elevato
Una delle cause più frequenti è l’occupazione prolungata del thread principale del browser, chiamato main thread.
Quando JavaScript esegue operazioni particolarmente lunghe, il browser può ritardare la gestione delle interazioni e il successivo aggiornamento dell’interfaccia.
Le cause possono comprendere script di terze parti, componenti interattivi complessi, elaborazioni sincrone e modifiche ripetute al DOM.
Come migliorare l’INP
Occorre individuare quali interazioni presentano una latenza elevata e verificare le attività eseguite dal browser durante quei momenti.
Tra gli interventi possibili rientrano la suddivisione delle operazioni JavaScript più lunghe, l’eliminazione del codice non utilizzato, la riduzione delle modifiche inutili al DOM e lo spostamento delle elaborazioni compatibili verso Web Worker.
È inoltre opportuno evitare che script non necessari occupino il main thread durante le interazioni più importanti.
Il semplice differimento del caricamento JavaScript non garantisce un INP migliore: uno script può essere caricato successivamente e causare comunque rallentamenti durante la navigazione.
INP e First Input Delay: che cosa è cambiato
Il 12 marzo 2024 Google ha sostituito il First Input Delay (FID) con l’INP tra i Core Web Vitals.
Il FID misurava il ritardo nell’elaborazione della prima interazione, mentre l’INP valuta la reattività durante l’intera visita.
Questo permette di individuare problemi che si manifestano anche dopo il caricamento iniziale, ad esempio durante l’apertura di un menu, la compilazione di un modulo o l’utilizzo di un componente interattivo.
Cumulative Layout Shift (CLS): stabilità visiva della pagina
Il Cumulative Layout Shift misura gli spostamenti imprevisti degli elementi visibili durante l’utilizzo della pagina.
Un esempio tipico è quello di un articolo che inizia a essere visualizzato e, pochi istanti dopo, viene spostato verso il basso perché sopra il testo compare un banner pubblicitario.
Un altro caso riguarda le immagini prive di dimensioni dichiarate. Prima del loro caricamento, il browser potrebbe non sapere quanto spazio riservare. Quando l’immagine viene visualizzata, gli elementi successivi possono cambiare posizione.
Il CLS non è espresso in secondi o millisecondi, ma attraverso un punteggio numerico calcolato in base all’area interessata dagli spostamenti e alla loro distanza relativa.
Google considera buono un CLS pari o inferiore a 0,1.
Le principali cause di un CLS elevato
- Immagini e video senza dimensioni o proporzioni definite.
- Banner pubblicitari inseriti senza spazio riservato.
- Font che modificano sensibilmente le dimensioni del testo quando vengono caricati.
- Elementi dinamici aggiunti sopra contenuti già visualizzati.
- Widget esterni che cambiano dimensione dopo il caricamento.
Come ridurre il CLS
Per immagini e video è opportuno dichiarare larghezza e altezza, oppure definire un rapporto d’aspetto tramite CSS. Il browser può così riservare lo spazio necessario prima che la risorsa venga caricata.
Per banner, iframe e contenuti dinamici conviene predisporre contenitori con dimensioni adeguate, evitando di inserire nuovi elementi sopra il contenuto già presente.
La gestione dei font richiede attenzione. Un font sostitutivo con caratteristiche dimensionali molto diverse da quello definitivo può provocare spostamenti del testo quando avviene la sostituzione.
Non tutti gli spostamenti visivi vengono conteggiati nel CLS. La metrica esclude, ad esempio, determinati spostamenti che avvengono subito dopo un’interazione dell’utente, secondo le regole previste dalla specifica.
Le soglie dei Core Web Vitals richieste da Google
Google utilizza tre intervalli per classificare ciascuna metrica: buono, da migliorare e scarso.
| Parametro | Buono | Da migliorare | Scarso |
|---|---|---|---|
| LCP | ≤ 2,5 s | > 2,5 s e ≤ 4 s | > 4 s |
| INP | ≤ 200 ms | > 200 ms e ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | > 0,1 e ≤ 0,25 | > 0,25 |
Per superare la valutazione dei Core Web Vitals, tutte e tre le metriche devono rispettare le rispettive soglie di qualità nella valutazione basata sui dati reali.
Che cosa significa 75° percentile
Google utilizza il 75° percentile delle misurazioni per classificare le prestazioni rilevate durante le visite reali.
Questo significa che, ordinando i risultati dal migliore al peggiore, il valore considerato si trova al punto in cui circa il 75% delle misurazioni presenta un risultato uguale o migliore.
Si considerino 100 visite a una pagina. Se il valore LCP al 75° percentile è di 2,3 secondi, la metrica rientra nella fascia buona, anche se una parte degli utenti ha registrato tempi superiori.
La scelta del percentile permette di rappresentare l’esperienza della maggior parte degli utenti senza lasciare che pochi valori estremi determinino da soli la classificazione.
Perché un singolo test non basta
Un test eseguito da un computer con una connessione veloce può restituire risultati molto diversi da quelli registrati dagli utenti che visitano abitualmente il sito.
Per questo motivo è necessario distinguere tra misurazioni di laboratorio e dati raccolti durante le visite reali.
Il superamento delle soglie in un singolo test Lighthouse non equivale automaticamente al superamento della valutazione Core Web Vitals basata sui dati sul campo.
Gli altri parametri di prestazione analizzati da Google
Oltre ai Core Web Vitals esistono altre metriche utilizzate per analizzare il comportamento delle pagine. Queste aiutano a identificare le cause dei rallentamenti, ma non devono essere confuse con i tre Segnali web essenziali.
First Contentful Paint (FCP)
Il First Contentful Paint misura il tempo necessario affinché il browser visualizzi il primo contenuto idoneo, come un testo o un’immagine.
Un FCP basso indica che la pagina ha iniziato rapidamente a mostrare qualcosa, ma non significa che il contenuto principale sia già disponibile.
È possibile avere un FCP di 0,8 secondi e un LCP di 4 secondi. In questo caso il browser ha iniziato presto a visualizzare la pagina, ma l’elemento principale è arrivato molto più tardi.
Google considera buono un FCP pari o inferiore a 1,8 secondi. Per approfondire i valori di riferimento, le differenze rispetto all’LCP e gli interventi di ottimizzazione, è disponibile la guida FCP: cos’è il First Contentful Paint.
Time to First Byte (TTFB)
Il Time to First Byte misura il tempo trascorso dall’inizio della richiesta di navigazione fino alla ricezione del primo byte della risposta.
Il valore può comprendere diverse fasi, tra cui redirect, connessione e attesa della risposta del server. Non rappresenta quindi esclusivamente il tempo impiegato dal software server per elaborare una richiesta.
Un TTFB elevato può ritardare il caricamento delle risorse successive e peggiorare l’LCP.
Per approfondire il funzionamento della metrica e le possibili ottimizzazioni è disponibile l’articolo Che cos’è il TTFB e come migliorare il Time to First Byte.
Speed Index (SI)
Lo Speed Index descrive la velocità con cui i contenuti visibili della pagina vengono progressivamente mostrati durante il caricamento.
Viene calcolato attraverso l’analisi dell’evoluzione visiva della pagina nel corso del test.
È una metrica utile per comprendere quanto rapidamente la pagina appare completa all’utente, anche se non misura direttamente la reattività alle interazioni.
Total Blocking Time (TBT)
Il Total Blocking Time misura il tempo complessivo durante il quale il main thread rimane bloccato da attività sufficientemente lunghe da poter ritardare la risposta agli input.
Nel calcolo vengono considerate le porzioni superiori a 50 millisecondi delle attività lunghe, nell’intervallo tra FCP e Time to Interactive.
Il TBT è particolarmente utile nei test di laboratorio per individuare problemi legati all’esecuzione di JavaScript.
Può fornire indicazioni sui problemi che influenzano anche l’INP, ma le due metriche non sono equivalenti. Il TBT analizza una fase del caricamento, mentre l’INP considera le interazioni effettive durante la visita.
Perché un buon TTFB non garantisce un buon LCP
Si consideri una pagina con un TTFB di 150 millisecondi. Il server risponde rapidamente, ma il browser deve ancora scaricare un’immagine principale di grandi dimensioni, elaborare i fogli di stile ed eseguire eventuali script.
Se queste operazioni richiedono diversi secondi, l’LCP può risultare scarso nonostante la risposta iniziale del server sia veloce.
Questo esempio mostra perché l’ottimizzazione delle prestazioni deve considerare l’intero percorso di caricamento, dal server fino al rendering nel browser.
Come misurare i Core Web Vitals di un sito web
Per analizzare correttamente le prestazioni conviene utilizzare strumenti che restituiscano sia dati reali sia informazioni diagnostiche.
Google PageSpeed Insights
Google PageSpeed Insights permette di analizzare una pagina inserendone l’indirizzo URL.
Lo strumento presenta, quando disponibili, i dati reali raccolti attraverso il Chrome User Experience Report e i risultati di un test di laboratorio eseguito con Lighthouse.
La sezione dedicata ai dati reali mostra le metriche disponibili e la loro classificazione. Il rapporto diagnostico fornisce invece informazioni sulle risorse che rallentano il caricamento e sugli interventi possibili.
È importante non confondere il punteggio Performance, espresso su una scala da 0 a 100, con la valutazione dei Core Web Vitals.
Un sito può ottenere un punteggio Lighthouse elevato e avere comunque un INP scarso nei dati reali.
Google Search Console
Il rapporto Segnali web essenziali di Google Search Console permette di individuare gruppi di pagine con problemi di prestazioni.
Il rapporto distingue i risultati per dispositivi mobili e desktop e utilizza dati reali provenienti da CrUX.
Le pagine vengono raggruppate in base a problemi simili, permettendo di individuare situazioni che coinvolgono più URL.
Se, ad esempio, numerose pagine di una stessa tipologia presentano un CLS elevato, può essere opportuno controllare gli elementi comuni del template, come header, banner e contenitori delle immagini.
Search Console non sostituisce un’analisi dettagliata delle singole pagine. È particolarmente utile per individuare problemi ricorrenti e verificare nel tempo l’effetto delle modifiche.
Lighthouse e Chrome DevTools
Lighthouse è uno strumento di analisi automatizzata che può essere utilizzato direttamente attraverso Chrome DevTools.
Consente di effettuare test di laboratorio e ottenere indicazioni sulle prestazioni, sull’accessibilità e su altri aspetti tecnici della pagina.
Chrome DevTools mette inoltre a disposizione strumenti di profilazione che permettono di analizzare l’esecuzione di JavaScript, le richieste di rete, il rendering e le interazioni.
Questi strumenti risultano particolarmente utili quando occorre identificare il codice responsabile di un ritardo o di uno spostamento del layout.
Chrome User Experience Report (CrUX)
Il Chrome User Experience Report è un insieme di dati aggregati e anonimizzati relativi alle esperienze di navigazione di utenti Chrome idonei alla raccolta.
CrUX costituisce una delle principali fonti utilizzate dagli strumenti Google per presentare i Core Web Vitals reali.
I dati non sono necessariamente disponibili per ogni pagina. In assenza di un volume sufficiente di misurazioni idonee, PageSpeed Insights può mostrare dati aggregati a livello di origine oppure non mostrare dati reali.
I dati CrUX presentati nei report ordinari fanno riferimento a una finestra mobile di 28 giorni. Di conseguenza, una modifica tecnica effettuata oggi non produce necessariamente un cambiamento immediato nei risultati aggregati.
Quale strumento conviene utilizzare
PageSpeed Insights è indicato per una prima analisi della singola pagina. Search Console permette di individuare problemi distribuiti su più URL, mentre Chrome DevTools è utile per diagnosticare le cause tecniche.
Per un confronto più approfondito tra i diversi sistemi di misurazione è disponibile l’articolo Performance: PageSpeed Insights vs GTmetrix vs Lighthouse.
Come migliorare i Core Web Vitals
Non esiste una configurazione valida per qualsiasi sito. Gli interventi devono essere scelti in base alle metriche che presentano problemi e alle risorse effettivamente responsabili dei rallentamenti.
Ottimizzare immagini e contenuti multimediali
Le immagini possono incidere in modo significativo sul caricamento, soprattutto quando costituiscono l’elemento LCP.
Occorre verificare che le dimensioni dei file siano coerenti con quelle di visualizzazione, utilizzare una compressione adeguata e scegliere formati efficienti.
WebP e AVIF permettono spesso di ridurre il peso dei file rispetto a formati meno efficienti, mantenendo una qualità visiva adeguata.
È inoltre opportuno utilizzare immagini responsive attraverso srcset e sizes, in modo che il browser possa selezionare una risorsa appropriata al dispositivo.
Per le immagini non immediatamente visibili può essere utilizzato il lazy loading. L’immagine principale responsabile dell’LCP dovrebbe invece essere caricata senza ritardi non necessari.
Utilizzare correttamente la cache
La cache permette di ridurre il lavoro necessario per servire risorse o generare pagine già richieste in precedenza.
La cache del browser evita di scaricare nuovamente determinate risorse statiche. La cache delle pagine può ridurre il tempo di generazione dell’HTML sul server.
Nei siti WordPress, sistemi come LiteSpeed Cache possono intervenire sulla gestione della cache e su diverse operazioni di ottimizzazione.
Le impostazioni devono essere verificate con attenzione, soprattutto nei siti che utilizzano carrelli, aree riservate o contenuti personalizzati.
Per le configurazioni WordPress è disponibile la guida Come configurare LiteSpeed Cache e il suo Crawler.
Ridurre CSS e JavaScript che rallentano il rendering
Fogli di stile e script possono ritardare la visualizzazione dei contenuti o bloccare temporaneamente il main thread.
La minificazione riduce la dimensione dei file eliminando caratteri non necessari, ma non risolve automaticamente i problemi legati all’esecuzione del codice.
Per migliorare le prestazioni è spesso più utile eliminare risorse non utilizzate, ridurre le dipendenze e caricare gli script nel momento appropriato.
Gli attributi defer e async possono modificare il comportamento di caricamento degli script esterni, ma devono essere utilizzati tenendo conto delle dipendenze tra i componenti.
Nei siti WordPress è opportuno verificare anche quali plugin caricano risorse JavaScript e CSS su pagine che non ne hanno bisogno.
Gestire correttamente i font
I font web possono incidere sia sui tempi di visualizzazione sia sulla stabilità del layout.
Quando un font viene caricato in ritardo, il browser può inizialmente utilizzare un carattere sostitutivo. Se le dimensioni dei due font sono molto diverse, il testo può cambiare disposizione al momento della sostituzione.
Per ridurre questi problemi conviene limitare le varianti caricate, utilizzare formati compressi come WOFF2 e valutare le opzioni di font-display.
Il precaricamento dei font può essere utile per le risorse effettivamente necessarie alla visualizzazione iniziale, ma un numero eccessivo di preload rischia di sottrarre priorità ad altre risorse importanti.
Utilizzare una CDN quando necessario
Una Content Delivery Network distribuisce determinate risorse attraverso server collocati in diverse aree geografiche.
Questo può ridurre la latenza e migliorare i tempi di consegna, soprattutto quando gli utenti si trovano lontano dal server di origine.
Il beneficio dipende dalla configurazione della CDN, dalla tipologia dei contenuti e dalla distribuzione geografica dei visitatori.
Una CDN non corregge automaticamente JavaScript inefficiente, immagini mal dimensionate o problemi di layout.
Per approfondire è disponibile l’articolo CDN: cosa sono e a che cosa servono.
Controllare le risorse di terze parti
Script pubblicitari, sistemi di tracciamento, widget social, video incorporati e altri componenti esterni possono introdurre richieste aggiuntive e attività JavaScript.
Prima di intervenire conviene verificare quali risorse vengono effettivamente utilizzate e quale impatto producono.
Quando possibile, i componenti non necessari al caricamento iniziale possono essere differiti. Occorre però evitare che il caricamento successivo introduca spostamenti del layout o rallentamenti durante le interazioni.
Quanto incide l’hosting sui Core Web Vitals
L’infrastruttura hosting può influenzare i tempi di risposta del server e la velocità con cui vengono consegnate le risorse richieste dal browser.
Il suo impatto è particolarmente evidente quando il sito genera dinamicamente le pagine, esegue numerose interrogazioni al database o deve gestire molte richieste contemporanee.
Tempi di risposta e risorse del server
CPU, memoria RAM, prestazioni dello storage e configurazione del software server possono influire sul tempo necessario per elaborare una richiesta.
Un sito WordPress con numerosi plugin e interrogazioni al database può presentare tempi di generazione elevati quando le risorse disponibili non sono sufficienti o il codice applicativo è inefficiente.
In questi casi l’ottimizzazione può richiedere interventi sia sull’applicazione sia sull’ambiente server.
Cache lato server e database
Una cache delle pagine configurata correttamente può evitare di eseguire PHP e interrogazioni al database per ogni richiesta compatibile con la cache.
Una object cache, ad esempio basata su Redis, può ridurre il costo di determinate operazioni ripetute sul database e sugli oggetti applicativi.
I due sistemi svolgono funzioni differenti. La cache delle pagine conserva risposte già generate, mentre la object cache memorizza dati e risultati utilizzati dall’applicazione.
L’effetto sulle prestazioni dipende dal tipo di sito, dal rapporto tra richieste servite dalla cache e richieste dinamiche e dalla configurazione complessiva.
HTTP/2, HTTP/3 e compressione
I protocolli HTTP/2 e HTTP/3 introducono meccanismi che possono migliorare la gestione delle connessioni e delle richieste rispetto a HTTP/1.1.
La compressione delle risorse testuali, attraverso algoritmi come Brotli o gzip, permette inoltre di ridurre la quantità di dati trasferiti.
Queste tecnologie possono migliorare la consegna delle risorse, ma non eliminano i tempi necessari al browser per interpretare CSS, eseguire JavaScript e costruire il layout.
Quando il problema non dipende dall’hosting
Un sito può essere ospitato su un server veloce e presentare comunque risultati Core Web Vitals insufficienti.
Un CLS elevato causato da immagini senza dimensioni, ad esempio, non viene risolto aumentando la RAM del server.
Allo stesso modo, un INP scarso dovuto a script JavaScript particolarmente pesanti richiede generalmente interventi sul codice eseguito dal browser.
Quando si analizzano le prestazioni è quindi necessario separare i problemi dell’infrastruttura da quelli dell’applicazione e del frontend.
Un servizio hosting WordPress con supporto per sistemi di cache e risorse adeguate può contribuire a ridurre i tempi di risposta e a rendere più efficiente la distribuzione dei contenuti. Il raggiungimento di buoni Core Web Vitals dipende comunque anche dall’ottimizzazione del sito.
Core Web Vitals e SEO: quanto influiscono sul posizionamento
Google ha confermato che i Core Web Vitals vengono utilizzati dai propri sistemi di ranking, ma non ha indicato un peso numerico fisso valido per tutte le ricerche.
Non è quindi corretto affermare che il miglioramento di una metrica produca automaticamente un determinato aumento delle posizioni nei risultati di ricerca.
I sistemi di Google cercano principalmente di mostrare contenuti pertinenti e utili rispetto alle ricerche effettuate dagli utenti.
Una pagina con contenuti particolarmente pertinenti può posizionarsi bene anche quando presenta prestazioni non ottimali. Viceversa, un sito tecnicamente veloce non ottiene automaticamente visibilità se i contenuti non rispondono alle esigenze di ricerca.
Perché PageSpeed 100/100 non garantisce il primo posto
Il punteggio Performance di Lighthouse viene calcolato attraverso una combinazione ponderata di metriche rilevate durante un test di laboratorio.
Non corrisponde al valore utilizzato direttamente da Google per determinare il posizionamento di una pagina.
Ottenere 100/100 può indicare risultati molto buoni nelle condizioni del test, ma non dimostra che tutti gli utenti abbiano la stessa esperienza e non garantisce il superamento delle soglie Core Web Vitals nei dati reali.
La valutazione SEO deve quindi considerare separatamente la qualità dei contenuti, gli aspetti tecnici che consentono ai motori di ricerca di accedere alle pagine e le prestazioni riscontrate dagli utenti.
Come stabilire le priorità di ottimizzazione
Quando una pagina presenta più problemi, conviene partire dalle metriche classificate come scarse e individuare gli elementi responsabili.
Un LCP elevato può richiedere interventi sul caricamento delle immagini, sul server o sulle risorse che bloccano il rendering.
Un INP elevato richiede invece un’analisi delle interazioni e del lavoro svolto dal main thread.
Per il CLS occorre verificare gli spostamenti del layout e identificare quali elementi vengono ridimensionati o inseriti durante la navigazione.
Dopo ogni modifica è opportuno ripetere i test di laboratorio e osservare l’evoluzione dei dati reali, evitando di valutare il risultato sulla base di una sola misurazione.
Domande frequenti sui Core Web Vitals
Qual è un buon punteggio PageSpeed Insights?
Nel punteggio Performance di Lighthouse, i valori da 90 a 100 rientrano nella fascia buona, quelli da 50 a 89 richiedono miglioramenti e quelli inferiori a 50 sono considerati scarsi.
Queste soglie riguardano il punteggio Lighthouse e non devono essere confuse con le soglie LCP, INP e CLS.
È necessario raggiungere 100/100 su PageSpeed Insights?
No. Google non richiede un punteggio PageSpeed di 100/100. È più utile verificare che le pagine offrano una buona esperienza reale e che i Core Web Vitals rispettino le soglie consigliate.
Google penalizza i siti con Core Web Vitals scarsi?
I Core Web Vitals vengono utilizzati nei sistemi di ranking, quindi prestazioni insufficienti possono rappresentare uno svantaggio. Non esiste però una penalizzazione automatica e quantificabile associata al mancato superamento di una singola soglia.
Google continua a considerare numerosi altri segnali, a partire dalla pertinenza dei contenuti rispetto alla ricerca.
I Core Web Vitals sono diversi per desktop e mobile?
Le metriche e le soglie sono le stesse, ma le misurazioni vengono valutate separatamente per dispositivi mobili e desktop. Le differenze dipendono dalle condizioni di rete, dalle capacità dei dispositivi e dalle caratteristiche delle pagine.
Ogni quanto vengono aggiornati i dati?
I dati reali CrUX utilizzati nei report ordinari si basano su una finestra mobile di 28 giorni. Le modifiche effettuate al sito possono quindi richiedere tempo prima di riflettersi completamente nei risultati aggregati.
I test Lighthouse, invece, permettono di misurare immediatamente le prestazioni nelle condizioni di laboratorio utilizzate.
WordPress può ottenere buoni Core Web Vitals?
Sì. WordPress può rispettare le soglie Core Web Vitals, purché tema, plugin, contenuti e infrastruttura siano configurati in modo adeguato.
Le prestazioni dipendono dalle risorse caricate, dalla qualità del codice, dalla gestione della cache e dalle operazioni eseguite dal browser.
L’utilizzo di WordPress non determina di per sé un risultato buono o scarso.
Un sito veloce può avere un CLS elevato?
Sì. La velocità di caricamento e la stabilità visiva sono caratteristiche differenti.
Una pagina può visualizzare rapidamente tutti i contenuti e presentare comunque spostamenti imprevisti causati da immagini, font o componenti dinamici.
Quali sono i Core Web Vitals attualmente utilizzati da Google?
I tre Core Web Vitals sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS).
L’INP ha sostituito il First Input Delay (FID) il 12 marzo 2024.
Come verificare se un sito supera i Core Web Vitals?
È possibile utilizzare PageSpeed Insights per analizzare una singola pagina e Google Search Console per individuare gruppi di URL con problemi.
La valutazione basata sui dati reali richiede che LCP, INP e CLS rispettino le rispettive soglie al 75° percentile.
Fonti e documentazione ufficiale
Per verificare le definizioni delle metriche, i valori di riferimento e le indicazioni relative al posizionamento, si possono consultare le seguenti risorse ufficiali:
