Aggiornamento di maggio 2021 di Google: uno sguardo più da vicino a Core Web Vitals

AGGIORNAMENTO: Il mondo del marketing digitale è in continua evoluzione, ma non preoccuparti, siamo al top. Google ha cambiato idea sul prossimo algoritmo.

Leggi le modifiche recenti qui nel nostro aggiornamento, ma sentiti libero di leggere anche questo blog.

Nel maggio 2021, Google introdurrà le metriche Core Web Vitals (CWV) per far parte del proprio algoritmo di ranking della ricerca. Ecco cosa devi sapere e fare prima di allora...

Sappiamo tutti che i siti veloci sono importanti. Creano una migliore esperienza utente, con conseguente aumento dei tassi di conversione e già tengono conto del ranking di ricerca mobile in Google insieme ad altre metriche sull'esperienza della pagina come l'ottimizzazione per i dispositivi mobili.

Ma Google non si ferma qui. Nel maggio 2020, ci hanno parlato di Core Web Vitals e il 10 novembre 2020 hanno annunciato che a maggio 2021 Core Web Vitals sarà incorporato come segnale di ricerca nell'algoritmo di classificazione generale.

Inoltre, hanno in programma di "testare un indicatore visivo che evidenzi le pagine nei risultati di ricerca che hanno un'ottima esperienza di pagina". Quindi non solo abbiamo una maggiore possibilità di ottenere un posizionamento più elevato attraverso l'ottimizzazione CWV, ma abbiamo anche la prospettiva di un aumento delle percentuali di clic dalle pagine dei risultati dei motori di ricerca.

Agire ora per controllare e risolvere eventuali problemi potenziali segnalati con queste nuove metriche CWV offrirà ai nostri siti maggiori possibilità di ottenere un posizionamento Google più elevato quando questa modifica entrerà in vigore nel 2021.

Ma prima, un riassunto...

Riepilogo: cosa sono i Core Web Vital?

I Core Web Vitals sono un insieme di 3 nuove metriche sull'esperienza della pagina che entrano nei punteggi complessivi della velocità del sito. Queste metriche hanno già un ruolo di primo piano nello strumento PageSpeed ​​Insights di Google PSI e nel monitoraggio delle prestazioni di Lighthouse altrove.

Le nuove metriche CWV comprendono quanto segue:

Il più grande contenuto di vernice (LCP)

Questo è il tempo necessario prima che l'elemento above the fold più grande venga visualizzato all'utente. Rappresenta il 25% del meccanismo complessivo del punteggio di velocità ed è quindi di vitale importanza per semplificare la consegna dell'elemento più grande a 2,5 secondi o meno sui dispositivi mobili.

Numerosi fattori contribuiscono a un LCP elevato tra cui reattività del server, script e stili di blocco del rendering, complessità di CSS, caratteri e immagini

Ritardo primo ingresso (FID)

Questo misura l'interattività; quanto è reattiva la pagina all'input dell'utente, ad esempio tramite tocchi o clic. La velocità target alla quale il browser risponde al primo input dovrebbe essere di 100 ms o meno.

Se il browser sta analizzando o eseguendo molti JavaScript durante il caricamento della pagina, questo bloccherà la CPU o bloccherà il "Thread principale", rendendo i dispositivi meno reattivi all'input. Un FID alto è solitamente un indicatore di JavaScript complesso. Potrebbe trattarsi di un singolo script o funzione o di numerosi script.

Le metriche PSI esistenti per il tempo di interattività e il tempo di blocco totale sono correlate al FID e insieme rappresentano un enorme 35% dei punteggi complessivi di velocità.

Cambio layout cumulativo (CLS)

Questa è una misura della stabilità visiva del contenuto above the fold. Sebbene comprenda solo il 5% dei punteggi complessivi di velocità, vale comunque la pena considerarlo nel quadro generale. Un CLS alto può spesso indicare uno o più cambiamenti nel layout visivo durante il caricamento della pagina, ad esempio quando i banner vengono caricati spostando il contenuto della pagina verso il basso.

Ripartizione del punteggio di velocità

Il diagramma seguente mostra una ripartizione del punteggio di velocità complessivo e il ruolo che giocano queste nuove metriche CWV nei punteggi GPSI.

Dati di origine dall'aggiornamento del punteggio di Lighthouse

Sebbene le metriche non CWV formino anche il punteggio complessivo, inclusi First Content Paint (FCP), Time to Interactive (TTI) e Total Blocking Time (TBT), concentrarsi sulle tre metriche CWV avrà un impatto diretto sugli altri. Un LCP veloce non è possibile, ad esempio, senza un FCP veloce e i punteggi FID alti sono direttamente influenzati da TBT e TTI.

Suggerimenti per la più ampia ottimizzazione di Paintful

La metrica LCP è composta da numerosi fattori individuali e direttamente influenzata da un FCP elevato. Se il FCP viene contrassegnato come povero, potresti iniziare da qui. Qualsiasi cosa, dalla connettività di rete, alla reattività del server, al Time To First Byte TTFB e ai file di blocco del rendering, influenzerà il valore FCP. Per un approfondimento su alcuni di questi consigli più generici sulla velocità della pagina, dai un'occhiata al nostro eBook sulla velocità della pagina sull'argomento oltre ai suggerimenti specifici per LCP di seguito.

Se il valore LCP è molto più alto di FCP, allora dobbiamo esaminare come possiamo semplificare meglio la visualizzazione di questo elemento più grande.

Determina l'elemento più grande

La prima cosa che probabilmente vorrai fare è determinare qual è l'elemento più grande. L'elemento più grande si basa sull'area dei pixel che può cambiare in diversi punti di interruzione, quindi una scansione visiva potrebbe non identificare necessariamente l'elemento giusto.

In PSI, nella sezione Diagnostica dovrebbe essere presente un pannello "Elemento di pittura più contenuto". In alternativa, puoi visualizzare l'LCP passando con il mouse sull'indicatore nello strumento di monitoraggio delle prestazioni di Chrome come mostrato di seguito.

Nel sito di Hallam nell'esempio sopra, Performance Monitor mostra l'LCP come intestazione principale "Thrive Online". Idealmente, LCP dovrebbe seguire immediatamente FCP come in questo esempio e se c'è un divario tra i due, dobbiamo cercare di capire perché.

I caratteri sono ottimizzati?

Se l'elemento above the fold più grande è la tipografia, dobbiamo assicurarci che la consegna dei caratteri sia il più snella possibile. Ciò comprende:

1. Usa il font-display CSS: swap; per garantire la visualizzazione immediata del carattere durante il caricamento del file del carattere. Sia Google Fonts che Typekit di Adobe hanno la possibilità di impostare il parametro "display" del carattere.
2. Prova a ospitare localmente file di caratteri .woff e .woff2 sul server invece di effettuare richieste tra domini a caratteri di terze parti. Google Fonts è piuttosto veloce, i font Typekit sono più lenti e alcune fonderie di font di terze parti possono essere meno affidabili.
3. Il precaricamento dei file dei caratteri può essere d'aiuto. I caratteri ospitati localmente saranno spesso inclusi nel foglio di stile principale dei siti Web, ma questo foglio di stile deve essere scaricato e analizzato prima che venga effettuata una richiesta aggiuntiva al carattere all'interno. Il precaricamento dice al browser di iniziare a scaricare il font prima, senza aspettare che il CSS venga analizzato.
4. Usa preconnect e dns-prefetch per le fonderie di font di terze parti. Queste direttive aiuteranno a stabilire connessioni DNS, TLS e TCP tra domini di terze parti prima che venga effettuata la richiesta ai caratteri.
5. Includere solo i file di caratteri per la tipografia necessari per il display pieghevole. Le risorse di carattere per le librerie di icone come Font Awesome sono notoriamente pesanti, ma le richieste a queste (e alla corrispondente libreria di icone CSS) possono essere generalmente rinviate e caricate dopo l'elemento <head>.
6. Non effettuare richieste tra domini per file di caratteri all'interno del foglio di stile del sito principale poiché ciò si basa sulla connettività e sulla ricerca aggiuntiva di un dominio di terze parti.
7. Considera i caratteri sicuri per il web. Questi non richiedono alcuna richiesta per i file di font, anche se possono essere molto limitati in termini di estetica.

Le immagini sono ottimizzate?

Molto spesso, l'elemento above the fold più grande sarà un'immagine così importante da garantire che le immagini siano ottimizzate. Quanto segue è una buona pratica in generale, ma particolarmente importante per l'elemento LCP.

1. Usa il tipo di file immagine corretto. Le immagini JPG dovrebbero essere utilizzate per fotografie, SVG per grafica vettoriale e icone o PNG per immagini più complesse, non fotografiche e se è richiesta la trasparenza.
2. Assicurati che le immagini JPG vengano salvate o emesse con una qualità del 50-60%. A questo livello, non dovrebbe esserci alcuna perdita di qualità percepibile. Inoltre, assicurati che alle immagini siano stati rimossi i metadati.
3. I plug-in oi servizi di compressione come tinypng.com possono ottimizzare automaticamente e in blocco le immagini ed eliminare i metadati non necessari.
4. Le immagini devono essere dimensionate in modo appropriato per l'area in cui vengono visualizzate. Non trasmettere l'immagine desktop di alta qualità su dispositivi mobili.
5. Le immagini devono essere emesse utilizzando il tag <img> standard con l'attributo 'srcset' per le immagini responsive.
6. Le immagini below the fold o fuori schermo devono utilizzare l'attributo loading=”lazy”.
7. Utilizza il formato di file immagine .web di nuova generazione per tassi di compressione ancora migliori. Questo può facilmente risparmiare il 30% e in molti casi molto di più.
8. Prendi in considerazione la possibilità di precaricare l'immagine above the fold più grande per avviare il download più velocemente prima di altri contenuti potenzialmente meno critici.

Riduci i file che bloccano il rendering

Qualsiasi file JavaScript o CSS caricato nell'elemento <head></head> è considerato di blocco del rendering poiché questi file devono essere scaricati prima che la pagina possa iniziare a essere visualizzata. Questo può avere un enorme impatto sia sulla metrica FCP che LCP. I file di blocco del rendering nella testa devono essere utilizzati solo se sono critici per la visualizzazione above the fold iniziale sulla pagina.

La rimozione di eventuali file inutilizzati in <head>, il caricamento di file non critici nel piè di pagina o la combinazione di più file in un numero inferiore di file ridurrà la quantità di risorse che bloccano il rendering.

Non utilizzare JavaScript per visualizzare l'LCP

Prima di CWV, questo non era un grosso problema. È comune che JavaScript venga utilizzato per animare o visualizzare elementi above the fold come testo in dissolvenza o caroselli di eroi, spesso con un impatto minimo o nullo sui punteggi di velocità.

Se la visualizzazione dell'elemento più grande si basa su JavaScript, ciò può spesso causare un lungo ritardo poiché JavaScript deve essere scaricato, analizzato ed eseguito prima che l'elemento venga visualizzato. I file JavaScript vengono solitamente (e giustamente) caricati dopo l'elemento <head> in modo che non stiano "bloccando il rendering", ma questo significa che possono ancora bloccare efficacemente il rendering dell'LCP.

Dai un'occhiata all'esempio qui sotto (logo sfocato e intestazione cambiata) questo proviene da un sito con punteggi alti in PSI. L'LCP (il testo dell'intestazione principale) è di alcuni secondi più lontano dall'FCP, a causa della necessità di JavaScript (rappresentato dalle bande gialle) di scaricare, analizzare ed eseguire prima che il testo possa dissolversi.

Anche la dissolvenza del testo in sé può essere un problema, causando una visualizzazione ritardata dell'elemento più grande.

Tecniche JavaScript come questa possono ridurre immediatamente i punteggi complessivi di velocità del 25% e non devono essere utilizzate per ostacolare o impedire in alcun modo il caricamento dell'elemento più grande.

Esegui script al caricamento della finestra

JavaScript è raramente richiesto (e non dovrebbe essere richiesto) per visualizzare contenuti critici above the fold, tuttavia un problema comune che vediamo è che le funzioni possono essere attivate non appena il DOM è pronto. Nel popolare framework jQuery, ciò avviene tramite l'evento 'ready'. Google Tag Manager può anche attivare funzioni o "tag" pronti.

Prendi in considerazione l'attivazione di tutti i JavaScript non necessari per la visualizzazione critica del contenuto nell'evento di caricamento della finestra, dopo che il contenuto della pagina principale è stato caricato per evitare potenziali interferenze con il rendering del contenuto above the fold e dell'elemento LCP.

Accendi l'LCP

Non importa quanto un'immagine sia ben ottimizzata e snella, ci vorrà quasi sempre più tempo per il download e la visualizzazione rispetto a un elemento tipografico. Sebbene sia del tutto possibile ottenere punteggi LCP veloci per le immagini, a volte una modifica per ridurre l'elemento dell'immagine più grande in modo che sia più piccolo dell'elemento di testo più grande significherà che il testo può essere utilizzato invece per l'LCP.

Questo può fare una grande differenza per i punteggi, se il design lo consente, come mostrato nell'esempio seguente in cui l'LCP è stato cambiato in un elemento di testo.

Suggerimenti per l'ottimizzazione del ritardo del primo input

Come accennato in precedenza, il FID misura la reattività della pagina all'input dell'utente. Combina il Time To Interactive TTI e il Total Blocking Time TBT che può rappresentare fino al 35% dei punteggi complessivi di velocità.

Queste metriche sono principalmente influenzate dall'analisi e dall'esecuzione degli script durante il caricamento della pagina; bloccando il thread principale della CPU e potenzialmente influenzando la reattività del dispositivo, in particolare per i dispositivi smartphone di fascia bassa.

È importante notare che i "Dati di laboratorio" mostrati in PSI non misurano direttamente il FID. Ciò è dovuto alla natura interattiva della misurazione da tocchi o clic da parte dell'utente che è difficile da simulare. Invece, viene raccolto da 'Field Data'; misurazioni raccolte da utenti effettivi in ​​un periodo di 28 giorni in base al Chrome User Experience Report CrUX.

Pertanto, l'ottimizzazione diretta per FID è un po' più difficile, poiché non possiamo cambiare qualcosa e aspettare 28 giorni per raccogliere più dati. Dovremmo quindi utilizzare le metriche TTI e TBT nei Dati di laboratorio per questo, poiché i tempi bassi per queste metriche saranno correlati a un FID basso.

Quindi, come possiamo ottimizzare per queste metriche?

Controlla il tuo JavaScript

JavaScript può essere disponibile in tutte le forme e dimensioni e non è raro che un singolo video incorporato, widget di chat, script ReCaptcha o integrazione HubSpot sia l'unica causa dietro le metriche FID, TTI e TBT elevate.

I pannelli di diagnostica in Page Speed ​​Insights sono un buon punto di partenza. La sezione "Riduci al minimo il lavoro del thread principale" ti dirà quanto tempo di esecuzione è occupato da JavaScript, la sezione "Riduci il tempo di esecuzione di JavaScript" indicherà quali file hanno tempi di analisi ed esecuzione elevati e "Riduci l'impatto di terze parti code' evidenzierà e raggrupperà script di terze parti ad alto impatto.

Lo screenshot qui sotto mostra un sito che soffre di avere diversi script pesanti, con una metrica Time to Interactive di 15 secondi. Molti script provengono da terze parti, inclusi HubSpot e Vimeo.

Per un'analisi e una visualizzazione più approfondite sull'impatto di questi script sul caricamento della pagina, lo strumento Performance Monitor di Chrome può essere un ottimo modo per approfondire quali script e funzioni vengono attivati, l'impatto relativo di questi script e in quale punto della pagina vengono caricati vengono eseguiti lunghi script.

L'esempio seguente proviene dallo stesso sito e mostra JavaScript rappresentato dalle barre gialle, rosa e arancioni, con barre più lunghe che mostrano attività in esecuzione più lunghe. Quando facciamo clic su queste attività più lunghe, possiamo vedere gli script evidenziati correlati agli script di grandi dimensioni evidenziati da PSI sopra.

Una volta che abbiamo un quadro migliore di quali script influiscono sulle prestazioni, ci sono diverse tecniche che possiamo utilizzare per ridurre al minimo il loro impatto, come descritto di seguito.

Carica gli script in modo asincrono

JavaScript per impostazione predefinita verrà eseguito in sequenza. Se sono presenti script che non dipendono dal caricamento di altri, questi script dovrebbero essere caricati con l'attributo 'async' in modo che non blocchino l'analisi e l'esecuzione di altri script.

Carica JavaScript in modo condizionale

Un problema comune che vediamo su molti siti è che gli script pesanti vengono caricati a livello globale o su pagine quando non sono necessari. Se hai bisogno di utilizzare ReCaptcha, ad esempio, per aiutare a fermare lo spam sugli invii di moduli, assicurati di caricare solo gli script sulle pagine che contengono moduli.

Semplifica i pacchetti JavaScript

Le librerie JavaScript come jQuery UI o Bootstrap sono spesso utilizzate per fornire funzionalità e funzioni JavaScript aggiuntive. Se utilizzi un pacchetto, assicurati di includere solo le funzionalità pertinenti all'interno del pacchetto per evitare che JavaScript non venga scaricato e analizzato.

Script di caricamento pigro quando necessario

Anche se JavaScript viene caricato solo sulle pagine su cui è necessario, lo script stesso non deve necessariamente essere analizzato ed eseguito durante il caricamento della pagina o l'evento di caricamento della finestra. Caricare JavaScript solo quando è effettivamente necessario può fare un'enorme differenza per le metriche TTI, TBT e FID. Ecco alcuni esempi:

1. Gli incorporamenti video come YouTube e Vimeo sono in genere ad alto impatto. Considera invece di caricare questi script solo quando fai clic sulla miniatura di un video.
2. Le integrazioni di moduli di terze parti come HubSpot possono essere intense. Se il modulo viene visualizzato in modalità modale o nella parte inferiore di una pagina, valutare la possibilità di caricare o inserire lo script richiesto durante lo scorrimento o l'attivazione modale anziché il caricamento della pagina.
3. I widget della chat dal vivo possono influenzare i punteggi di velocità complessivi fino al 35%. Considera di spostare il widget della chat dal vivo in una pagina di contatto dedicata con supporto CTA globale "chat dal vivo" o di inserire lo script della chat dal vivo solo quando si fa clic su un pulsante "chatta con noi".
4. L'aggiunta dell'attributo 'loading=”lazy” al contenuto basato su iFrame incorporato può essere d'aiuto, ma si tratta di una nuova funzionalità del browser e dovrà essere testata a seconda dell'iFrame incorporato utilizzato.

Valuta gli strumenti di business intelligence

L'analisi del comportamento degli utenti con strumenti come Hotjar o software di test A/B come VWO è molto importante per la business intelligence e, in molti casi, i loro vantaggi supereranno l'impatto sulla velocità del sito.

Detto questo, vale comunque la pena valutare l'importanza di eseguire questi strumenti 24 ore su 24, 7 giorni su 7, a seconda della frequenza con cui vengono analizzati i dati. I test A/B devono essere disattivati ​​se, ad esempio, non sono in esecuzione test attivi e gli strumenti di analisi del comportamento come Hotjar possono essere disattivati ​​dopo che sono stati raccolti ed elaborati dati sufficienti.

Suggerimenti per l'ottimizzazione dello spostamento cumulativo del layout

Cumulative Layout Shift (CLS) può rappresentare solo il 5% dei punteggi complessivi di velocità, ma comunque una parte importante del quadro generale, soprattutto perché un'elevata quantità di elementi mobili durante il caricamento della pagina può essere un'esperienza fastidiosa per l'utente.

Determina l'elemento CLS

A volte può sembrare ovvio quale elemento o elementi causano uno spostamento nel contenuto, ma vale sempre la pena verificarlo tramite il pannello Spostamento layout in PSI come mostrato di seguito.

La metrica CLS dovrebbe essere inferiore a 0,1, ma nell'esempio sopra viene superata di oltre il 400% e costerà un calo del 5% nei punteggi. Se questo è un problema globale, questo è il 5% su ogni pagina.

Gli elementi mutevoli dovrebbero essere identificati e affrontati in ordine di impatto e possono includere elementi above e below the fold. Di seguito abbiamo evidenziato alcune delle cause e risoluzioni più comuni dello spostamento del layout.

Attenzione all'animazione

È abbastanza comune che alcune tecniche di animazione vengano utilizzate per cambiare il modo in cui il contenuto viene presentato all'utente, ad esempio dissolvendo o facendo scorrere immagini, testo o pannelli di contenuto mentre l'utente scorre una pagina. Sebbene questi possano essere esteticamente gradevoli (a seconda di chi chiedi), è importante che queste tecniche non spostino alcun contenuto durante il caricamento della pagina.

Se devi nascondere e poi sfumare il contenuto per l'utente, assicurati che la dimensione del contenitore o l'altezza totale della pagina non cambi mentre il contenuto viene caricato. Il contenuto può essere nascosto (se necessario) utilizzando le regole di visibilità CSS piuttosto che visualizzare: nessuno; che conserverà la quantità di spazio sottostante di cui ha bisogno.

Specifica le dimensioni dell'immagine

Se il tag <img> non ha gli attributi di larghezza e altezza impostati, o CSS non viene utilizzato per impostare le dimensioni o il rapporto dell'immagine, i browser dovranno prima scaricare l'immagine prima di poter determinare l'area di pixel che deve display in. Ciò può causare uno spostamento di qualsiasi contenuto sottoposto a rendering sotto l'immagine, quando l'immagine viene caricata.

Specificare la larghezza e l'altezza dell'immagine o impostare le dimensioni o il rapporto dell'immagine (o del contenitore principale) all'interno dei CSS prima che l'immagine venga scaricata farà in modo che i browser conoscano l'area in cui l'immagine deve essere visualizzata ed evitino potenziali layout cambio.

banner

Pubblicità, barre della legge sui cookie o qualsiasi altra informazione utilizzata per visualizzare informazioni importanti in un banner sono probabilmente una delle cause più comuni di un CLS elevato.

È comune che il contenuto del banner venga caricato da un'origine dati esterna o tramite JavaScript dallo stesso sito, il che significa che la dimensione del contenitore del banner potrebbe non essere calcolabile finché il contenuto non è stato caricato. Quando ciò accade, il contenuto sotto il banner si sposterà verso il basso una volta che il contenuto del banner è stato caricato e mostrato all'utente.

Ci sono una serie di risoluzioni a questo proposito:

1. Imposta un'altezza minima per il banner o il contenitore di banner in CSS in modo che il browser possa rappresentare efficacemente un segnaposto. Anche se questo può essere problematico se la quantità di contenuto è dinamica e sconosciuta.
2. Assolutamente o fissa la posizione del banner nella parte superiore o inferiore dello schermo. Per i banner che possono essere chiusi o ignorati, questa è una buona considerazione poiché gli elementi fissi non influiranno sul posizionamento di altri elementi.
3. Se possibile, esamina il rendering lato server del contenuto del banner, il che significa che il contenuto e le dimensioni del banner possono essere caricati in anticipo prima che raggiungano l'utente.

Sommario

Si spera che alcune delle tecniche evidenziate sopra siano utili per diagnosticare e risolvere i problemi di prestazioni relativi ai nuovi Core Web Vitals di Google. Negli ultimi mesi in Hallam, abbiamo aiutato un certo numero di clienti a migliorare le prestazioni del loro sito Web sia in termini di controlli di velocità che di miglioramenti diretti apportati dal nostro team di sviluppo.

Se hai trovato utile questo articolo, potresti anche voler dare un'occhiata al nostro eBook sulle prestazioni del sito Web che approfondisce alcuni dei consigli più generici sulla velocità della pagina di cui chiunque crei o gestisca un sito Web può trarre vantaggio.