Core Web Vitals 101 e guida allo sviluppo

Cosa sta succedendo e cambiando?

Nel maggio 2021, Google ha avviato l'implementazione di un aggiornamento dell'algoritmo di base che aggiunge un ulteriore fattore ai segnali per il ranking delle pagine, in relazione alla velocità della pagina e all'esperienza dell'utente. Anche l'implementazione dell'aggiornamento di base si è protratta fino a giugno 2021, rendendo questo uno dei più grandi cambiamenti fondamentali della storia. Core Web Vitals si unirà ai segnali di ranking precedenti come un sito protetto da HTTPS, compatibilità con i dispositivi mobili e interstitial non intrusivi come segnali di ricerca nel fattore di ranking complessivo dell'esperienza della pagina.

I tre componenti di Core Web Vitals includono quanto segue:

• Largest Contentful Paint (LCP) : misura la velocità di caricamento percepita e segna il punto nella timeline di caricamento della pagina in cui è probabile che il contenuto principale della pagina sia stato caricato. Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di fare in modo che l'LCP si verifichi entro i primi 2,5 secondi dall'inizio del caricamento della pagina.
• First Input Delay (FID) : misura la reattività e quantifica l'esperienza che gli utenti provano quando provano a interagire per la prima volta con la pagina. Per offrire una buona esperienza utente, i siti dovrebbero sforzarsi di avere un FID inferiore a 100 millisecondi .
• Cumulative Layout Shift (CLS) : misura la stabilità visiva e quantifica la quantità di spostamento di layout imprevisto del contenuto della pagina visibile. Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere un punteggio CLS inferiore a 0,1 .

Dichiarazione di rilascio ufficiale di Google su questo aggiornamento dell'algoritmo: https://developers.google.com/search/blog/2020/11/timing-for-page-experience

Inoltre, Google ha rilasciato ulteriori informazioni sulla modifica di CLS mentre continuava a monitorare le prestazioni durante l'implementazione. Di conseguenza, molti siti hanno ricevuto un punteggio più favorevole a causa delle recenti modifiche ed hanno evitato molto lavoro di sviluppo per adattare il layout del sito. Come sempre, queste modifiche sono soggette a modifiche, quindi consigliamo di monitorare i CWV come parte di una lista di controllo settimanale o mensile.

Cosa sappiamo dell'aggiornamento della classifica?

Come con la maggior parte degli aggiornamenti dell'algoritmo di Google, ci sono molte cose sconosciute in termini di come influenzerà l'attuale panorama della ricerca. Sappiamo che questo sarà un fattore nel ranking delle pagine. Tuttavia, non sappiamo quale percentuale di un fattore o quale impatto avrà all'interno dell'algoritmo. Un altro fattore sconosciuto sarà se i concorrenti diretti si adatteranno o agiranno per aggiornare i loro siti per aderire ai nuovi fattori. In base al comportamento della concorrenza, questo potrebbe a sua volta avere un impatto positivo o negativo sulle classifiche del tuo sito, rispetto a quelle pari. Quello che sappiamo è che Google continuerà a dare la priorità al posizionamento dei contenuti che considera preziosi o rilevanti per gli utenti rispetto a siti Web più veloci con contenuti deboli.

Infatti, poiché Google offre maggiori informazioni sull'aggiornamento, ha confermato che i contenuti pertinenti rimangono uno degli elementi più importanti nelle classifiche di ricerca.

"I nostri sistemi continueranno a dare la priorità alle pagine con le migliori informazioni in generale, anche se alcuni aspetti dell'esperienza della pagina sono scadenti. Una buona esperienza sulla pagina non prevale sulla disponibilità di contenuti interessanti e pertinenti."

Come prepararsi per l'aggiornamento del ranking dell'esperienza della pagina di Google?

A causa dei fattori sconosciuti relativi a questo aggiornamento e alla finestra di preavviso di 6 mesi di Google, la modifica sembra segnalare che questo diventerà un fattore di ranking. Pertanto, si consiglia vivamente che sia il team SEO che quello di sviluppo esaminino le prestazioni attuali di Core Web Vitals del tuo sito e agiscano rapidamente nella revisione e nell'aggiornamento dei problemi relativi all'aggiornamento del segnale di classifica. È importante assicurarsi di essere proattivi piuttosto che reattivi, poiché qualsiasi calo di classifica può richiedere del tempo per recuperare. Sappiamo tutti che la SEO è un gioco lungo!

Come identificare i problemi del sito, i passaggi successivi in ​​base ai problemi e suggerimenti aggiuntivi?

I Core Web Vitals sono delineati nell'account Google Search Console del tuo sito in "Miglioramenti". Inoltre, c'è un aspetto generale all'interno della sezione "Panoramica" dell'account, che avrà un aspetto simile all'esempio riportato di seguito (probabilmente si verificheranno alcune variazioni poiché il tuo account dipende dai potenziali problemi specifici del tuo sito). C'è anche una sezione delineata sia per desktop che per dispositivi mobili. In questo esempio, esaminiamo i problemi relativi ai dispositivi mobili.

Poiché a partire da settembre 2020 tutti i siti saranno indicizzati per dispositivi mobili , consigliamo di dedicare prima il tempo di sviluppo ai problemi relativi ai dispositivi mobili. Detto questo, se il tuo sito è reattivo, è probabile che gli aggiornamenti che apporti su dispositivi mobili avranno un impatto positivo anche sul desktop. Inoltre, a seconda delle dimensioni del sito, potrebbe esserci un serraglio di problemi "scadenti" e "necessari miglioramenti". Ti consigliamo vivamente di concentrarti sugli URL "scadenti", poiché gli elementi "necessitano di miglioramenti" potrebbero non valere lo sforzo rispetto all'impatto, o la regola 80/20, di cui parleremo più avanti!

Quando si esaminano gli URL delineati in Google Search Console che mostrano prestazioni non ottimali, è importante tenere a mente ciò che John Mueller di Google ha rivelato su come Google potrebbe in alcuni casi calcolare il punteggio di core web vitals come media di più pagine:

Questa è la domanda:

"Quando questo diventa un segnale di ranking... sarà a livello di pagina o di dominio?"

Müller ha risposto:

“…Quello che succede con i dati sul campo è che non abbiamo punti dati per ogni pagina.

Quindi, per la maggior parte, abbiamo bisogno di avere una sorta di raggruppamento di singole pagine.

E a seconda della quantità di dati che abbiamo, può trattarsi di un raggruppamento dell'intero sito Web (tipo di dominio).

... Penso che nel rapporto sull'esperienza utente di Chrome utilizzino l'origine che sarebbe il sottodominio e il protocollo lì.

Quindi sarebbe una specie di tipo generale di raggruppamento.

E se disponiamo di più dati per le singole parti di un sito Web, proveremo a utilizzarli.

E credo che sia qualcosa che vedi anche nella console di ricerca dove mostreremo come un URL e diremo... ci sono così tante altre pagine associate a quello. E questo è il tipo di raggruppamento che useremmo lì.

Forse ti starai chiedendo, perché ne parliamo all'inizio della conversazione su Core Web Vitals? Mueller spiega che il rapporto di Google Search Console che delinea i problemi relativi agli URL tenta di classificare e segnalare le pagine con gli stessi problemi in un raggruppamento. Sfortunatamente, in pratica, questi raggruppamenti di URL sono stati poco utili per alcuni siti Web della nostra esperienza.

Occasionalmente, esamineremo gli URL indicati come aventi prestazioni "scarse" nel rapporto di Google Search Console, solo per scoprire che le stesse pagine sembrano avere un buono stato di salute quando vengono testate con Lighthouse e Page Speed ​​Insights.

In sintesi, quando esaminiamo i problemi relativi agli URL delineati nel rapporto di Google Search Console, consigliamo di "prenderla con le pinze". La nostra ipotesi migliore è che Google intenda classificare il punteggio "web vitals" per le pagine sulla base di una cronologia di 28 giorni di dati di navigazione del mondo reale effettivi ("dati sul campo" nel linguaggio di Google). Tuttavia, è probabile che i dati del mondo reale vengano aggregati dall'intero dominio (o "origine" nel linguaggio di Google) se la pagina non è molto trafficata. Mentre Search Console sarà utile per identificare il fatto che i tuoi web vitals necessitano di cure amorevoli, non fare affidamento su di essa per il tuo controllo. Inoltre, fai attenzione a rivedere i dati di laboratorio (risultati individuali delle pagine testate in tempo reale) rispetto ai dati sul campo (che possono essere per più pagine e sono sempre su una finestra temporale di 28 giorni) durante l'esecuzione e la verifica o la convalida delle correzioni.

Una volta che sai di avere un problema, se non riesci a determinare le pagine di origine, inizia con pagine di esempio di test di laboratorio per ciascuno dei tuoi modelli principali. Ad esempio, la home page, una pagina di prodotto, una pagina di categoria, un articolo di blog, ecc. Spesso, i problemi strutturali possono essere trovati in ogni istanza di un particolare tipo di pagina e risolti una volta da uno sviluppatore web attraverso un aggiornamento al modello sottostante codice. Se questo non risolve il problema, considera un'analisi simile di un sottoinsieme di singole pagine a partire da quelle più visitate. Uno strumento che abbiamo trovato utile in questo processo è l' auditing di Core Web Vitals tramite Screaming Frog .

Guida al miglioramento dello spostamento cumulativo del layout (CLS).

Cumulative Layout Shift (CLS) misura la somma totale di tutti i singoli punteggi di spostamento del layout per ogni spostamento di layout imprevisto che si verifica durante l'intera durata della pagina. Uno spostamento del layout si verifica ogni volta che un elemento visibile cambia la sua posizione da un fotogramma renderizzato a quello successivo.

Google consiglia le seguenti indicazioni su come migliorare CLS per la maggior parte dei siti Web attenendosi ad alcuni principi guida:

• Includi sempre gli attributi di dimensione nelle immagini e negli elementi video o altrimenti riserva lo spazio richiesto con qualcosa come i riquadri CSS per le proporzioni . Questo approccio garantisce che il browser possa allocare la quantità corretta di spazio nel documento durante il caricamento dell'immagine. Si noti che è anche possibile utilizzare il criterio delle funzionalità multimediali non dimensionate per forzare questo comportamento nei browser che supportano i criteri delle funzionalità.
• Non inserire mai contenuto sopra il contenuto esistente, tranne in risposta a un'interazione dell'utente. Ciò garantisce che siano previsti eventuali cambiamenti di layout che si verificano.
• Preferisci le animazioni di trasformazione alle animazioni di proprietà che attivano modifiche al layout. Animare le transizioni in modo da fornire contesto e continuità da stato a stato.

Google consiglia di utilizzare la seguente procedura per analizzare, testare e distribuire gli aggiornamenti in tutto il sito:

• Una volta identificate le pagine che necessitano di intervento (descritto sopra), utilizza PageSpeed ​​Insights per diagnosticare problemi di laboratorio e sul campo in una pagina.
• Pronto a ottimizzare il tuo sito localmente in laboratorio? Utilizza Lighthouse e Chrome DevTools per misurare i Core Web Vitals e ottenere indicazioni utili su cosa correggere esattamente. L' estensione Web Vitals per Chrome può offrirti una visualizzazione in tempo reale delle metriche sul desktop.
• Cerchi una guida? web.dev/measure può misurare la tua pagina e mostrarti una serie di guide e codelab in ordine di priorità per l'ottimizzazione, utilizzando i dati PSI.
• Infine, usa Lighthouse CI sulle richieste pull per assicurarti che non ci siano regressioni in Core Web Vitals prima di distribuire una modifica alla produzione.

Per un approfondimento su come migliorare CLS, consulta Optimize CLS .

Guida al miglioramento della più grande vernice contenta (LCP).

La metrica Largest Contentful Paint (LCP) riporta il tempo di rendering dell'immagine o del blocco di testo più grande visibile all'interno del viewport.

Come attualmente specificato nell'API Largest Contentful Paint , i tipi di elementi considerati per Largest Contentful Paint sono:

• <img> elementi
• Elementi <image> all'interno di un elemento <svg>
• <video> elementi (viene utilizzata l'immagine poster)
• Un elemento con un'immagine di sfondo caricata tramite la funzione url() (al contrario di un gradiente CSS )
• Elementi a livello di blocco contenenti nodi di testo o altri elementi figlio di testo a livello di riga

Google consiglia le seguenti linee guida su come migliorare LCP, che è influenzato principalmente da quattro fattori:

• Tempi di risposta del server lenti
• JavaScript e CSS che bloccano il rendering
• Tempi di caricamento delle risorse
• Rendering lato client

Per un approfondimento su come migliorare LCP, consulta Ottimizza LCP . Per ulteriori indicazioni sulle tecniche di performance individuali che possono anche migliorare LCP, vedere:

• Applica il caricamento istantaneo con il modello PRPL
• Ottimizzazione del percorso di rendering critico
• Ottimizza il tuo CSS
• Ottimizza le tue immagini
• Ottimizza i caratteri web

Ottimizza il tuo JavaScript (per i siti renderizzati dal client)

I risultati vitali del Web principale dello sviluppo fino ad oggi

Il nostro team di sviluppo ha visto che gran parte dell'aggiornamento della classifica Core Web Vitals richiederà test approfonditi da parte dello sviluppo per garantire che gli aggiornamenti realizzati soddisfino gli standard stabiliti da Google.

In numerosi casi per i siti più piccoli, molti di questi elementi saranno al di fuori del controllo degli sviluppatori web. Ad esempio, la velocità del server è ampiamente controllata dal provider di hosting e per l'hosting condiviso (come WP Engine o Shopify), gli sviluppatori non avranno il controllo. Allo stesso modo, i temi del sito pronti all'uso avranno spesso Javascript e CSS che bloccano il rendering "integrati". In questi casi, potrebbe non essere pratico affrontare molti dei problemi segnalati. Per questi motivi, è necessaria un'analisi critica per determinare l'intersezione di (1) quali problemi hanno il maggiore impatto e (2) quali problemi sono causati dal codice che il team di sviluppo può e deve modificare.

Dopo aver avviato il processo di revisione dei problemi di Core Web Vitals in diversi dei nostri clienti, abbiamo scoperto che gran parte degli strumenti correlati forniti da Google rimane immatura, nella misura in cui è in grado di identificare i problemi (come i cambiamenti di caricamento dei contenuti), ma non è sempre utile per individuare la causa specifica. Anche se ci aspettiamo che questo maturi nelle prossime iterazioni di questi strumenti (in particolare, in Chrome Dev Tools), abbiamo scoperto che potrebbero essere necessari processi diagnostici alternativi per identificare determinati problemi.

Abbiamo anche scoperto che lavorare per migliorare queste metriche è di natura simile al miglioramento delle prestazioni della velocità della pagina nel suo complesso. In ogni caso, sconsigliamo la ricerca del “punteggio perfetto”. Si applica invece la regola 80/20. Se affronti il ​​​​frutto basso, probabilmente vedrai un miglioramento significativo nelle tue metriche. Successivamente, il miglioramento diventa più dispendioso in termini di tempo, più costoso e meno incisivo.

Una guida di base come il suggerimento di Google di includere markup per la conservazione dello spazio o CSS su tutti gli elementi immagine, video e contenitore è generalmente un buon consiglio semplice da implementare. Altri problemi sono più difficili da rintracciare e, a meno che non abbiano un impatto eccessivo sulle tue metriche (come riportato da alcuni degli strumenti suggeriti), potrebbe essere meglio metterli da parte.

Anche l'architettura del sito svolgerà un ruolo significativo nella relativa facilità con cui questi elementi possono essere affrontati. Piattaforme di siti popolari come Shopify e WordPress, insieme a creatori di pagine grafiche come WP Bakery e Shogun, gestiscono una parte del processo di generazione dell'HTML "dietro le quinte". I problemi oscurati dai componenti del generatore di pagine (ad es. alcuni caricamenti lenti di immagini) potrebbero non essere facilmente risolvibili senza modifiche fondamentali al sito o al supporto della piattaforma, del tema o del fornitore di plug-in/app.

Il concetto di cui sopra si estende a terze parti che utilizzano javascript per caricare pigramente i widget nella tua pagina (ad esempio, moduli di iscrizione incorporati da piattaforme di posta elettronica come Klaviyo). In alcuni casi, posizionare un elemento contenitore di dimensioni appropriate ed esplicite attorno al codice di incorporamento del componente offensivo è una soluzione praticabile. In altri casi, il fornitore stesso potrebbe dover apportare una modifica.

Ti consigliamo di avviare qualsiasi processo di correzione con problemi di impatto che possono essere risolti modificando i modelli di sito principali facilmente accessibili (ad esempio, pagine di prodotto, pagine di raccolta di prodotti, ecc.). Ciò consentirà spesso una modifica del codice per migliorare i risultati su decine o centinaia di pagine del sito. Successivamente, indirizza la home page, poiché è quasi sempre la pagina più visitata del sito. Infine, assegna la priorità ad altre singole pagine che richiedono una correzione in base alla gravità del problema e alla visibilità della pagina.

Come nel caso dei miglioramenti della velocità della pagina, la gestione di Core Web Vitals è importante, ma è solo una variabile tra le tante nell'algoritmo di ranking di Google, e anche la SEO deve essere bilanciata rispetto ad altre priorità del sito e dell'azienda che competono per tempo e budget.