Home Articoli tecnici Il nucleo dei segni vitali del Web
Applications

About The Author

Outline

Introduzione

Dalla sua introduzione nel maggio 2020, la suite Core Web Vitals (CWV) di Google è diventata una metrica importante per misurare le performance dei siti web. Dato che Google considera questi valori come parte del loro algoritmo di classificazione delle pagine, massimizzando le prestazioni del tuo sito web in termini di CWV non solo migliora l’esperienza per gli utenti, ma migliora il posizionamento del tuo motore di ricerca. In questo articolo vengono illustrati suggerimenti e tecniche per migliorare i punteggi delle pagine, aumentare la soddisfazione degli utenti e aumentare i profitti.

Che cosa sono i segni vitali di base per il Web?

Come molte altre cose nella tecnologia, i Web Vitals di Google sono uno sciame di acronimi di tre lettere, ognuno dei quali rappresenta un aspetto misurabile delle prestazioni di un sito web. Per impostare la fase, definiamo le tre metriche chiave che definiscono i principali parametri vitali Web:

Vernice Contentful più grande

Large Contentful Paint (LCP): Misura la velocità di carico percepita concentrandosi sul tempo necessario per caricare il contenuto visibile sopra la piega. Per offrire un’esperienza utente ideale, LCP deve essere attivato entro 2,5 secondi nella timeline di caricamento della pagina.

Ritardo primo ingresso

Ritardo primo input (FID): Misura la reattività della pagina misurando il ritardo tra le azioni dell’utente e la risposta della pagina. Per offrire un’esperienza utente ideale, le pagine devono avere un FID di 100 millisecondi o meno.

Spostamento layout cumulativo

Spostamento layout cumulativo (CLS): Misura la stabilità visiva utilizzando una misurazione composita degli spostamenti di layout sulla pagina durante il rendering. Per offrire un’esperienza utente ideale, le pagine devono mantenere un CLS pari o inferiore a 0,1; tutto ciò che è compreso tra 0,1 e 0,25 è considerato moderato e superiore a 0,25 è scarso.

… e perché sono importanti?

Per molte aziende, le performance dei siti Web sono direttamente correlate al successo aziendale. La ricerca indica che i siti Web con punteggi CWV superati possono godere fino al 37% di visibilità in più nei risultati di ricerca rispetto alle pagine che non lo fanno (Beus); e che i punteggi CWV migliorati possono aumentare sia il fatturato per visitatore sia il tasso di conversione (Duong et al.).

Mentre si lavora con Akira, Una boutique di moda femminile, Edgio è stata in grado di migliorare i CWV del sito web, portando i tempi di caricamento della prima pagina da 5 secondi a ~1 secondo, migliorando le misurazioni CWV e, infine, fornendo un aumento del +30% nel traffico organico, un miglioramento del +61% nelle iniziazioni di checkout e un aumento del 37% nel tasso di conversione.

In parole povere, i siti Web più veloci consentono una migliore classifica SEO e utenti più felici, in particolare nel contesto dei siti Web di e-commerce, che si combinano per ridurre i tassi di rimbalzo e aumentare le conversioni.

Quindi, come possiamo migliorarli?

Ritardo primo ingresso

Cominciamo con il frutto a basso costo: First input Delay. La buona notizia è che i siti web hanno superato i punteggi FID più spesso di no, il che è bello da vedere! Se, tuttavia, non è così, spesso il colpevole sono gli script di terze parti caricati nelle prime fasi del ciclo di vita del sito Web, che possono bloccare l’esecuzione del thread principale necessario per ricevere l’input dell’utente. Gli strumenti che catturano gli errori ed eseguono la registrazione su schermo sono i candidati principali per un ulteriore controllo.

Infatti, tutto ciò che blocca il thread di esecuzione principale può contribuire a prestazioni FID inadeguate. Tenete d’occhio le attività JavaScript a uso intensivo di risorse o a esecuzione prolungata e prendete in considerazione il refactoring di codice non correlato all’interfaccia utente a un web worker, nonché l’utilizzo di tecniche di caricamento e suddivisione del codice per garantire che venga caricato solo il JavaScript richiesto e solo quando necessario.

Inoltre, sebbene tecnicamente non sia un elemento centrale dei CWV, vale la pena menzionare un’altra metrica correlata: Interaction to Next Paint (INP). INP misura il tempo che intercorre tra l’interazione con una pagina e il successivo aggiornamento della pagina che riflette tale interazione. Mentre INP e FID misurano entrambi la reattività complessiva della pagina, INP si occupa di tutte le interazioni della pagina piuttosto che della prima, con l’obiettivo di garantire che la pagina rimanga reattiva per tutta la sessione, non solo per le interazioni iniziali. INP tiene traccia delle peggiori prestazioni di interazione tra l’esperienza di un utente e le segnala come fondamentali. È molto probabile che presto INP sostituirà FID come misura della reattività della pagina, quindi vale la pena tenere d’occhio.

Vernice Contentful più grande

Probabilmente la metrica più importante e di impatto per le prestazioni della pagina è LCP. “In qualche modo prevedibile, l’esempio più comune di Large Contentful Paint è un’immagine “eroica”, un’immagine o un video di grandi dimensioni, che solitamente occupa l’intera larghezza del viewport sopra la “piega”.” Sebbene le tecniche per ottimizzare questo elemento siano le stesse di qualsiasi altra risorsa di pagina, il tempo necessario per il rendering di tale risorsa è di massima importanza, poiché questo è il primo elemento principale che un utente sperimenterà.

In attesa in coda
La suddivisione della tempistica delle richieste per l’elemento LCP è estremamente utile per ottimizzarne le prestazioni. Qualsiasi richiesta effettuata da un browser inizia con la coda. Ogni millisecondo di richieste LCP speso in coda è un millisecondo che contribuirà al punteggio LCP, quindi se si scopre che questi elementi trascorrono una quantità sproporzionata di tempo a languire nella coda del browser, esaminare cosa viene richiesto prima di esso e perché, e adottare le misure necessarie per assegnare priorità alle risorse LCP. Forse le risorse sono al di sotto della piega, o altri script che possono essere caricati in modo pigro o altrimenti rinviati. L’ordine delle operazioni è fondamentale.

In attesa sul server
Dopo aver avviato la richiesta di rete, il client del browser deve attendere che il server riceva, elabori e risponda a tale richiesta. Questa metrica è chiamata TTFB (Time-to-First-byte). Se il server risponde lentamente alla richiesta, il punteggio LCP verrà compromesso. Questa è una delle aree in cui una CDN può avere un impatto significativo sul miglioramento della velocità, poiché le CDN possono mantenere una copia memorizzata nella cache della risorsa in una posizione geograficamente vicina agli utenti finali e rispondere con tale risorsa più rapidamente di un singolo server applicazioni. Altri aspetti importanti dell’utilizzo di una CDN includono WAF di sicurezza integrati e la capacità di rispondere a picchi di traffico di grandi dimensioni. Se stai andando per la velocità, dovresti utilizzare una CDN.

Largo sul filo
A questo punto, si spera che il browser richieda le risorse LCP nelle prime fasi del ciclo di vita delle pagine e che il server risponda rapidamente. L’elemento successivo da considerare è la dimensione complessiva della risorsa richiesta. Ogni byte che deve viaggiare “via cavo” verso il browser richiederà un po’ di tempo, e più di questi byte ci sono, più tempo sarà necessario per il completamento della richiesta. È pertanto opportuno garantire che le risorse siano il più possibile ridotte al minimo per ridurre al minimo il tempo impiegato per il loro trasferimento. Ciò potrebbe includere l’utilizzo di servizi di ottimizzazione delle immagini e hosting di terze parti come kraken.io o imgix.com, che possono sia ottimizzare che servire i file multimediali in formati “NextGen” come WebP, riducendo ulteriormente le dimensioni.

Aiutare il browser
Oltre alle ottimizzazioni delle dimensioni, è consigliabile utilizzare <i tag immagine> , che consentiranno al browser di scegliere la risorsa giusta da richiedere al dispositivo in modo più intelligente. Un browser desktop può avere ampie aree di spazio per lo schermo per visualizzare immagini a risoluzione più elevata; tuttavia, queste stesse risorse si impantanano su un dispositivo mobile con uno schermo più piccolo. Utilizzando risorse ottimizzate e media query CSS, è possibile garantire che il browser richieda la risorsa giusta per il tipo di dispositivo e ridurre il tempo impiegato per trasferire i byte dal server al client.

Inoltre, è possibile dare una mano al browser chiedendo di precaricare le risorse LCP e specificando una priorità di recupero. In questo modo, il browser fornisce gli indizi per assegnare priorità alle risorse chiave prima di quelle meno critiche. Più velocemente si accede al browser, più velocemente si può eseguire il rendering e più velocemente si verifica il LCP, meglio è.

Spostamento layout cumulativo

Lo vediamo sempre. Dopo aver inviato il browser per recuperare un sito Web, la pagina inizia a caricarsi; mentre la pagina si costruisce, vedi il pezzo che ti interessa e spostati per fare clic su di esso quando improvvisamente l’intera pagina si sposta e il collegamento che credevi di fare è improvvisamente altrove! Questo fenomeno è chiamato spostamento del layout. È fastidioso per tutti, di solito autoinflitti, e dovremmo sforzarci di minimizzarlo per il bene dell’umanità.

I soliti sospettati
I colpevoli tipici per punteggi CLS più alti sono:

  • Testate adesive
  • Banner promozionali o “Hero” caricati e resi lato client
  • Newsletter, coupon e avvisi GPDR
  • Altre integrazioni di terze parti che vengono inserite dinamicamente nella pagina

Imposta dei limiti
Ricordate l’ <elemento immagine> a cui abbiamo fatto riferimento durante la discussione su LCP? Non dimenticate di aggiungere dimensioni ai vari elementi in esso contenuti. Omettendo questi valori, si esce dal posto di guida quando si dirige il browser su come eseguire il rendering di questi elementi. Definendo le dimensioni, il browser può mettere da parte la quantità corretta di spazio in cui verrà colorata l’immagine, riducendo lo spostamento.

Lo stesso vale per qualsiasi contenuto che potrebbe essere aggiunto dinamicamente alla pagina. Annunci pubblicitari, <iframe>o altri contenuti aggiunti dinamicamente possono contribuire a CLS. Il contenuto della pagina si sposterà meno riservando spazio per questi elementi in anticipo. Inoltre, evitate di aggiungere il contenuto sopra il contenuto della pagina esistente, poiché ciò causerà lo spostamento dell’intera pagina di seguito.

Aiutando il browser a ritagliare lo spazio in anticipo, si riduce il CLS, ma potrebbe andare a scapito dell’esperienza utente complessiva, poiché l’utente attende che queste parti della pagina altrimenti vuota vengano popolate con contenuti utili. Come via di mezzo, implementare gli scheletri di caricamento degli elementi può essere una tecnica utile per comunicare all’utente che ci sono altre cose in arrivo, dando l’impressione di un’esperienza più veloce mentre il browser fa il resto del lavoro pesante per coordinare il contenuto della pagina aggiuntiva. Inoltre, è possibile e opportuno implementarle utilizzando animazioni CSS piuttosto che GIF animate, il che significa che è possibile utilizzare solo poche righe di CSS per implementare questa tecnica in tutto il sito Web.

Conclusione

In superficie, Core Web Vitas può sembrare gli ultimi pezzi del leggendario e oscuro algoritmo di Google per determinare il grado di pagina all’interno dei risultati di ricerca – e in una certa misura, potrebbe essere corretto. Tuttavia, più di questo, i principali elementi vitali del Web rappresentano un framework più concreto per misurare le prestazioni delle pagine e stabilire una base di riferimento per descrivere le cose che contano in termini di esperienza utente. Anche se non esaustive, le tecniche di cui sopra dovrebbero aiutarti a risolvere i problemi e ottimizzare le prestazioni del tuo sito Web, con un conseguente miglioramento dell’esperienza utente, della classifica delle pagine e dei ricavi.