Home Articoli tecnici Come ottimizzare i principali parametri vitali Web per i siti Web di e-commerce
Applications

Come ottimizzare i principali parametri vitali Web per i siti Web di e-commerce

About The Author

Outline

Il prossimo aggiornamento dell’esperienza della pagina di Google introduce i segnali derivati da Core Web Vitals (CWV) nell’algoritmo di classificazione ufficiale. I principali parametri vitali Web sono un insieme di metriche che misurano la velocità di caricamento delle pagine, diventano interattive e si stabilizzano visivamente per gli utenti reali che interagiscono con loro. I siti Web che non superano il test Core Web Vitals si posizioneranno al di sotto di quelli attualmente disponibili all’inizio del 2021.

CWV è costituito da metriche a 3 velocità che hanno un impatto significativo sull’esperienza percepita dall’utente. Questi includono la vernice Contentful Paint (LCP) più grande per misurare i tempi di carico, il primo ritardo di input (FID) per misurare l’interattività e la reattività e la variazione del layout cumulativo (CLS) per misurare la stabilità visiva. Mentre la velocità del sito web è stata in prima linea per molte aziende di e-commerce, sta per diventare uno dei fattori più importanti nel panorama online. Ecco le metriche su cui dovete concentrarvi e come migliorare la velocità per ciascuna di esse.

Quali sono i principali parametri vitali del Web

Fare una buona prima impressione online è fondamentale. Gli acquirenti vogliono vedere i prodotti immediatamente, navigare rapidamente e acquistare facilmente, senza interruzioni. Se le loro aspettative non sono soddisfatte, rimbalzeranno e non torneranno mai. Core Web Vitals aiuta a risolvere questo problema misurando le pagine di esperienza fornite agli acquirenti mobili mentre navigano attraverso un sito in tempo reale.

Mentre la maggior parte degli strumenti di Google si basa su test sintetici in ambienti simulati (noti come dati di laboratorio), Core Web Vitals viene misurato utilizzando i dati sul campo raccolti dall’esperienza utente di Google Chrome (Crux), un database di dati utente Chrome reale. I dati di campo catturano gli effetti drammatici delle variabili dell’utente reale, come il dispositivo, le condizioni di rete e/o le impostazioni. A seconda delle condizioni di un utente, le prestazioni di un sito possono variare drasticamente e avere un impatto sui punteggi vitali del Core Web.

Ogni metrica CWV ha soglie diverse da considerare buone, moderate o scarse. Tuttavia, tutti hanno una cosa in comune: Google utilizza il 75° percentile per classificare le pagine in questi gruppi: Una pagina che raggiunge la soglia per essere considerata veloce per il 75% o più del caricamento della pagina è una buona esperienza.

Non puoi ottimizzare ciò che non sai, quindi cerchiamo di conoscere ognuna delle tre metriche che compongono i Core Web Vitals.

Fonte: https://web.dev/vitals/

LCP (Large Contentful Paint)

In genere, gli utenti ritengono che la pagina sia stata caricata quando l’elemento di contenuto più grande è completamente visibile sullo schermo, ad esempio, dalla velocità del disegno concettuale più grande o LCP. Gli elementi contenuti possono includere elementi a livello di blocco, immagini (comprese le immagini all’interno di file SVG) e video. Per l’e-commerce, gli LCP di solito misurano la velocità di caricamento dell’immagine del prodotto/dell’eroe. Se questo è lento, gli utenti suppongono che l’intera esperienza sarà simile, il che li porta a lasciare il sito di un concorrente.

Gli LCP di 2,5 secondi o meno sono considerati veloci, le pagine con LCP compresi tra 2,6 e 4,0 secondi necessitano di miglioramenti e gli LCP più lunghi di 4,0 secondi sono lenti.

TheTieBar.comcarichi LCP in 800 ms sul livello 0 (Edgio)

Nell’esempio precedente, l’LCP di Tie Bar è contrassegnato a 900 ms quando l’immagine principale è completamente verniciata. Tie Bar fornisce costantemente caricamenti di pagine inferiori a secondi agli acquirenti mobili, offrendo al contempo personalizzazione, ricerche di inventario in tempo reale e prezzi dinamici sulle migliaia di pagine su Edgio.

In genere, LCP è influenzato da uno dei seguenti fattori:

  • Tempi di risposta del server lenti
  • JavaScript e CSS di blocco del rendering
  • Lunghi tempi di caricamento delle risorse
  • Problemi di rendering lato client

Per ottimizzare l’LCP, considerare quanto segue:

  1. “Ottimizzare i tempi di risposta del server instradando il traffico alla CDN POP più vicina disponibile, memorizzando nella cache le risorse, utilizzando un addetto all’assistenza e stabilendo presto connessioni di terze parti con “rel=”preconnect”.”
  2. Ridurre il tempo di blocco di JavaScript minimizzando il codice (ad esempio, rimuovendo gli spazi), comprimendo i dati con strumenti come Broti o Gzip, dividendo i pacchetti e inviando solo ciò che è necessario all’inizio, e servendo il codice con la sintassi più recente con strumenti come Babel. Ridurre i CSS rimuovendo tutti i CSS inutilizzati o i caratteri non necessari, come spaziatura, rientranza o commenti, e inserendo i CSS critici includendoli direttamente nell’intestazione della pagina.
  3. Per ridurre i tempi di caricamento delle risorse, ottimizzare e comprimere file di immagine e testo, precaricare le risorse essenziali e distribuire risorse diverse in base alla connessione di rete e alle risorse della cache utilizzando un addetto all’assistenza.
  4. Ottimizzare il rendering lato client riducendo il tempo di blocco di JavaScript (vedere il punto 2 per l’ottimizzazione), utilizzando il rendering lato server (SSR) e il pre-rendering.

Ritardo primo ingresso (FID)

Anche se la prima impressione di un utente è influenzata dalla velocità con cui viene resa l’immagine più grande, è altrettanto importante che il tuo sito sia reattivo una volta che l’utente tenta di interagire con esso. First input Delay, o FID, misura il tempo che intercorre tra la prima volta che un utente interagisce con una pagina (fa clic, tocca o preme un tasto) e il momento in cui il browser può rispondere a tale interazione.

In genere, si verifica un ritardo di input perché JavaScript viene eseguito sul thread principale e tutto JavaScript è un blocco di rendering per impostazione predefinita. Ciò significa che quando il browser si imbatte in un file JavaScript, deve mettere in pausa ciò che sta facendo per scaricare, analizzare, compilare ed eseguire quel JavaScript. Più tempo richiede, più ritarda l’esperienza utente e meno Google visualizzerà la pagina come utilizzabile.

Google considera un FID di 100 millisecondi o meno veloce, tra 1,1 e 3,0 secondi come necessario miglioramento e oltre 3,0 secondi come lento. Mentre è importante lottare per il 75° percentile per tutti i Core Web Vitals, Google consiglia di guardare il 95°-99° percentile per FID su dispositivi mobili e desktop, in quanto ciò rappresenterà le peggiori esperienze utente e verificherà le aree che necessitano di maggiori miglioramenti (poiché si concentrerà sul FID per oltre il 95% delle pagine caricate).

È anche importante notare che, a differenza di LCP e CLS, il FID può essere misurato solo sul campo (e non sarà trovato nei dati di laboratorio), in quanto richiede una reale interazione da parte dell’utente.

I motivi più comuni per i FID lenti includono:

  1. Attività lunghe che bloccano il thread principale per 50 millisecondi o più
  2. L’esecuzione di script di prima parte ritarda la prontezza dell’interazione
  3. Tempo di esecuzione JavaScript elevato

Da ‍How a optime per FID:

  1. Suddividere il codice a esecuzione prolungata in attività asincrone più piccole e utilizzare la suddivisione del codice.
  2. Spostare il carico (e l’esecuzione) di script pesanti per i componenti non essenziali fuori dal percorso critico e ridurre al minimo il recupero dei dati a cascata e la quantità di dati che devono essere post-elaborati sul lato client.
  3. Utilizzare un Web worker, come Comlink, Workway o Workerize, che consente di eseguire JavaScript su un thread in background, suddividere in codice il pacchetto JavaScript in più blocchi (noti anche come caricamento pigro) e caricare tutti gli script di terze parti con il metodo defer o asincrono.

Spostamento layout cumulativo (CLS)

La stabilità visiva di una pagina è un altro fattore che influisce sull’esperienza dell’utente e può impedire agli acquirenti di proseguire lungo il percorso di acquisto. La terza e ultima metrica di Core Web Vitals è la funzione di spostamento cumulativo del layout, o CLS, che misura la frequenza con cui gli utenti riscontrano cambiamenti di layout imprevisti.

Hai sperimentato questi casi: Stai per toccare un collegamento o un’immagine del prodotto, ma subito prima di toccare lo schermo, la pagina si sposta e bam, fai clic su un altro elemento involontariamente. Nel migliore dei casi, queste situazioni sono un po’ fastidiose, ma nel peggiore dei casi, si inviano gli acquirenti alla ricerca di un’esperienza più fluida e meno ingannevole sul Web.

Google calcola questi movimenti di pagina moltiplicando la frazione di impatto, o la quantità di contenuto visibile spostato nella vista, per la frazione di distanzao la distanza che un elemento instabile si è spostato nella cornice divisa per la dimensione più grande dello schermo (altezza o larghezza). Il totale di tutti i singoli punteggi (frazione di impatto x frazione di distanza) per ogni spostamento di layout inatteso che si verifica mentre un acquirente sfoglia determina la CLS di una pagina.

Google considera un CLS inferiore a 0,1 come buono, tra il 0,1 e il 0,25 come moderato e superiore a 0,25 come povero.

Se trovi un CLS scadente, è probabile che sia dovuto a uno dei seguenti:

  1. Un’immagine o un video che si ridimensiona
  2. Ridimensionamento annunci
  3. Carattere caricato in ritardo e visualizzato più grande o più piccolo del previsto

Per migliorare questa metrica, considerare quanto segue:

  1. Includere le dimensioni esatte delle immagini e degli elementi video.
  2. Evita annunci pop-up o banner. Invece, riservare staticamente uno spazio ampio per lo slot dell’annuncio.
  3. Evitare flash di testo non formattato o invisibile (FOIT/FOUT) con strumenti quali la visualizzazione dei caratteri e l’ API di caricamento dei caratteri.

In che modo Layer0 aiuta a ottimizzare la velocità per ogni metrica Core Web Vitals

I siti Web di e-commerce grandi e complessi con milioni di pagine, 1000 SKU, test A/B e personalizzazione, prezzi dinamici e ricerche di inventario in tempo reale possono raggiungere velocità inferiori ai secondi con Layer0. In effetti, Layer0 è l’unica piattaforma sul mercato a garantire LCP mediani al di sotto dei 500ms.

Sul livello 0, il contenuto esegue il rendering istantaneo, o il pittorico, su una pagina e diventa immediatamente accessibile grazie alla nostra CDN configurabile JavaScript, che riconosce l’applicazione, chiamata CDN-as-JavaScript. Utilizza il prefetching predittivo avanzato e l’edge computing per trasmettere contenuti dinamici (JSON/SSR/HTML) dall’edge al browser dell’utente, prima ancora che venga richiesto. In questo modo, i siti vengono sempre mantenuti 5 secondi in anticipo rispetto ai rubinetti degli acquirenti.

I siti Web su Layer0 hanno un tasso di hit cache superiore al 95% per i dati HTML e JSON all’edge, mentre i siti su CDN tradizionali sono in media pari al 6%. Si tratta di un’enorme differenza nella distribuzione dei contenuti che in genere rallentano un sito Web.

In conclusione

Caricamento rapido delle pagine differenziate tra deliziare gli acquirenti e spaventarli per il sito del vostro concorrente. I principali parametri vitali Web considerano la prima impressione di velocità, interattività e stabilità visiva di un utente misurando il più grande Contentful Paint, il primo ritardo di input e lo spostamento cumulativo del layout. Se le velocità sono superiori a 2,5 s per LCP, 100 ms per FID o .1 per CLS, è possibile presumere che sia gli utenti che Google percepiscano il sito come lento. Google abbasserà il tuo rango e i consumatori rimbalzeranno e non torneranno mai più.

In appena un paio di mesi, una scarsa esperienza di pagina danneggerà la reputazione del tuo marchio e avrà un impatto sul tuo posizionamento SEO. Proteggi il tuo SEO faticosamente guadagnato usando le tattiche di ottimizzazione offerte sopra, o vai istantaneamente con Layer0 (ora Edgio).

Layer0 è la soluzione all-in-one per sviluppare, distribuire, visualizzare in anteprima, sperimentare, monitorare, e gestisci il tuo frontend. Shoe Carnival, REVOLVE e 1-800-Flowers sono solo alcuni esempi di siti Web di eCommerce che offrono velocità inferiori al secondo e ne traggono vantaggio. Se hai domande sull’aggiornamento dell’esperienza della pagina o su come velocizzare il tuo sito, saremo lieti di metterti in contatto con un esperto di velocità del sito oggi stesso.

Il prossimo aggiornamento dell’esperienza della pagina di Google introduce i segnali derivati da Core Web Vitals (CWV) nell’algoritmo di classificazione ufficiale. I principali parametri vitali Web sono un insieme di metriche che misurano la velocità di caricamento delle pagine, diventano interattive e si stabilizzano visivamente per gli utenti reali che interagiscono con loro. I siti Web che non superano il test Core Web Vitals si posizioneranno al di sotto di quelli attualmente disponibili all’inizio del 2021.