Aggiornamento Google CORE WEB VITALS Maggio 2021 e consigli per velocizzare Magento 2

A maggio 2021, Google introdurrà le metriche Core Web Vitals (CWV) per far parte del loro algoritmo di ranking di ricerca. Ci sono quindi alcune operazioni che devi conoscere e che devi effettuare prima di questa data.

Sappiamo tutti avere un sito veloce è fondamentale, per la buona riuscita di un E-Commerce. Un sito con alte prestazioni infatti, crea una migliore esperienza utente, con conseguente aumento dei tassi di conversione. Questo fatto poi è legato anche al posizionamento nella 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 ha parlato di Core Web Vitals e il 10 novembre 2020 ha 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 sulla pagina”. Quindi non solo abbiamo una maggiore possibilità di classifiche più alte 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 darà ai nostri siti una migliore possibilità di un posizionamento più alto di Google quando questa modifica entrerà in vigore nel 2021.

Cos’è il Core Web Vitals?

I principali parametri vitali web sono un insieme di 3 nuove metriche sull’esperienza della pagina che vanno nei punteggi complessivi della velocità del sito. Queste metriche hanno già un ruolo di primo piano nello strumento PSI di Google PageSpeed Insights e nel monitoraggio delle prestazioni di Lighthouse altrove.

Le nuove metriche CWV comprendono quanto segue:

caricamento (LCP)
interattività (FID)
stabilità visiva (CLS)

Le metriche del Core Web Vitals per Google, si basano su questi criteri:

Quanto velocemente appare il contenuto sullo schermo? (LCP)
Quanto velocemente reagisce la pagina all’interazione dell’utente? (FID)
Il contenuto si sposta sullo schermo durante il caricamento del sito? (CLS)

Largest Contenful Paint (LCP)

Questo è il tempo necessario affinche il contenuto più pesante del sito appaia sullo schermo. In sostanza, quando entriamo in un sito E-Commerce e clicchiamo su un articolo, quella che appare è la pagina di prodotto. All’interno di questa troviamo elementi specifici, come logo, testo e immagini. Generalmente sono le immagini gli elementi più pesanti. L’ LCP quindi indicherebbe il tempo necessario per il caricamento dell’immagine.

Rappresenta il 25% del meccanismo di punteggio della velocità complessivo e quindi di vitale importanza per semplificare la consegna dell’articolo più grande a 2,5 secondi o meno sui dispositivi mobili.

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

Come si ottimizza l’ LCP

Innanzitutto dovrai prima controllare l’effettiva velocità del tuo sito e le eventuali criticità. Per farlo ci sono molti tool, tra cui lo Speed Test del nostro partner hosting Hostgento.

Effettua subito il test >>

Dopo questa operazione, puoi cercare di ottimizzare l’ LCP seguendo questi semplici consigli:

Ottimizza le immagini. Precarica, comprimi e riduci il peso di tutti gli elementi visivi che sono presenti nel tuo sito. Più basso è il numero di MB, minore sarà il tempo necessario per il caricamento.
Ottimizza il server. Memorizza nella cache tutti i file statici o utilizza soluzioni CDN pronte per l’uso. Il vantaggio della CDN è che fornisce contenuti dal server più vicino all’utente. Quindi le immagini e le descrizioni dei prodotti vengono caricate più velocemente.
Ottimizza JavaScript e CSS. Rivedi e taglia qualsiasi codice non necessario dai file CSS o JS. È meglio dedicare un file CSS / JS separato per ogni blocco invece di scrivere tutta la logica e gli stili JS in un file ingombrante.
Ottimizza il rendering lato client. Non utilizzare molte operazioni di nidificazione dei componenti nella struttura ad albero DOM. Prova a utilizzare meno funzioni setTimeout per eseguire il rendering e aggiungere elementi al DOM nel caso di eventi “document.ready” e “window.onload”.

First Input Delay (FID)

Questa metrica riflette la reattività del tuo sito: in sostanza, misura il tempo necessario per rispondere a qualsiasi interazione dell’utente. La velocità target alla quale il browser risponde al primo input dovrebbe essere 100 ms o meno.

Se il browser sta analizzando o eseguendo molto JavaScript durante il caricamento della pagina, questo bloccherà la CPU o bloccherà il “thread principale”, rendendo i dispositivi meno reattivi all’input. Un FID elevato di solito è un indicatore di JavaScript complesso. Potrebbe trattarsi di un singolo script o funzione o numerosi script.

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

Cumulative Layout Shift (CLS)

Il CLS infatti, misura tutti i cambiamenti di layout del tuo sito durante il caricamento. Sebbene rappresenti solo il 5% dei punteggi di velocità complessivi, 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 vengono caricati banner 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 importante che queste nuove metriche CWV giocano nei punteggi GPSI.

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

Consigli per migliorare la Largest Contentful Paint

La metrica LCP è composta da numerosi fattori individuali e influenzata direttamente da un FCP elevato. Se il FCP viene contrassegnato come scadente, potresti iniziare da qui. Qualsiasi cosa, dalla connettività di rete, alla reattività del server, al TTFB Time To First Byte e ai file che bloccano il rendering, influenzerà il valore FCP.

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

Determina l’elemento più grande

La prima cosa che probabilmente vorresti 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, dovrebbe esserci un pannello “Il più grande elemento di pittura con contenuti” nella sezione Diagnostica. In alternativa, puoi visualizzare l’LCP passando con il mouse sopra l’indicatore nello strumento di monitoraggio delle prestazioni di Chrome .

I caratteri sono ottimizzati?

Se l’elemento più grande è legato alla tipografia, dobbiamo assicurarci che la questione legata ai caratteri sia il più snella possibile. Questo comprende:

Usa il font-display CSS: swap; per garantire la visualizzazione immediata dei caratteri durante il caricamento del file dei caratteri. Sia Google Fonts che Typekit di Adobe hanno la possibilità di impostare il parametro “display” del carattere.
Prova a ospitare localmente i file di font .woff e .woff2 sul server invece di effettuare richieste interdominio a font 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.
Il precaricamento dei file dei caratteri può aiutare. I caratteri ospitati localmente saranno spesso inclusi nel foglio di stile principale del sito Web, ma questo foglio di stile deve essere scaricato e analizzato prima che venga effettuata una richiesta aggiuntiva al carattere all’interno. Il precaricamento indica al browser di iniziare a scaricare il carattere prima, senza attendere che il CSS venga analizzato.
Usa preconnect e dns-prefetch per fonderie di font di terze parti. Queste direttive aiuteranno a stabilire connessioni DNS, TLS e TCP tra domini di terze parti prima che la richiesta venga effettuata ai caratteri.
Includi solo file di font per la tipografia richiesti per sopra il display pieghevole. Le risorse di font per le librerie di icone come Font Awesome sono notoriamente pesanti ma le richieste a queste (e alla corrispondente libreria di icone CSS) possono solitamente essere differite e caricate dopo l’elemento <head>.
Non effettuare richieste interdominio ai file di caratteri all’interno del foglio di stile del sito principale poiché si basa sulla connettività e sulla ricerca aggiuntiva di un dominio di terze parti.
Considera i caratteri sicuri per il Web. Questi non richiedono alcuna richiesta di file di font, sebbene possano essere molto limitati in termini di estetica.

Le immagini sono ottimizzate?

Molto spesso, l’elemento più grande sarà un’immagine e quindi diventa fondamentale garantire che le immagini siano ottimizzate. Quanto segue è una buona pratica in generale, ma particolarmente importante per l’elemento LCP.

Utilizza il tipo di file immagine corretto. Le immagini JPG devono essere utilizzate per fotografie, SVG per grafica vettoriale e icone o PNG per immagini più complesse e non fotografiche e se è richiesta la trasparenza.
Assicurati che le immagini JPG siano salvate o che siano di qualità intorno al 50-60%. A questo livello, non dovrebbe esserci alcuna perdita di qualità percepibile. Inoltre, assicurati che alle immagini siano stati rimossi i metadati.
Plugin di compressione o servizi analoghi possono ottimizzare automaticamente e in blocco le immagini ed eliminare i metadati non necessari.
Le immagini devono essere di dimensioni adeguate per l’area in cui vengono visualizzate. Non riprodurre l’immagine desktop di alta qualità su dispositivi mobili.
Le immagini devono essere prodotte utilizzando il tag <img> standard con l’attributo “srcset” per immagini reattive.
Sotto la piega o le immagini fuori schermo devono utilizzare l’attributo loading = “lazy”.
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ù.
Considera 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 che blocca il rendering poiché questi file devono essere scaricati prima che la pagina possa iniziare a essere visualizzata. Ciò può avere un enorme impatto sia sulla metrica FCP che su quella LCP. I file di blocco del rendering nella testina devono essere utilizzati solo se sono fondamentali per la visualizzazione iniziale above the fold nella pagina.

La rimozione di 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 del CWV, questo non era un grosso problema. È comune che JavaScript venga utilizzato per animare o visualizzare elementi, ad esempio con testo in dissolvenza o caroselli, spesso con un impatto minimo o nullo sui punteggi di velocità.

Se la visualizzazione dell’elemento più grande si basa su JavaScript, spesso ciò può 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> quindi non sono “blocco del rendering”, ma questo significa che possono ancora bloccare efficacemente il rendering dell’LCP.

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

Attivare l’LCP

Non importa quanto sia ottimizzata e snella un’immagine, quasi sempre ci vorrà più tempo per scaricarla e visualizzarla rispetto a un elemento tipografico. Sebbene sia del tutto possibile ottenere punteggi LCP rapidi per le immagini, a volte un aggiustamento per ridurre l’elemento più grande dell’immagine in modo che sia più piccolo dell’elemento di testo più grande significa 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 convertito in un elemento di testo.

Consigli per migliorare il First Input Delay

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 possono rappresentare fino al 35% dei punteggi di velocità complessivi.

Queste metriche sono principalmente influenzate dall’analisi e dall’esecuzione degli script durante il caricamento della pagina; bloccando il thread principale della CPU e influendo potenzialmente sulla 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. Viene invece raccolto da “Field Data”; misurazioni raccolte dagli utenti effettivi in un periodo di 28 giorni sulla base del rapporto sull’esperienza utente di Chrome CrUX.

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

Vediamo comunque come ottimizzare il FID.

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 diagnostici 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.

Carica script in modo asincrono

JavaScript per impostazione predefinita verrà eseguito in sequenza. Se ci sono 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 in modo condizionale JavaScript

Un problema comune che riscontriamo su molti siti è che gli script pesanti vengono caricati globalmente o sulle pagine quando non sono necessari. Se è necessario utilizzare ReCaptcha, ad esempio, per bloccare lo spam sugli invii di moduli, assicurarsi di caricare solo gli script sulle pagine che contengono moduli.

Semplifica i pacchetti JavaScript

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

Script di caricamento lento 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 durante l’evento di caricamento della finestra. Il caricamento di JavaScript solo quando è effettivamente necessario può fare un’enorme differenza per le metriche TTI, TBT e FID. Ecco alcuni esempi:

I video incorporati come YouTube e Vimeo sono in genere ad alto impatto. Considera l’idea di caricare questi script solo quando fai clic sulla miniatura di un video.
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.
I widget della chat dal vivo possono influire sui punteggi di velocità complessivi fino al 35%. Considera l’idea di spostare il widget della chat dal vivo in una pagina di contatto dedicata con il supporto dell’invito all’azione di “chat dal vivo” globale o di inserire lo script della chat dal vivo solo quando si fa clic sul pulsante “chatta con noi”.
L’aggiunta dell’attributo “loading=”lazy” sui contenuti incorporati basati su iFrame può aiutare, ma si tratta di una nuova funzionalità del browser e sarà necessario testare a seconda dell’incorporamento iFrame 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 i dati vengono analizzati. Il test A / B deve essere disattivato 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.

Consigli per migliorare il Cumulative Layout Shift

Determina l’elemento CLS

A volte può sembrare ovvio quale elemento o quali 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à una riduzione dei punteggi del 5%. Se si tratta di un problema globale, si tratta del 5% su ogni pagina.

Gli elementi in movimento 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 delle 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 verso il basso. 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 all’utente, assicurati che la dimensione del contenitore o l’altezza totale della pagina non cambi quando il contenuto viene caricato. Il contenuto può essere nascosto (se necessario) utilizzando le regole di visibilità CSS anziché visualizzare: nessuno; che preserverà 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 se non si utilizzano CSS per impostare le dimensioni o il rapporto dell’immagine, i browser dovranno scaricare l’immagine prima di poter determinare l’area pixel di cui ha bisogno display in. Ciò può causare uno spostamento di qualsiasi contenuto renderizzato sotto l’immagine, mentre 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 del CSS prima che l’immagine venga scaricata assicurerà che i browser conoscano l’area in cui l’immagine deve essere visualizzata ed eviterà il potenziale layout cambio.

Banner

Pubblicità, pop up per la 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 potrebbe non essere possibile calcolare la dimensione del contenitore del banner fino a quando 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:

Imposta un’altezza minima per il banner o il contenitore del banner in CSS in modo che il browser possa visualizzare in modo efficace un segnaposto. Anche se questo può essere problematico se la quantità di contenuto è dinamica e sconosciuta.
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 in quanto gli elementi fissi non influenzeranno il posizionamento di altri elementi.
Se possibile, osserva 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.

Fonte Hallam – Blog