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

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 dipinta. Tie Bar distribuisce costantemente carichi di pagine inferiori al secondo agli acquirenti mobili, offrendo al contempo personalizzazione, ricerche di inventario in tempo reale e prezzi dinamici sulle migliaia di pagine di Edgio.

In genere, l’LCP è interessato da uno dei seguenti fattori:

• Tempi di risposta del server lenti
• JavaScript e CSS che bloccano il 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 al POP CDN più vicino disponibile, memorizzando le risorse nella cache, utilizzando un service worker e stabilendo in anticipo connessioni di terze parti con “rel=”preconnessione”.”
2. Ridurre il tempo di blocco di JavaScript riducendo il codice (ad esempio, rimuovendo lo spazio bianco), comprimendo i dati con strumenti come Broti o Gzip, suddividendo 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 i CSS inutilizzati o i caratteri non necessari, come spaziatura, rientri o commenti, e inserendo i CSS critici direttamente nella parte superiore della pagina.
3. Per ridurre i tempi di caricamento delle risorse, ottimizzare e comprimere file di immagini e di testo, precaricare le risorse essenziali e distribuire risorse diverse in base alla connessione di rete e alle risorse della cache utilizzando un service worker.
4. Ottimizza il rendering lato client riducendo il tempo di blocco di JavaScript (vedere il n. 2 per ottimizzarlo), utilizzando il rendering lato server (SSR) e il pre-rendering.

Ritardo primo ingresso (FID)

Mentre la prima impressione di un utente è influenzata dalla velocità con cui viene eseguita la rappresentazione dell’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 interagisce per la prima volta con una pagina (clic, tocco o pressione di un tasto) fino al momento in cui il browser è in grado di rispondere a tale interazione.

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

Google considera un FID di 100 millisecondi o meno così veloce, tra 1,1 e 3,0 secondi come necessario miglioramento, e oltre 3,0 secondi come lento. Sebbene sia importante sforzarsi di raggiungere il 75° percentile per tutti i Core Web Vitals, Google consiglia di considerare il 95°-99° percentile per FID su dispositivi mobili e desktop, poiché questo rappresenterà le peggiori esperienze utente e verificherà le aree che necessitano di maggior miglioramento (in quanto si concentrerà sul FID per il 95%+ dei caricamenti delle pagine).

È 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 un’interazione reale con l’utente. ‍

I motivi più comuni per la lentezza dei FID includono:

1. Operazioni lunghe che bloccano il thread principale per 50 millisecondi o più
2. L’esecuzione di script di prima parte ritarda la disponibilità dell’interazione
3. Elevato tempo di esecuzione di JavaScript

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. Spostate il carico di script (e l’esecuzione) intensivo per i componenti non essenziali dal percorso critico e riducete al minimo il recupero dei dati a cascata e la quantità di dati da postelaborare sul lato client.
3. Utilizzare un Web worker, come Comlink, Workway o Workerize, che consente di eseguire JavaScript su un thread in background, dividere il pacchetto JavaScript in più parti (noto anche come lazy-loading) e caricare tutti gli script di terze parti con differimento o asincrono.

Spostamento layout cumulativo (CLS)

La stabilità visiva di una pagina è un altro fattore che influisce sull’esperienza utente e può impedire agli acquirenti di continuare il percorso di acquisto. La terza e ultima metrica di Core Web Vitals è Cumulative Layout Shift (spostamento cumulativo layout), o CLS, che misura la frequenza con cui gli utenti subiscono cambiamenti di layout imprevisti.

Hai sperimentato questi casi: Stai per toccare un link o un’immagine di prodotto, ma subito prima di toccare lo schermo, la pagina si sposta, e bam, fai clic su un’altra cosa involontariamente. Nel migliore dei casi, queste situazioni sono un po’ fastidiose, ma nel peggiore dei casi, si invia agli acquirenti alla ricerca di un’esperienza più fluida e meno ingombrante sul Web.

Google calcola questi movimenti della pagina moltiplicando la frazione di impatto, o la quantità di contenuto visibile spostato nella vista, per la frazione di distanza , o la distanza che un elemento instabile ha spostato nel fotogramma 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 imprevisto che si verifica durante la ricerca di un acquirente determina il 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 maggiore di 0,25 come povero. ‍

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

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

Per migliorare questa metrica, considerare quanto segue:

1. Includi le dimensioni esatte delle tue immagini e degli elementi video.
2. Evita annunci popup o banner. Al contrario, riservare staticamente un ampio spazio 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 ciascuna metrica Core Web Vitals

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

Su Layer0, il contenuto esegue istantaneamente il rendering, o dipinge, su una pagina e diventa immediatamente toccabile a causa della nostra CDN JavaScript configurabile in base alle applicazioni, denominata 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 mantenuti 5 secondi avanti rispetto ai rubinetti degli acquirenti in qualsiasi momento.

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

In sintesi

Il caricamento rapido delle pagine consente di distinguere tra il piacere degli acquirenti e il loro timore per il sito della concorrenza. Core Web Vitals prende in considerazione la prima impressione dell’utente di velocità, interattività e stabilità visiva misurando la vernice intensiva più grande, il ritardo al primo 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 supporre 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 influenzerà il tuo posizionamento SEO. Proteggi il tuo SEO faticosamente guadagnato utilizzando 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 ed eseguire il frontend. Shoe Carnival, REVOLVE e 1-800-Flowers sono solo alcuni esempi di siti Web di e-commerce che offrono velocità inferiori al secondo e ne stanno sfruttando i vantaggi. 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.

L’imminente aggiornamento di Page Experience di Google introduce i segnali derivati da Core Web Vitals (CWV) nell’algoritmo di classificazione ufficiale. I principali parametri vitali Web sono una serie di metriche che misurano la velocità con cui le pagine vengono caricate, interattive e stabilizzate visivamente per gli utenti reali che interagiscono con esse. I siti Web che non superano il test Core Web Vitals saranno più bassi di quanto non siano attualmente disponibili all’inizio del 2021.