Introduzione
Dalla sua introduzione nel maggio 2020, la suite Core Web Vitals (CWV) di Google è diventata un’importante metrica per misurare le prestazioni del sito web. Dato che Google considera questi valori come parte del suo algoritmo di classificazione delle pagine, massimizzare le prestazioni del tuo sito web in termini di CWV non solo migliora l’esperienza per i tuoi utenti, ma migliora il posizionamento dei motori di ricerca. In questo articolo verranno illustrati suggerimenti e tecniche per migliorare i punteggi delle pagine, aumentare la soddisfazione degli utenti e aumentare i profitti.
Cosa sono i principali segni vitali Web?
Come molte altre cose della tecnologia, i Web Vitals di Google sono uno sciame di acronimi di tre lettere, ciascuno 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 del Web:
Vernice principale
Large Contentful Paint (LCP): Misura la velocità di carico percepita concentrandosi sulla quantità di tempo necessaria per caricare il contenuto visibile sopra la piega. Per offrire un’esperienza utente ideale, LCP deve essere attivato entro 2,5 secondi nella sequenza temporale di caricamento della pagina.
Ritardo primo ingresso
First input Delay (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 fornire un’esperienza utente ideale, le pagine devono mantenere un CLS di 0,1 o inferiore; tutto tra 0,1 e 0,25 è considerato moderato e maggiore di 0,25 è scarso.
… e perché sono importanti?
Per molte aziende, le performance dei siti Web hanno una correlazione diretta con il successo aziendale. Le ricerche indicano 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 le entrate per visitatore che il tasso di conversione (Duong et al.).
Mentre si lavora con Akira, 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, in ultima analisi, ottenendo un aumento del +30% del traffico organico, un miglioramento del +61% nelle operazioni di checkout e un aumento del 37% del tasso di conversione.
In parole povere, i siti Web più veloci consentono di ottenere classifiche SEO migliori e utenti più felici, in particolare nel contesto dei siti Web di e-commerce; questi ultimi si combinano per ridurre i tassi di rimbalzo e aumentare le conversioni.
Allora, come possiamo migliorarli?
Ritardo primo ingresso
Iniziamo con il frutto a bassa portata: First input Delay. La buona notizia è che i siti web hanno superato i punteggi FID più spesso che no, il che è fantastico 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 necessaria per ricevere l’input dell’utente. Gli strumenti che catturano gli errori ed eseguono la registrazione delle schermate sono i candidati principali per un ulteriore esame.
In effetti, qualsiasi cosa blocchi il thread di esecuzione principale può contribuire a scarse prestazioni FID. Tieni d’occhio le attività JavaScript ad uso intensivo di risorse o a esecuzione prolungata e valuta la possibilità di refactoring del codice non correlato all’interfaccia utente a un web worker, nonché di utilizzare tecniche di caricamento lento e di suddivisione del codice per garantire che venga caricato solo il JavaScript richiesto e solo quando necessario.
Inoltre, anche se tecnicamente non è 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 interazione, 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 in tutta l’esperienza dell’utente e le segnala in modo approssimativo. È molto probabile che presto INP sostituirà FID come misura della reattività della pagina, quindi vale la pena tenere d’occhio.
Vernice principale
Probabilmente la metrica più importante e di impatto per le prestazioni delle pagine è LCP. In un certo senso, l’esempio più comune di Large Contentful Paint è un’immagine “eroina”, ovvero un’immagine o un video di grandi dimensioni, che occupa solitamente l’intera larghezza della vista al di sopra della “piegatura”. 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 primaria importanza perché si tratta del primo elemento principale che un utente sperimenterà.
In attesa nella coda
L’analisi dei tempi di richiesta per l’elemento LCP è estremamente utile per ottimizzarne le prestazioni. Qualsiasi richiesta effettuata da un browser inizia con la coda. Ogni millisecondo che le richieste LCP spendono nella coda è un millisecondo che contribuirà al punteggio LCP, quindi se si scopre che questi elementi stanno sprecando una quantità sproporzionata di tempo nella coda del browser, esaminare cosa viene richiesto prima di esso e perché e adottare misure per assegnare priorità alle risorse LCP. Forse le risorse sono al di sotto della piega o altri script che possono essere caricati a 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 ne risentirà. Questa è una delle aree in cui la CDN può avere un impatto significativo sul miglioramento della velocità, in quanto 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 di applicazioni. Altri aspetti importanti dell’utilizzo di una CDN includono i WAF di sicurezza integrati e la capacità di rispondere a picchi di traffico di grandi dimensioni. Se stai andando per la velocità, dovresti usare una CDN.
Largo sul filo
A questo punto, si spera che il browser richieda le risorse LCP nelle prime fasi del ciclo di vita della pagina 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à del tempo e più di questi byte ci sono, più tempo sarà necessario per completare la richiesta.” È pertanto opportuno garantire che le risorse siano il più possibile ridotte al fine di ridurre al minimo il tempo impiegato per trasferirle. Ciò potrebbe includere l’utilizzo di servizi di hosting e ottimizzazione delle immagini di terze parti come kraken.io o imgix.com, che possono ottimizzare e 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 per il dispositivo in modo più intelligente. Un browser desktop può avere ampie aree di visualizzazione dello schermo per visualizzare immagini a risoluzione più elevata; tuttavia, queste stesse risorse rallentano 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 riduca il tempo impiegato per trasferire i byte dal server al client.
Inoltre, è possibile aiutare il 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 le cose arrivano al browser, più velocemente è possibile eseguire il rendering e più velocemente avviene l’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 sviluppa, vedi il pezzo che ti interessa e spostati per selezionarlo quando improvvisamente l’intera pagina si sposta e il collegamento che credi di fare clic si trova improvvisamente altrove! Questo fenomeno è chiamato spostamento del layout. È fastidioso per tutti, di solito autoinflitto, e dovremmo sforzarci di minimizzarlo per il bene dell’umanità.
I soliti sospettati
I responsabili tipici dei punteggi CLS più elevati sono:
- Intestazioni adesive
- “Banner promozionali o “Hero” caricati e resi lato client.
- Newsletter, buoni e avvisi GPDR
- Altre integrazioni di terze parti che vengono inserite dinamicamente nella pagina
Impostare dei limiti
Ricordate l'<>elemento immagine a cui abbiamo fatto riferimento durante la discussione sull’LCP? Non dimenticate di aggiungere dimensioni ai vari elementi contenuti in esso. Omettendo questi valori si esce dal sedile del conducente 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à dipinta 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à di meno riservando spazio a questi elementi in anticipo. Inoltre, evitare di aggiungere il contenuto al di sopra del contenuto della pagina esistente, poiché in questo modo l’intera pagina verrà spostata al di sotto.
Aiutando il browser a ritagliare lo spazio in anticipo si riduce il CLS, ma può andare a scapito dell’esperienza complessiva dell’utente, mentre l’utente attende che queste porzioni della pagina altrimenti vuota vengano popolate con contenuti utili. Come punto di partenza, implementare gli scheletri di caricamento degli elementi può essere una tecnica utile per comunicare all’utente che c’è di più 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, queste possono e devono essere implementate utilizzando animazioni CSS piuttosto che GIF animate, il che significa che solo poche righe di CSS possono essere utilizzate per implementare questa tecnica in tutto il vostro sito Web.
Conclusione
In apparenza, Core Web Vitas può sembrare gli ultimi pezzi del favoloso e oscuro algoritmo di Google per determinare il rango delle pagine all’interno dei loro risultati di ricerca – e in una certa misura, potrebbe essere corretto. Tuttavia, oltre a questo, i principali elementi vitali del Web rappresentano un framework più concreto per misurare le prestazioni delle pagine e stabilire una base per descrivere le cose importanti in termini di esperienza utente. Anche se non esaustive, le tecniche sopra menzionate dovrebbero aiutarti a risolvere i problemi e ottimizzare le prestazioni del tuo sito Web, con conseguenti miglioramenti in termini di esperienza utente, classificazione delle pagine e ricavi.
