Google vuole migliorare le prestazioni del web con i Core Web Vitals. Perché? Perché il business di Google si basa prevalentemente sul web: siti e applicazioni web lente spingono gli utenti a tornare alle applicazioni native.
Il vostro posizionamento nei risultati di Google Search è in gran parte determinato dalle parole chiave del termine di ricerca, dall’uso di quelle parole chiave all’interno della vostra pagina e dalla popolarità della vostra pagina secondo il numero (e la qualità) dei link proveniente da altre parti. Da agosto 2021, Google sta facendo degli sforzi anche per valutare le pagine in base alle prestazioni.
Questo articolo vi mostrerà come potete ottimizzare il vostro sito per le metriche Core Web Vitals di Google.
Perché Core Web Vitals?
Il contenuto rimane cruciale. Ma se confrontate due siti con testo e popolarità simili, quello che offre la migliore esperienza web avrà la priorità nei risultati di Google Search.
Oltre a un page rank migliorato, i siti ad alte prestazioni possono essere inclusi nel carosello di ricerca mobile. Questo era precedentemente riservato alle Accelerated Mobile Pages (AMP), che richiedevano il porting dei contenuti in un sito separato ospitato da Google. AMP ha attirato critiche, soprattutto perché le pagine non sono sempre più veloci di quelle di un sito statico o WordPress ben ottimizzato. Tuttavia questo non è più un requisito.
Non importa cosa avete scelto: più veloce e responsive è il vostro sito, più possibilità ha di posizionarsi più in alto nei risultati di Google Search.
Se considerate che la pagina media pesa all’incirca 2 MB, fa più di 60 richieste HTTP e impiega 16 secondi per il rendering completo su un dispositivo mobile, vedrete che c’è un certo margine per migliorare il vostro sito. Vi mostreremo i modi migliori per ottenere questi miglioramenti.
Fattori Chiave del Posizionamento su Google
Ci sono quattro fattori chiave di posizionamento da esaminare prima di iniziare a valutare le prestazioni:
- HTTPS: HTTPS è essenziale. Il vostro sito stabilisce una connessione sicura tra il browser dell’utente e il webserver?
- Facilità d’uso per i dispositivi mobili: Il vostro sito deve funzionare bene ed essere usabile su dispositivi mobile e a piccolo schermo: è così? Carica in modo fluido? Il testo è abbastanza grande? Le aree cliccabili sono abbastanza chiare per i comandi tattili?
- Nessun annuncio interstitial: Evitate annunci interstitial invadenti che richiedono una quantità irragionevole di spazio sullo schermo. Il vostro contenuto è sempre leggibile? È parzialmente oscurato da pop-up interstitial o banner? La vostra pubblicità o le vostre promozioni di marketing rendono il sito difficile da usare?
- Navigazione sicura: Il vostro sito dovrebbe essere privo di malware, virus, phishing, frodi e altre truffe.
Una volta soddisfatti questi requisiti, il vostro sito sarà valutato per le sue prestazioni.
Come Fa Google a Valutare le Prestazioni del Web?
Rendere il vostro sito veloce nel caricamento, nel rendering e nella reattività è vitale. Ma quanto è veloce per gli utenti?
Le applicazioni per misurare le prestazioni come DevTools del browser riportano misure tecniche come:
- Tempo di blocco: Il tempo trascorso in attesa dell’inizio di un download, tipicamente perché altre risorse come fogli di stile e script hanno una priorità più alta.
- Risoluzione DNS: Il tempo per risolvere un hostname in un indirizzo IP per recuperare una risorsa.
- Tempo di connessione: Il tempo per inizializzare una connessione TCP.
- Time to First Byte (TTFB): Il tempo totale tra la richiesta e il primo byte della risposta.
- Tempo di ricezione: Il tempo per recuperare l’intera risorsa.
- Tempo di caricamento del DOM: Il tempo per scaricare e rendere il Document Object Model HTML. Questo è di solito il primo punto in cui gli script che analizzano o modificano il DOM possono essere eseguiti in modo affidabile.
- Tempo di caricamento della pagina: Il tempo per scaricare la pagina e tutte le risorse come immagini, fogli di stile, script e così via.
- Peso totale della pagina: La dimensione totale di tutte le risorse. Spesso viene riportata sia la dimensione compressa (download) che quella non compressa.
- Il numero di elementi DOM: Il numero totale di elementi HTML nella pagina. Più elementi ci sono, più tempo impiega la pagina per essere elaborata.
- First Contentful Paint (FCP): Il tempo impiegato prima che il browser renda il primo pixel di contenuto.
- First Meaningful Paint (FMP): Il tempo impiegato prima che il contenuto primario della pagina diventi visibile all’utente.
- Time to Interactive (TTI): Il tempo impiegato prima che una pagina sia completamente interattiva e possa rispondere in modo affidabile all’input dell’utente.
- First CPU Idle: Il tempo necessario alla CPU per renderizzare la pagina ed eseguire tutti gli script di inizializzazione, in attesa di ulteriori input.
- Utilizzo della CPU: L’attività di elaborazione richiesta durante il rendering della pagina e la risposta all’input dell’utente.
- Layout al secondo: la velocità con cui il browser deve ricalcolare gli stili e i layout di pagina.
Queste possono essere usate per determinare specifici colli di bottiglia come il carico del server, il caching del CMS, il caching del browser, la velocità di download e l’efficienza di JavaScript. Ma non possono determinare se una pagina fornisce un’esperienza utente buona o cattiva. Per esempio:
- Un’applicazione potrebbe scaricarsi e apparire velocemente ma diventare non responsive dopo la prima interazione perché sta eseguendo una grande quantità di codice JavaScript non ottimizzato.
- Un’applicazione di chat potrebbe scaricare continuamente dati mentre gli utenti pubblicano messaggi. Uno strumento di valutazione potrebbe presumere di non aver mai completato il caricamento, nonostante la pagina sembri responsive.
I Core Web Vitals sono il tentativo di Google di risolvere questi dilemmi.
Cosa Sono i Core Web Vitals?
I Core Web Vitals (CWV) di Google sono tre metriche di performance che valutano l’esperienza utente nel mondo reale:
- Largest Contentful Paint (LCP): Prestazioni di caricamento
- First Input Delay (FID): Prestazioni di interattività
- Cumulative Layout Shift (CLS): Prestazioni di stabilità visiva
Questo nuovo aggiornamento dell’algoritmo di Google ha iniziato a diffondersi globalmente dalla fine di agosto 2021. Le metriche Core Web Vitals influenzano principalmente i risultati di ricerca mobile, ma si proseguirà poi con gli equivalenti desktop se l’esperimento avrà successo.
I punteggi LCP, FID e CLS di una pagina si basano sugli ultimi 28 giorni di metriche reali dell’utente raccolte in modo anonimo attraverso il browser Chrome. Queste misurazioni possono variare a causa del dispositivo dell’utente, della connessione e di altre attività concomitanti, quindi viene calcolato il 75° percentile piuttosto che una media.
In altre parole, le metriche di tutti gli utenti sono ordinate dalla migliore alla peggiore, e viene presa la cifra a tre quarti. Tre visitatori del sito su quattro sperimenteranno quindi quel livello di prestazioni, o uno superiore.
Qualsiasi pagina che raggiunge un buon punteggio (verde) per tutte e tre le metriche Core Web Vitals riceverà un posizionamento più alto nei risultati di ricerca e sarà inclusa nel carosello “Top Stories” nell’applicazione Google News.
Nelle sezioni seguenti, descriveremo l’algoritmo usato per calcolare una metrica, gli strumenti che potete usare per identificare il punteggio di una pagina, le cause tipiche dei punteggi bassi e i passi che potete fare per risolvere i problemi di prestazioni.
Largest Contentful Paint (LCP)
Largest Contentful Paint misura le prestazioni di caricamento. In sostanza, quanto velocemente viene reso il contenuto utilizzabile sulla pagina?
Il LCP analizza quanto tempo impiega l’immagine più grande o il blocco di testo a diventare visibile all’interno della finestra del browser (above the fold). Nella maggior parte dei casi, l’elemento più prominente sarà un’immagine, un banner, un titolo o un grande blocco di testo.
Con il Largest Contentful Paint si possono analizzare questi elementi:
- immagini (elemento
<img>) - immagini all’interno di grafica vettoriale (un
<image>incorporato in un<svg>) - miniature video (un attributo poster impostato su un URL immagine all’interno di un elemento
<video>) - elementi con immagini di sfondo (tipicamente caricati con la proprietà CSS
background-image url()) - elementi a livello di blocco contenenti testo
Le pagine in cui il Largest Contentful Paint viene completato entro i primi 2,5 secondi del caricamento della pagina sono considerate buone (verde). Le pagine che superano i 4.0 secondi sono considerate scarse (rosso):
Strumenti di Analisi di Largest Contentful Paint
LCP è la metrica Core Web Vital più facile da comprendere, ma potrebbe non essere ovvio quale elemento sarà scelto per l’analisi.
Il pannello DevTools Lighthouse è incluso nei browser basati su Chromium come Chrome, Edge, Brave, Opera e Vivaldi. Aprite DevTools dal menu del browser, di solito da Altri strumenti > Strumenti di sviluppo o dalle scorciatoie da tastiera Ctrl | Cmd + Shift + i o F12, poi navigate fino alla scheda Lighthouse (le vecchie edizioni potrebbero chiamarla Audit).
Generate un rapporto Prestazioni da mobile, poi esaminate la sezione Prestazioni risultante. Il tempo di Largest Contentful Paint risultante viene mostrato con una sezione espandibile, che identifica l’elemento scelto:
Potete generare informazioni identiche negli strumenti online PageSpeed Insights e web.dev Measure se non avete accesso a un browser basato su Chromium:
Il pannello Performance di DevTools mostra anche un indicatore LCP. Per iniziare, fate clic sull’icona circolare Record, ricaricate la pagina e poi fate clic sul pulsante Stop per visualizzare il rapporto. Fate clic sull’icona LCP nella sezione Timings per identificare l’elemento e visualizzare un riassunto delle statistiche.
L’estensione Web Vitals è disponibile per Google Chrome ma può essere installata sulla maggior parte dei browser basati su Chromium. Calcola le metriche Core Web Vitals per ogni sito che visitate e la sua icona diventa verde, arancione o rossa a seconda del risultato. Potete anche fare clic sull’icona dell’estensione per visualizzare più dettagli sul LCP:
La Search Console di Google ora offre una sezione Core Web Vitals se il vostro sito viene aggiunto come proprietà. Il rapporto illustra come le metriche CWV sono cambiate nel tempo. Notate che non identifica metriche LCP specifiche e sono disponibili solo i siti con un traffico ragionevolmente alto:
Il Chrome User Experience Report vi permette di consultare le statistiche reali di utilizzo, compreso l’LCP attraverso diversi Paesi, connessioni e dispositivi, per un URL specifico. È un progetto pubblico su Google BigQuery, quindi dovete registrarvi per un account Google Cloud Platform e fornire i dettagli di fatturazione. Di nuovo, il rapporto sarà utile solo quando un URL ha un livello di traffico ragionevolmente alto.
Infine, la libreria JavaScript web-vitals è un piccolo script di 1 kB che può calcolare LCP e altre metriche Core Web Vitals per utenti reali sul votro sito live. Può essere scaricato da un CDN, quindi potete aggiungere il seguente script al vostro HTML <head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() è una funzione asincrona a cui viene passata una callback attivata quando il valore LCP è stato calcolato (anche se potrebbe non attivarsi mai se la pagina viene caricata in una scheda in background). Alla funzione di callback viene passato un oggetto contenente:
name: il nome della metrica (“LCP” in questo caso)value: il valore calcolatoid: un ID unico che rappresenta questa metrica per la pagina correntedelta: il delta tra il valore corrente e l’ultimo valore riportatoentries: un array di voci usate nel calcolo del valore
Lo script qui sopra emette l’oggetto nella console, anche se è più pratico inviare i dati a un server o a Google Analytics per ulteriori analisi.
Cause Comuni di Punteggi Bassi per il Largest Contentful Paint
Bassi punteggi di LCP sono tipicamente causati da pagine che si caricano lentamente e che impediscono al blocco più grande di apparire rapidamente:
- La risposta del server potrebbe essere lenta perché è sovraccarico o sta facendo troppo lavoro per rendere una pagina. Questo non si deve necessariamente al vostro sito, ma potrebbe dipendere dai limiti del server se state usando un servizio di hosting condiviso.
- I CSS e i JavaScript che bloccano il rendering possono ritardare il caricamento della pagina se sono referenziati nell’HTML sopra il contenuto primario.
- Altre risorse come immagini e video di grandi dimensioni possono ridurre la larghezza di banda disponibile e richiedere più tempo per il rendering.
- Anche il contenuto della pagina generato sul client piuttosto che sul server richiede più tempo per apparire.
Come Migliorare i Punteggi del Largest Contentful Paint
Un controllo accurato può identificare i problemi di caricamento, ma generalmente si tratta di ridurre la quantità di dati inviati al browser. I seguenti consigli vi aiuteranno a migliorare il punteggio LCP:
- Aggiornate il vostro server e/o il servizio di hosting. Assicuratevi che la velocità di download rimanga alta anche nei momenti di alto utilizzo.
- Attivate la compressione del server e HTTP/2+. Non c’è ragione per non farlo!
- Riducete lo sforzo del server. Rimuovete il codice inutilizzato e i plugin CMS, poi attivate una cache efficace.
- Assicuratevi che il browser possa memorizzare i file nella cache in modo efficace. Impostate Expires, Last-Modified e/o ETag hash appropriati nell’intestazione HTTP, in modo che i file non vengano richiesti di nuovo.
- Usate un Content Delivery Network (CDN) per dividere il carico e ospitare le risorse su server geograficamente più vicini agli utenti.
- Migliorate l’ottimizzazione generale grazie alla funzione di minificazione del codice che è integrata nel cruscotto di MyKinsta.
- Ottimizzate le vostre immagini. Riducetele alle loro dimensioni più piccole e usate un formato appropriato per minimizzare le dimensioni dei file. Assicuratevi che qualsiasi immagine nel blocco di contenuto più grande sia richiesta il prima possibile; un pre-caricamento potrebbe aiutare.
- Caricate le immagini con la tecnica del lazy-loading aggiungendo un attributo
loading="lazy". Aggiungete attributi di larghezza e altezza per assicurare che venga riservato lo spazio appropriato nella pagina prima che l’immagine completi il caricamento. - Minimizzate le richieste di terze parti e considerate di spostare le risorse sul vostro dominio primario per evitare ricerche estranee sul DNS.
- Riducete al minimo il numero e la dimensione dei file richiesti, specialmente all’inizio del vostro HTML.
- Assicuratevi di caricare solo i web font richiesti. Passate ai font web-safe per massimizzare le prestazioni.
- Rimuovete i file JavaScript e CSS inutilizzati.
- Concatenate e minimizzate i vostri file JavaScript e CSS.
- Evitate le dichiarazioni CSS @import perché bloccano il rendering e caricano gli stili in serie.
- Evitate la codifica Base64 perché aumenta le dimensioni dei file e richiede un’elaborazione aggiuntiva.
- Considerate i CSS critici in linea. Incorporate il CSS essenziale “above-the-fold” in un blocco
<link>all’inizio della pagina, poi caricate altri fogli di stile in modo asincrono. - Usate JavaScript asincrono, differito o con modulo ES per eseguire gli script in un secondo momento. Eseguite processi JavaScript di lunga durata in un service worker.
First Input Delay (FID)
Il First Input Delay misura la reattività della vostra pagina. In sostanza, quanto velocemente risponde alle azioni dell’utente come clic, tap o scrolling?
La metrica FID è calcolata come il tempo tra l’interazione dell’utente e l’elaborazione della sua richiesta da parte del browser. Non misura il tempo per eseguire la funzione di gestione, che in genere elabora l’input e aggiorna il DOM.
Le pagine con un tempo FID di 100 millisecondi o meno sono considerate buone (verde). Le pagine che superano i 300 millisecondi sono considerate scarse (rosso):
Strumenti di Analisi del First Input Delay
Il First Input Delay è impossibile da simulare perché può essere misurato solo quando la pagina viene servita a un utente reale che interagisce con la pagina. Il risultato dipende quindi dalla velocità e dalle capacità del processore di ogni dispositivo.
Il FID non è calcolato nel pannello DevTools Lighthouse o in PageSpeed Insights. Tuttavia, può determinare il Tempo Totale di Blocco (Total Blocking Time o TBT). Questa è un’approssimazione ragionevole per il First Input Delay. Misura la differenza di tempo tra:
- Il First Contentful Paint (FCP), o il tempo in cui il contenuto della pagina inizia il rendering, e
- Il Time to Interactive (TTI), cioè il tempo in cui la pagina può rispondere all’input dell’utente. Il TTI viene presunto quando non c’è nessun compito di lunga durata attivo e rimangono da completare meno di tre richieste HTTP.
L’estensione Web Vitals per Google Chrome può anche mostrare una metrica FID dopo aver interagito con la pagina tramite scroll o clic. Fate clic sull’icona dell’estensione per rivelare maggiori informazioni:
Come LCP, il Chrome User Experience Report vi permette di interrogare le statistiche FID reali registrate in diversi paesi, connessioni e dispositivi per un URL specifico.
La libreria JavaScript web-vitals può anche calcolare le metriche FID per gli utenti reali sul vostro sito live. Potete aggiungere il seguente script al vostro <head> HTML per emettere le metriche FID su una funzione di callback:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Cause Comuni di Punteggi per il First Input Delay
Scarsi punteggi FID e TBT sono solitamente causati da codice lato client che occupa il processore, come per esempio:
- Quantità significative di CSS e JavaScript che bloccano il rendering, che fermano il caricamento della pagina mentre il codice viene scaricato e analizzato
- Script grandi e ad alta intensità di processo che vengono eseguiti immediatamente quando la pagina viene caricata
- Compiti JavaScript di lunga durata o scarsamente ottimizzati
Per impostazione predefinita, i browser funzionano su un singolo thread, che può elaborare solo un compito alla volta. Se una funzione JavaScript impiega un secondo per essere eseguita, tutti gli altri processi di rendering sono bloccati durante quel secondo. La pagina non può reagire all’input dell’utente, aggiornare il DOM, mostrare animazioni e così via. Anche le animazioni GIF possono essere bloccate nei vecchi browser.
Come Migliorare i Punteggi di First Input Delay
Un controllo JavaScript lato client può identificare i problemi, ma generalmente si tratta di rimuovere il codice ridondante e di assicurare che i compiti vengano eseguiti rapidamente.
I seguenti consigli vi aiuteranno a raggiungere un miglior punteggio FID:
- Generate e memorizzate in cache quanto più contenuto HTML statico possibile sul server. Cercate di non fare affidamento su framework JavaScript lato client per rendere lo stesso HTML per chiunque.
- Assicuratevi che il browser possa memorizzare i file nella cache in modo efficace. Impostate gli hash appropriati Expires, Last-Modified, e/o ETag nell’intestazione HTTP, in modo che i file non vengano richiesti di nuovo.
- Adottate tecniche di miglioramento progressivo, in modo che l’interfaccia sia utilizzabile in HTML e CSS prima che venga eseguito il JavaScript.
- Rimuovete i file JavaScript e CSS inutilizzati.
- Concatenate e minimizzate i vostri file JavaScript e CSS.
- Evitate l’uso eccessivo di costose proprietà CSS come box-shadow e filter.
- Usate JavaScript asincrono, differito o con modulo ES per eseguire gli script in un secondo momento.
- Riducete al minimo le richieste JavaScript di terze parti per l’analisi, i widget dei social media, i forum di discussione, ecc. Questi possono arrivare rapidamente a diversi megabyte di JavaScript.
- Caricate con lazy-loading i componenti JavaScript su richiesta, per esempio i widget della chat, i lettori video, ecc.
- Ritardate il caricamento degli script meno critici come gli strumenti di analisi, le pubblicità e i social media.
- Suddividete i compiti JavaScript di lunga durata in una serie di lavori più piccoli che vengono eseguiti dopo un breve ritardo requestIdleCallback, setTimeout, o requestAnimationFrame.
- Considerate l’esecuzione di processi JavaScript di lunga durata in un web worker, che utilizza un thread in background.
Cumulative Layout Shift (CLS)
Il CLS misura la stabilità visiva della pagina. In sostanza, il contenuto della pagina si muove o salta all’improvviso, soprattutto durante il caricamento iniziale?
Il CLS calcola il punteggio in funzione degli elementi che si muovono senza preavviso o interazione dell’utente. Probabilmente vi è capitato di sperimentarlo leggendo un articolo su un dispositivo mobile: il testo salta fuori campo e voi perdete il filo. Nei casi peggiori potreste finire per fare clic su un link sbagliato.
I problemi di CLS sono più evidenti quando una grande immagine o una pubblicità si carica sopra la posizione di scorrimento attuale e uno spazio ad altezza zero cresce all’improvviso di diverse centinaia di pixel.
I punteggi Cumulative Layout Shift sono calcolati moltiplicando insieme le seguenti metriche:
- La frazione di impatto: Questa è l’area totale di tutti gli elementi instabili nella finestra, cioè quelli che “salteranno”. Se gli elementi che coprono il 60% della visuale si spostano durante il caricamento della pagina, la frazione di impatto è 0,6. Gli elementi che hanno causato quello spostamento, come un’immagine o una pubblicità, sono considerati stabili perché non si spostano necessariamente dopo essere stati renderizzati.
- La frazione di distanza: Questa è la più grande distanza che si genera dallo spostamento di ogni singolo elemento instabile nella finestra. Se il movimento più ampio avviene su un elemento che si muove da 0,100 a 0,800, lo spostamento è pari a 700 pixel verticali. Se la finestra del dispositivo ha un’altezza di 1.000 px, la frazione di distanza è 700 px / 1000 px = 0,7. Il punteggio del Cumulative Layout Shift è quindi pari a 0,6 x 0,7 = 0,42.
Google ha apportato delle modifiche alla metrica CLS per adattarsi alle seguenti situazioni:
- Gli spostamenti di layout sono raggruppati in “sessioni” che durano cinque secondi ma si chiudono dopo un secondo se non si verificano ulteriori spostamenti di layout. Se si verificano due o più spostamenti entro un secondo, i loro punteggi vengono aggiunti.
- Gli spostamenti di layout non vengono registrati per 500 ms dopo l’interazione dell’utente, come un clic. In alcuni casi, questo innesca gli aggiornamenti del DOM (per esempio l’apertura di un menu, la visualizzazione di un messaggio di errore, la visualizzazione di una finestra di dialogo modale, ecc.)
- Le applicazioni a pagina singola che rimangono aperte per periodi più lunghi ed effettuano numerosi aggiornamenti del DOM non sono influenzate negativamente.
Le pagine che hanno un punteggio CLS di 0,1 o meno sono considerate buone (verde). Le pagine che superano 0,25 sono considerate scarse (rosso):
Strumenti di Analisi del Cumulative Layout Shift
Le metriche CLS sono calcolate nel pannello DevTools di Lighthouse, in PageSpeed Insights e negli strumenti web.dev Measure:
Anche l’estensione Web Vitals di Google Chrome mostra la metrica CLS:
Come già visto per il LCP e il FID, il Chrome User Experience Report vi permette di interrogare le statistiche CLS reali registrate in diversi Paesi, connessioni e dispositivi per un URL specifico.
Anche la libreria JavaScript web-vitals può calcolare le metriche CLS per gli utenti reali sul vostro sito live, proprio come fa con LCP e FID. Il seguente script potrebbe essere aggiunto al vostro <head> HTML per emettere le metriche CLS su una funzione di callback
:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Cause Comuni di Punteggi Bassi per il Cumulative Layout Shift
I bassi punteggi di CLS sono di solito causati da risorse di pagina che si caricano lentamente e da elementi DOM dinamici o non dimensionati:
- Lo spazio nella pagina non è riservato a immagini, iframes, pubblicità, ecc.
- Il contenuto viene iniettato dinamicamente nel DOM, di solito dopo una richiesta di rete per pubblicità, widget dei social media, ecc.
- Il caricamento di font web causa un evidente Flash of Invisible Text (FOIT) o Flash of Unstyled Text (FOUT).
Come Migliorare i Punteggi di Cumulative Layout Shift
Un controllo lato client può identificare i problemi, ma generalmente si tratta di assicurare che lo spazio sia riservato al contenuto prima che venga scaricato. I suggerimenti per l’ottimizzazione del server suggeriti per il Largest Contentful Paint offrono qualche beneficio, ma sono possibili ulteriori miglioramenti:
- Aggiungete attributi di larghezza e altezza ai tag HTML
<img>e<iframe>o usate la nuova proprietà CSS aspect-ratio per assicurarvi che lo spazio appropriato sia riservato sulla pagina prima del download delle risorse. - Impostate dimensioni appropriate per gli elementi contenitore che racchiudono contenuti di terze parti che si caricano più lentamente, come pubblicità e widget.
- Assicuratevi che le immagini e le altre risorse che appaiono in cima alla pagina siano richieste il prima possibile; un pre-caricamento potrebbe essere utile.
- Riducete al minimo l’utilizzo di font web e considerate l’utilizzo di font OS comunemente disponibili, quando possibile.
- Caricate i web font e impostate il font-display CSS su opzionale o swap. Meglio usare un font di fallback di dimensioni simili per minimizzare lo spostamento del layout.
- Evitate di inserire elementi verso la parte superiore della pagina a meno che non rispondano a un’azione dell’utente come un clic.
- Assicuratevi che le interazioni dell’utente siano complete entro 500 millisecondi dall’attivazione dell’input.
- Usate la trasformazione CSS e l’opacità per animazioni più efficienti che non incorrono in un ri-layout.
- Considerate i CSS critici inline. Incorporate il CSS essenziale “above-the-fold” in un blocco
<link>all’inizio della pagina, poi caricate altri fogli di stile in modo asincrono. - Dove necessario, considerate il Containment, una nuova caratteristica CSS che vi permette di identificare i sottoinsiemi isolati di una pagina. Il browser può ottimizzare l’elaborazione rendendo – o non rendendo – specifici blocchi di contenuto DOM.
Riepilogo
Chi si occupa di sviluppo non sono sempre vuole ballare al ritmo di Google. Eppure l’azienda ha un potere considerevole e piccoli aggiornamenti del motore di ricerca possono influenzare negativamente la produttività e la redditività delle attività sul web.
Detto questo, i Core Web Vitals adottano un approccio “carota” piuttosto che “bastone”. Siti ben ottimizzati e utilizzabili che rinunciano a schemi oscuri hanno maggiori possibilità di successo rispetto a siti gonfiati e pieni di pop-up che offrono una scarsa interfaccia utente mobile.
I Core Web Vitals forniscono un modo misurabile per valutare l’esperienza utente che vi aiutano a concentrarvi sui miglioramenti più critici. I cambiamenti ai vostri Vitals potrebbero non aumentare le entrate, ma i vostri utenti saranno più felici e affezionati.
Avete altri consigli per migliorare i Core Web Vitals? Condivideteli nella sezione dei commenti!
Lascia un commento