Ottimizzare i Core Web Vitals: Guida SEO 2021

In questa guida troverai i consigli necessari per ottimizzare i CWV (core web vitals) del tuo sito, o per i siti dei tuoi clienti.

I Core Web Vitals (CWV) sono tre metriche progettate per misurare le prestazioni del sito e l’esperienza utente. Il progetto open source Chromium ha annunciato queste metriche all’inizio di maggio 2020 e rapidamente sono state adottate in tutti i prodotti Google.

“Gli esseri umani prediligono esperienze web complete”. Bene, bello! Ma che significa?

Uno studio recente citato da Google sui Core Web Vitals ha rilevato che gli utenti con dispositivi mobili riescono a concentrarsi sullo schermo solo per 4-8 secondi alla volta.

Esatto, hai letto bene!

In genere hai meno di 8 secondi per fornire un contenuto interessante e convincere i tuoi utenti a completare un’attività.

Come puoi misurare le prestazioni dell’esperienza dell’utente di un sito?

• Il sito sta caricando?
• È pronto? Funziona? Posso interagire?
• È visivamente “stabile”?

Fondamentalmente, i Core Web Vitals misurano il tempo impiegato per completare le funzioni di script necessarie per creare il contenuto “above the fold”, cioè quello che viene visualizzato nella prima schermata di qualsiasi pagina di un sito, prima di scrollare in basso, per capirci.

Tutto questo viene anche chiamato “Page Experience” o Esperienza di Pagina.

L’aggiornamento di Google relativo alla Page Experience sarà una catastrofe per i siti web?

Tranquilli, probabilmente no…

Ma se le tue pagine (o quelle dei tuoi clienti) superano il test di Google per i Core Web Vitals, i tuoi utenti avranno il 24% di probabilità in meno di abbandonare il sito. La tua SEO e la conversione del sito in generale ne beneficerà molto!

L’aggiornamento Core Web Vitals

CWV sarà uno degli elementi importanti per il posizionamento su Google (sicuramente non il più importante, ma avrà un certo peso).

Il lancio previsto sarà graduale da metà giugno ad agosto 2021, il Page Experience Ranking (punteggio) sarà composto da:

• Core Web Vitals
  • Largest Contentful Paint (rendering della schermata iniziale)
  • First Input Delay (tempo prima dell’interattività della pagina)
  • Visual Stability (stabilità visuale del layout)
• Mobile-Friendly. (layout del sito ottimizzato per dispositivi mobili)
• Safe Browsing. (certificato SSL e protocollo HTTPS)

La documentazione di Google chiarisce che l’implementazione sarà graduale e che “i siti in genere non dovrebbero aspettarsi grossi cambiamenti in termini di posizionamento”.

Nonostante ciò, ogni buon SEO sa che è meglio ottimizzare tutto l’ottimizzabile!

Cose importanti da sapere sull’aggiornamento:

• L’esperienza della pagina viene valutata per singolo URL.
• L’esperienza della pagina è basata su un browser per smartphone.
• AMP non è più necessario per i caroselli “Top stories”.
• Il superamento del test CWV non è un requisito per apparire nei caroselli “Top Stories”.

Il nuovo rapporto sull’esperienza di pagina in Search Console

Search Console ora include un rapporto “Esperienza di pagina”. Il rapporto include dati retrodatati degli ultimi 90 giorni.

Affinché un URL sia considerato “valido”, deve soddisfare i seguenti criteri:

• L’URL non presenta problemi su dispositivi mobili secondo il rapporto sull’usabilità.
• Il sito non ha problemi di sicurezza.
• L’URL viene servito con protocollo HTTPS.
• Il sito non presenta problemi di Esperienza pubblicitaria o il sito non è stato valutato per Esperienza pubblicitaria.

Il nuovo report offre widget di alto livello che si collegano ai report per ciascuno dei cinque criteri.

Flusso di lavoro per la diagnosi e la risoluzione di errori con Core Web Vitals

Prima di tutto, un’importante avvertenza sui dati “Field” e “Lab” (sul campo e di laboratorio).

I dati sul campo sono dati sulle prestazioni del sito raccolti dai caricamenti di pagine reali che gli utenti stanno sperimentando nel mondo reale. In effetti può essere definito come Monitoraggio Reale dell’utente.

Le valutazioni Core Web Vitals ed i segnali di classificazione dell’esperienza di pagina utilizzeranno i dati sul campo raccolti dal rapporto sull’esperienza utente di Chrome (Crux).

Quali utenti fanno parte del rapporto sull’esperienza utente di Chrome?

I dati Crux sono da utenti aggregati che soddisfano tre criteri in Google Chrome:

• L’utente ha deciso di sincronizzare la cronologia di navigazione.
• L’utente non ha impostato una password di sincronizzazione.
• L’utente ha attivato il reporting delle statistiche sull’utilizzo.

Puoi accedere ai dati Crux utilizzando Google Search Console, PageSpeed Insights (a livello di pagina), il progetto Google BigQuery pubblico o utilizzarli come origine di dati in Google Data Studio.

Perché potresti voler usare qualcos’altro? I dati sul campo di CWV sono un insieme limitato di metriche con capacità di debug e requisiti limitati per la disponibilità dei dati.

Perché la mia pagina non ha dati disponibili da Crux?

Durante il test delle tue pagine, potresti ricevere questo avviso: “Il rapporto sull’esperienza utente di Chrome non dispone di dati reali sulla velocità sufficienti per questa pagina”.

Questo perché i dati di Crux sono anonimizzati. Deve quindi esserci un numero sufficiente di caricamenti di pagine da utenti diversi, per evitare che il singolo utente venga identificato.

I parametri Core Web Vitals vengono identificati al meglio utilizzando i dati sul campo e quindi diagnosticati o sottoposti ad analisi utilizzando i dati di laboratorio.

I dati di laboratorio ti consentono di eseguire il debug delle prestazioni. Si chiamano “di laboratorio” perché questi dati vengono raccolti all’interno di un ambiente simulato.

Puoi ottenere dati di laboratorio da PageSpeed Insights, web.dev/measure, lo strumento Lighthouse di Chrome DevTool e da crawlers basati su Chromium.

Entriamo ora nel dettaglio del flusso di lavoro…

1. Identifica i problemi di Core Web Vitals con i dati Crux per tipo di comportamento in Search Console.

Iniziamo con il rapporto Core Web Vitals di Search Console per identificare i gruppi di pagine che richiedono attenzione. Questo set di dati utilizza i dati Crux e raggruppa insieme URL di diverse pagine in base a tipi diversi di comportamento.

Se risolvi il problema principale per una pagina, è probabile che lo risolva per tutte le pagine che condividono quel problema. In genere, questi problemi sono condivisi da un modello di pagina, un’istanza del CMS o un elemento sulla pagina. Search Console crea un raggruppamento per noi.

Concentrati sui dati mobili, dato che Google sta passando a un indice Mobile-First e CWV è impostato per influenzare le SERP mobili (i risultati di ricerca per dispositivi mobili).

2. Utilizza PageSpeed Insights per unire i dati sul campo con la diagnostica di laboratorio.

Dopo aver identificato le pagine che necessitano di lavoro, utilizza PageSpeed Insights (fornito da Lighthouse o Chrome UX Report) per diagnosticare i problemi di laboratorio e sul campo per ogni pagina.

Ricorda che i test di laboratorio sono test emulati una tantum. Un test non è una fonte di verità o una risposta definitiva. Prova sempre un campione di diversi URL di esempio.

PageSpeed Insights può essere utilizzato solo per testare URL disponibili pubblicamente e indicizzabili.

Se stai lavorando su pagine noindex o che richiedono autenticazione, i dati Crux sono disponibili tramite API o BigQuery. I test di laboratorio dovrebbero utilizzare Lighthouse.

3. Crea un sistema di ticket. Lavora sui Core Web Vitals come un vero professionista.

Come professionisti SEO, dovreste continuamente sviluppare ed utilizzare processi di ottimizzazione dei lavori e di controllo qualità.

I team di sviluppo in genere lavorano in sprint. Ogni sprint include dei tickets.

Avere ticket ben scritti consente al team di sviluppo di lavorare in armonia, velocemente e con concentrazione.

Nei tuoi tickets, includi:

Storia dell’utente/sito
Segui un semplice formato:

Come <tipo di utente / sito / ecc>, voglio <azione> per <obiettivo>.

Ad esempio: come sito performante, voglio includere CSS in linea per il nodo X nel modello di pagina Y per ottenere il rendering dei primi contenuti per questo modello di pagina in meno di 2,5 secondi.

Criteri di validazione
Definisci quando l’obiettivo è stato raggiunto. Cosa significa “Fatto/Risolto”? Per esempio:

Il CSS critico (ovvero: quello relativo al nodo X) è inserito sopra i collegamenti alle risorse JS e CSS nel tag <head> del documento.

Strategia di Test degli URL
Includi gli URL di esempio che hai trovato con Search Console. Fornisci sempre una serie di passaggi da seguire per gli sviluppatori e per il controllo qualità.
Pensa a quale strumento viene utilizzato, quale metrica / indicatore cercare e il comportamento che indica un test superato o un errore.

Inserisci e riferisci collegamenti alla documentazione richiesta per gli sviluppatori
Riferisciti sempre a documentazione originale quando disponibile. Evita blogs o video su youtube.

4. Testa le modifiche in ambienti di staging che utilizzano Lighthouse.

Prima che il codice venga inviato in produzione, viene spesso testato in un ambiente di staging. Utilizza Lighthouse (tramite Chrome DevTools) per misurare i principali dati CWV.

Tieni presente che gli ambienti di staging in genere sono server o istanze del sito con meno risorse e saranno quasi sempre meno performanti rispetto al sito in produzione.

LCP Largest Contentful paint

Cosa misura: l’esperienza di caricamento percepita dall’utente.

Come viene misurata: il momento nella sequenza temporale di caricamento della pagina in cui l’immagine più grande o il blocco di testo principale della pagina è visibile all’interno della finestra del browser.

Da notare: tutte le pagine che utilizzano gli stessi modelli di pagina (layout) in genere condividono la stessa LCP.

Obiettivo dell’ottimizzazione: il 75% delle visite sulle pagine ottimizzate raggiunge l’LCP in meno di 2,5 secondi.

Dati disponibili: Laboratorio e sul campo.

Cosa può essere considerato come LCP?

La metrica LCP misura quando il blocco di testo principale o l’immagine più grande diventano visibili nella finestra del browser.

Gli elementi che possono rappresentare un nodo LCP in una pagina sono:

• Elementi <img>
• Elementi <image> all’interno di un tag <svg>
• Immagini poster per elementi <video>
• Immagini di sfondo caricate tramite la funzione CSS url()
• Paragrafi di testo all’interno di elementi <div>

In futuro potrebbero essere inclusi elementi aggiuntivi come <svg> e <video>

Come diagnosticare l’LCP utilizzando i Chrome DevTools

1. Apri la pagina in Chrome emulando il dispositivo mobile Moto 4G
2. Passa al pannello Prestazioni degli Strumenti di sviluppo (Mac: Comando + Opzione + I – Windows e Linux: Control + Maiusc + I).
3. Passa il mouse sopra l’indicatore LCP nella sezione Tempi.
4. Gli elementi che formano l’LCP sono descritti in dettaglio nel campo Nodo correlato.

Che cosa causa un risultato di LCP scarso?

Ci sono quattro problemi comuni che causano una LCP scadente:

• Tempi di risposta del server troppo lunghi (server lento/poche risorse assegnate)
• Codice JavaScript e CSS che blocca il rendering
• Tempi di caricamento delle risorse troppo lunghi
• Rendering lato client scarso

I problemi che danno origine a risultati LCP scarsi sono sempre descritti, nel migliore dei casi, in maniera molto generale. Sfortunatamente, nessuna delle frasi riportate qui sopra sarà probabilmente sufficiente da poter dare informazioni dettagliate al tuo team di sviluppo.

Nonostante questo, puoi dare una smossa al problema cercando di individuare quale delle quattro tipologie di problema è quella con il maggiore impatto.

Migliorare la LCP sarà un lavoro collaborativo tra gli sviluppatori ed chi si occuperà dei test e del controllo qualità.

Diagnosticare una LCP scarsa: tempo di risposta del server troppo lungo

Dove guardare: Crux Dashboard – Time to First Byte (TTFB)

Se rilevi un TTFB consistentemente scadente dai tuoi dati sul campo, significa che il tempo di risposta iniziale del server è troppo lungo.

Come correggere il tempo di risposta del server

Il tempo di risposta del server (TTFB) è costituito da numerosi fattori che variano a seconda dello stack tecnologico utilizzato dal sito. Non esistono formule magiche. La cosa migliore che puoi fare è aprire un ticket con il tuo team di sviluppo.

Alcuni modi possibili per migliorare il TTFB sono:

• Ottimizza il server
• Indirizza gli utenti a una rete CDN per i contenuti multimediali e per assets di terze parti
• Abilita un sistema di caching per le pagine ed i contenuti non dinamici
• Stabilisci la connessione a domini di terze parti in anticipo

Diagnosticare una LCP scarsa: JavaScript e CSS che bloccano il rendering

Dove cercare: Lighthouse (tramite web.dev/measure, Chrome DevTools, Pagespeed Insights)

Come correggere gli errori CSS che bloccano il rendering

CSS blocca intrinsecamente il rendering e influisce sulle prestazioni del percorso di rendering critico per la pagina (header e primi contenuti). Per impostazione predefinita, il CSS viene considerato come una risorsa che blocca il rendering.

Il browser scarica tutte le risorse CSS, indipendentemente dal comportamento di blocco o non blocco.

Minifica il CSS

Se il tuo sito utilizza un aggregatore di moduli o uno strumento di compilazione del CSS, trova ed installa un plug-in che ridurrà sistematicamente gli script. Se utilizzi WordPress puoi utilizzare un plugin come Autoptimize

Deferisci il CSS non critico

Il rapporto sul codice in DevTools ti aiuterà a identificare gli stili CSS utilizzati nella pagina. Se un modulo CSS non è utilizzato su nessuna pagina, rimuovilo completamente.

Se gli stili sono usati su un’altra pagina, crea un foglio di stile separato da incorporare in quelle pagine che lo usano.

Passa al CSS critico in linea.

Includi il CSS del percorso critico utilizzato per i contenuti above the fold direttamente nel tag <head>.

Utilizza media-query dinamiche.

Le media query sono semplici filtri CSS che, quando applicati agli stili, li caricano in base ai tipi di dispositivo che riproduce il contenuto.

Come correggere gli errori di blocco dovuti al JavaScript

Minimizza e comprimi i file JavaScript

Dovrai farti aiutare dagli sviluppatori per minimizzare e comprimere i files di JS.

La minificazione comporta la rimozione di spazi, commenti e codice non necessari. È meglio farlo in modo sistematico con uno strumento apposito per la compressione JavaScript.

La compressione implica la modifica algoritmica del formato dei dati per avere interazioni più performanti tra il server ed il client.

Deferisci il JavaScript inutilizzato

La suddivisione del codice serve a sminuzzare grossi pezzi di JS per avere pacchetti più piccoli. Puoi quindi caricare prima quelli più importanti per i contenuti above the fold, rimandando tutto il resto dei pacchetti al caricamento del footer (per esempio).

Come correggere il JS di terze parti che blocca il rendering

Deferisci o Elimina il JS

Se lo script non contribuisce al contenuto above the fold, utilizza attributi async o defer.

Se lo script utilizza un <iframe> nell’header, eliminalo e contatta il fornitore per ottenere un metodo di implementazione aggiornato e non dannoso.

Controlla il codice utilizzato

Controlla l’utilizzo di JS di terze parti. Chi è responsabile dell codice? Utilizzare codice di terze parti senza un team di sviluppo e manutenzione dietro è una grossa responsabilità!

Ne vale la pena? Chiediti se il beneficio di avere questo codice è maggiore del problema che produce a livello di prestazioni.

Puoi usare qualcosaltro? Molto spesso per ottenere l’effetto desiderato o una specifica funzionalità esistono diversi tipi di implementazioni. Assicurati di utilizzare sempre codice mantenuto, aggiornato e sicuro.

Diagnosticare una LCP scarsa a causa dei tempi lunghi per il caricamento delle risorse

Dove cercare: Lighthouse (tramite web.dev/measure, Chrome DevTools, Pagespeed InsightsS).

I browser recuperano ed eseguono le risorse non appena le trovano. A volte il percorso per una risorsa è tutt’altro che ideale. Altre volte, le risorse non sono ottimizzate per l’esperienza di pagina.

Ecco come puoi combattere le cause più comuni dei tempi di caricamento lunghi per le risorse:

1. Ottimizza e comprimi le immagini.
   Nessuno ha bisogno di un file PNG da 10 MB. Raramente esiste un caso di utilizzo per un file immagine di grandi dimensioni. Soprattutto per un PNG!
2. Precarica le risorse importanti.
   Se una risorsa fa parte del percorso critico, un semplice attributo rel = “preload” dice al browser di recuperarla il prima possibile.
3. Comprimi file di testo.
   Codifica, comprimi, ripeti.
4. Fornisci risorse diverse in base alla connessione di rete (servizio adattivo).
   È improbabile che un dispositivo mobile su una rete 4G abbia bisogno / desideri / tolleri il tempo di caricamento delle risorse per un monitor ultra 4K. Utilizza la Network Information API che consente alle applicazioni web di accedere alle informazioni sulla rete dell’utente e distribuisci risorse ottimizzate ai diversi utenti del sito.
5. Metti in cache gli asset utilizzando un service worker.
   Sebbene Googlebot non esegua i service worker, il dispositivo di un utente lo farà sicuramente. Collabora con il tuo team di sviluppo per sfruttare la Cache Storage API.

Diagnosticare una LCP scarsa a causa del rendering insufficiente lato client

Dove cercare: per dare un’occhiata, ogni tanto, visualizza il codice sorgente della pagina. Se si tratta solo di un paio di righe senza senso, la pagina viene renderizzata lato client.

Alcuni elementi all’interno di una pagina possono essere renderizzati lato client. Per individuare questi elementi, confronta il codice sorgente della pagina con l’HTML visualizzato. Se utilizzi un crawler, confronta la differenza del conteggio delle parole visualizzate.

I Core Web Vitals sono un  buonmodo per misurare l’efficacia delle nostre strategie di rendering.

Tutte le opzioni di rendering hanno lo stesso output (costruiscono tutte pagine web), ma le metriche CWV misurano la velocità con cui forniamo ciò che conta, quando serve!

Come risolvere problemi derivanti dal rendering lato client

1. Riduci al minimo il JavaScript critico.
   Usa code splitting, tree shaking e funzioni in line nell’head per le funzionalità above the fold. Mantieni gli script in line al di sotto di 1kb.
2. Usa il rendering lato server.
   Facendo in modo che i tuoi server eseguano elementi JS, puoi restituire agli utenti HTML completamente renderizzato. Nota che questo aumenterà il tuo TTFB poiché gli script vengono eseguiti prima che il tuo server risponda.
3. Usa il pre-rendering.
   In fase di compilazione, esegui i tuoi script e rendi l’HTML pronto per le richieste in arrivo. Questa opzione offre un tempo di risposta del server migliore ma non funziona bene per i siti dinamici come ad esempio un e-commerce con prezzi e quantità che variano spesso.

First Input Delay (Ritardo primo input – FID)

Cosa misura: reattività all’input dell’utente.

Come viene misurato: il tempo che intercorre tra il momento in cui un utente interagisce per la prima volta con una pagina e il momento in cui il browser è effettivamente in grado di accettare ed elaborare input dell’utente ed iniziare a elaborare i gestori di eventi in risposta a tale interazione.

Da notare: FID è disponibile solo come dati sul campo.

Obiettivo dell’ottimizzazione: il 75% dei caricamenti delle pagine ha un FID minore o uguale a 100 millisecondi.

Dati disponibili: sul campo.

Usa il tempo di blocco totale (TBT) per i test di laboratorio

Poiché il FID è disponibile solo come dati di laboratorio, dovrai utilizzare il tempo di blocco totale per i test di laboratorio. I due valori hanno lo stesso risultato finale con soglie diverse.

TBT serve a misurare la reattività all’input dell’utente.

TBT viene misurato come tempo totale in cui il thread principale è occupato da attività che richiedono più di 50 ms per essere completate.

Obiettivo: risultato TBT inferiore o uguale a 300 millisecondi.

Dati disponibili: laboratorio.

Cosa causa un FID scarso?

JavaScript pesante. Tutto qua.

Un FID scarso deriva dal JS che occupa il thread principale, il che significa che le interazioni dell’utente devono attendere il caricamento del JS.

Quali elementi sulla pagina sono influenzati dal FID?

Il FID è un modo per misurare l’attività principale del thread. Ciò significa che tutte le attività in corso sul thread principale devono essere completate, prima che gli elementi sulla pagina possano rispondere all’interazione dell’utente.

Ecco alcuni degli elementi di pagina più comuni che, con un FID scarso, possono generare frustrazione per i tuoi utenti:

• Campi di testo
• Caselle di controllo
• Pulsanti di opzione (<input> e <textarea>)
• Menu a discesa (<select>)
• Collegamenti (<a>)

Dove cercare: per confermare cheil FID sia un problema per gli utenti, guarda in Crux Dashboard – First Input Delay (FID). Utilizza Chrome DevTools per identificare le specifiche attività coinvolte.

Come diagnosticare il TBT utilizzando Chrome DevTools

• Apri la pagina che vuoi analizzare  in Chrome
• Passa al pannello Rete degli Strumenti di sviluppo (Mac: Comando + Opzione + I – Windows e Linux: Control + Maiusc + I)
• Seleziona la casella per disabilitare la cache
• Passa al pannello delle prestazioni e seleziona la casella per Core Web Vitals
• Fare clic sul pulsante di ricarica per avviare il tracciamento delle prestazioni
• Cerca i blocchi blu etichettati come attività lente o gli indicatori rossi nell’angolo destro del pannello attività. Questi indicano attività lente che hanno richiesto più di 50 ms
• Trovi il TBT per la pagina in fondo al riepilogo

Come risolvere gli errori FID

Smetti di caricare così tanti script di terze parti.

Il codice di terze parti mette le tue prestazioni in mano ad un team esterno…

Dipenderai dal fatto che i loro script vengano eseguiti in modo corretto e veloce affinché la tua pagina sia considerata performante.

Libera il thread principale suddividendo le attività lente e riducendo il carico di JS

Se hai un enorme pacchetto JS per ogni pagina, probabilmente ci sono molte funzionalità in quel pacchetto che non contribuiscono alla pagina specifica.

Anche se non sta contribuendo, ogni funzione JS deve essere scaricata, analizzata, compilata ed eseguita.

Suddividendo quel grande pacchetto in blocchi più piccoli e caricando solo quelli che contribuiscono alla pagina libererai il thread principale.

Controlla il tuo tag manager

L’implementazione di tag pronti all’uso (listener di eventi) attiva dei tag che peseranno sul thread principale.

I tag manager sono gestori di input di lunga durata che bloccano lo scorrimento. Collabora con i tuoi sviluppatori per rimuovere i rimbalzi ed i ritardi dovuti ai gestori di input.

Ottimizza la tua pagina per la prontezza di interazione.

Consegna ed esegui i pacchetti JS in un ordine che abbia senso.

• È contenuto above the fold? Dagli priorità. Usa rel = preload.
• È contenuto abbastanza importante ma non abbastanza per bloccare il rendering? Aggiungi l’attributo async.
• È contenuto al di sotto della prima schermata? Deferiscilo con l’attributo defer.

Usa un web worker.

I web worker consentono al JavaScript di essere eseguito su un thread in background anziché sul thread principale su cui viene calcolato il tuo punteggio di FID.

Spostamento cumulativo del layout (Cumulative Layout Shift CLS)

Di cosa si tratta: misura la stabilità dell’interfaccia visuale (UI).

Come si misura: il calcolo è basato sul numero di fotogrammi in cui gli elementi si spostano visivamente e la distanza totale dello spostamento in pixel degli elementi.

punteggio di CLS = frazione dell’impatto * frazione della distanza

Come viene misurato: il CLS è l’unico Core Web Vital non misurato con il tempo. Il CLS è una metrica calcolata a sé. I calcoli esatti vengono attivamente ripetuti.

Obiettivo dell’ottimizzazione: il 75% dei caricamenti delle pagine ha una metrica calcolata di CLS inferiore a 0,10.

Dati disponibili: Lab e sul campo.

Diagnosticare un CLS scarso

Dove cercare: per confermare che si tratta di un problema per gli utenti, guarda in Crux Dashboard – Cumulative Layout Shift (CLS). Usa uno strumento come Lighthouse per identificare gli elementi che si mouvono troppo.

Chrome DevTools può fornirti maggiori informazioni sulle coordinate degli elementi coinvolti e quante volte si muovono.

Come diagnosticare il CLS utilizzando Chrome DevTools

1. Apri la pagina in Chrome.
2. Passa al pannello Rete di Strumenti di sviluppo (Mac: Comando + Opzione + I – Windows e Linux: Control + Maiusc + I)
3. Seleziona la casella per disabilitare la cache.
4. Passa al pannello delle prestazioni e seleziona la casella per Web Vitals.
5. Fai clic sul pulsante di ricarica per avviare il tracciamento delle prestazioni.
6. Fai clic sugli indicatori rossi nella sezione Esperienza.
7. Cerca il nome del nodo, l’evidenziazione del nodo sulla pagina e le coordinate per ogni spostamento dell’elemento.

Cosa si può considerare in CLS?

Se un elemento viene visualizzato nella schermatae iniziale, diventarà parte del calcolo della metrica.

Se carichi il footer di pagina prima del contenuto principale e questo appare nella schermata iniziale, il footer di pagina fa parte del tuo (probabilmente atroce) punteggio di CLS.

Quali sono le cause di un CLS scarso?

È il tuo avviso dei cookies? Probabilmente è lui…

In alternativa dai un’occhiata a:

• Immagini senza dimensioni specificate
• Annunci pubblicitari, incorporamenti esterni e iframe senza dimensioni specificate
• Contenuto iniettato dinamicamente
• Caratteri Web che causano FOIT / FOUT
• Catene di risorse critiche
• Azioni in attesa di una risposta di rete prima di aggiornare il DOM

Come correggere gli errori di CLS

Assicurati di includere sempre gli attributi di larghezza e altezza nelle immagini e negli elementi video.

Ad esempio: <img src = “layout-senza-errori.jpg” width = “480” height = “240” />.

Il web design “responsive” ha visto il declino delle dichiarazioni di altezza e larghezza. L’impatto negativo di ciò è che le pagine si spostano una volta che l’immagine compare sullo schermo.

Una buona pratica consiste nell’utilizzare fogli di stile per user-agent con le dimensioni dichiarate sistematicamente in base alle proporzioni delle immagini servite.

Riserva spazio per le aree di annunci pubblicitari (e non comprimerli).

Se hai o lavori su un sito editoriale, non vincerai mai la discussione sull’impatto negativo contro il rendimento degli annunci pubblicitari.

Per ovviare al problema puoi identificare l’annuncio di dimensioni maggiori che potrebbe essere visualizzato in un’area annuncio e dichiarare lo spazio necessario in precedenza. Se l’annuncio non viene popolato, visualizzerai un segnaposto. Questa soluzione è sicuramente migliore di un brusco spostamento di layout.

Evita di inserire nuovi contenuti sopra quelli esistenti.

Un nuovo elemento non dovrebbe mai comparire nella schermata a meno che non sia pronto per essere visualizzato.

Presta molta attenzione quando posizioni gli annunci nella parte superiore della finestra di visualizzazione (viewport).

Come regola generale, evita gli annunci nella parte superiore del viewport.

Precarica i caratteri e le risorse critiche.

Il caricamento lento di un font provoca un flash e una nuova riscrittura della pagina.

Il precaricamento dice al browser che vorresti recuperarlo prima di quanto il browser lo scoprirà, perché sei certo che sia un elemento importante per la pagina corrente.

es: <link rel = “preload” href = “/assets/Roboto-bold.woff2” as = “font” type = “font/woff2” crossorigin>

Evita le catene di risorse per creare contenuti above the fold.

Le catene si verificano quando chiami una risorsa che chiama un’altra risorsa. Se una risorsa critica viene chiamata da uno script, non può essere chiamata fino a quando non viene eseguito lo script…

Evita document.write()

I browser moderni supportano l’analisi speculativa del thread principale.

Ovvero: lavorano in anticipo mentre gli script vengono scaricati ed eseguiti.

Un po’ come leggere le risposte prima di un compito in classe

document.write() entra e cambia le domande. Ora tutto quello che hai letto è diventato inutile!

È probabile che questo non sia opera dei tuoi sviluppatori. Parla con il tuo punto di contatto per quello strumento “magico” di terze parte (es: strumenti di analisi e tracciamento, marketing ecc…).

Il futuro delle metriche Core Web Vitals

Google intende aggiornare i componenti di Page Experience su base annuale. Le future metriche CWV saranno documentate in modo simile.

Immagina un mondo in cui i professionisti SEO hanno saputo con un anno di anticipo che l’aggiornamento Panda stava arrivando!

I principali parametri Core web vitals rappresentano già il 55% del tuo punteggio Lighthouse v7.

Attualmente, Largest Contentful Paint (LCP) e First Input Delay (FID) sono considerati ciascuno al 25%. Lo spostamento cumulativo del layout CLS è un mero 5%, probabilmente possiamo aspettarci di vederli aumentare.

In qualità di professionisti SEO, dovremmo essere in grado di diagnosticare e fornire soluzioni per una migliore esperienza utente.

Questi investimenti e miglioramenti hanno un impatto per tutti gli utenti ed Il Ritorno di Investimento può essere giustificato in ogni mezzo ed ogni canale.

Ricorda che le prestazioni del traffico organico sono un riflesso generale dello stato di salute del sito.

Sappiamo bene che sarà una battaglia, tra marketing, direttori, sviluppatori e soci stakeholders… e che purtroppo sarai tu a portare le brutte notizie! Fatti coraggio e ricorda a tutti i coinvolti che (purtroppo o per fortuna loro) è il tuo dovere ottimizzare la UX ed il rendimento del sito.