 Buongiorno. I miei nome è Gilberto e lavoro come Web Ecosystem Consultante in Google. Oggi sono qui per parlarvi di Core Web Vitas, percorrendo una breve introduzione sul programma per poi descrivere le metriche e consigli utili su come ottimizzare questi indicatori. Core Web Vitas è un programma promosso da Google che descrive quali sono gli indicatori ottimali per offrire una buona esperienza utente sul Web. A partire da metà giugno 2021, Google Search commercerà ad integrare in maniera graduale i segnali di Page Experience in Search Ranking. Bene, ma cosa sono questi Core Web Vitas? Andiamo subito a scoprirlo. Le metriche che fanno parte di Core Web Vitas sono 3. Larges Contra Full Paint, First Input Delay e Cumulative Layout Shift. La metrica identificata per misurare al meglio la percenzione di caricamento della pagina è Larges Contra Full Paint. Un valore ottimale di Larges Contra Full Paint dovrebbe essere uguale o minore di 2.5 secondi. Naturalmente è importante non solo poter vedere il contenuto, ma anche poterci interagire. E per questo aspetto abbiamo identificato la metrica First Input Delay. Un valore ottimale di First Input Delay si attesta sotto i 100 mili secondi. L'ultimo aspetto che vogliamo coprire ha l'obiettivo di misurare quanto un sito Web è in grado di offrire un'esperienza stabile nel tempo, priva di salte di contenuto o movimenti inaspettati da parte dell'utente. La metrica che ha la responsabilità di misurare questo aspetto è il Comulative Layout Shift e suggeriamo di ottenere un valore uguale o minore di 0.10. È consigliabile raggiungere queste solle almeno sul 75% delle navigazioni utente, sia desktop che mobile. In questo modo sarete certi di aver migliorato le prestazioni su una percentuale significativa del traffico reale del vostro sito. Ora che abbiamo introdotto questa metrica andiamo ad escriverne meglio il loro funzionamento per poi coprire le problematiche più comuni. Largest Contentful Paint misura quando una pagina Web riesce a mostrare l'utente l'elemento più grande nella viewport dello schermo. Possono esistere più elementi Largest Contentful Paint in una pagina, ma quello che conta di più è l'ultima di questi. Elementi che determinano il tempo di Largest Contentful Paint possono essere dei nodi di testo, delle immagini o dei video. Le cause più comuni di un Largest Contentful Paint alto sono un elevato back in time o TTFB, contenuti render blocking come JavaScript e CSS, immagini o risorse con tempi di caricamento particolarmente lunghi e in ultimo i clients and rendering può rendere più difficile a raggiungere un buon Largest Contentful Paint. In questa immagine potete osservare come tutti i componenti hanno un ruolo chiave nella determinazione del Largest Contentful Paint, in questo caso identificato dall'immagine. Se il back in time è elevato la pagina ci mette molto tempo per ottenere l'HTML. Oltre a questo, se c'è del codice render blocking in eccesso come JavaScript e CSS, questi possono ritardare il First Contentful Paint. E il First Contentful Paint può agire proprio come collo di bottiglia per un buon Largest Contentful Paint da immagini. Infatti la richiesta dell'immagine non può partire prima di quando il Dom ne scopre la sua esistenza. Per finire, è molto importante che l'immagine si è ottimizzata in dimensioni e qualità, per il dispositivo al quale è indirizzato. Altrimenti il content download time dell'immagine risulterebbe elevato e di conseguenza anche il Largest Contentful Paint. La metrica First Input delay misura quanto il JavaScript può interferire con l'esperienza utente. Causando un ritardo tra il tempo della prima interazione utente è di momento in cui il browser è in grado di rispondere all'input. Le cause più comuni di un First Input delay alto sono la presenza di JavaScript task elevati, quindi sopra i 50 mili secondi, tempi di esecuzione JavaScript elevati o la presenza di molte librerie JavaScript decisivamente grandi o pesanti, come anche il codice render blocking. È molto importante comprendere quali librerie o componenti JavaScript sono presenti in pagina e puntare a caricare solo lo stretto necessario in caso di pagine con problematica FID evidenti. La metrica Cumulative Layout Shift misura i movimenti imprevisti di contenuto che avvengono durante l'intero utilizzo di una pagina web. Ogni volta che un elemento cambia la sua posizione iniziale senza un'interazione utente questo può causare un incremento del punteggio di CLS. Recentemente abbiamo migliorato questa metrica in modo da non conteggiare eccessivamente salti di contenuto simili che si ripetano nel tempo. Ora i Layout Shift sono raggruppati all'interno di diverse finestre temporali, ciascuna della durata di 5 secondi massimo ed ognuna di queste finestre ha un suo punteggio. Il punteggio finale della pagina non è più una somma di tutti i Layout Shift come in precedenza ma la risultante della finestre di tempo con il punteggio più alto. Le cause più comune di Cumulative Layout Shift sono immagini prive di dimensione, infatti è importante definire sempre gli attributi width e height alle immagini. Così facendo il browser riceverà per voi lo spazio necessario per mostrare l'immagine ed evitando il Layout Shift risultante. Annunci pubblicitari embed o iframes possono essere causa del Layout Shift. È importante riservare sufficiente spazio per questi elementi. Anche contenuti in età te dinamicamente come messaggi promozionali avvisi o simili sono un altro caso di Layout Shift facilmente risolvibile riservando spazio per gli stessi a render time. Per ultimo anche fonts personalizzate possono causare Layout Shift. Nella slide si può notare come un immagine senza attributi width e height definiti non permette al browser di riservare lo spazio spingendo di conseguenza il testo in basso quando quest'ultima viene caricata. Stessa cosa per i contenuti di terze parti quali annunci pubblicitari ma la soluzione è apportata di mano. È sufficiente riservare un'altezza minima di salvaguardia per andare a minimizzare se non annullare completamente il Layout Shift. In questo modo tutto il contenuto nella pagina ha un suo posto dove l'utente potrà meglio percepire quali contenuti andrà a visualizzare e dallo stesso tempo come interagirci. Ora che abbiamo introdotto le metriche passiamo gli strumenti forniti da Google per misurare al meglio questi indicatori. Prima di tutto è importante conoscere la differenza tra dati di laboratorio e traffico reale. Non tutte le metriche sono ugualmente misurabili in trambi gli ambienti e possono differire molto in alcuni casi. Per esempio in Page Speed Insights trovate sia il performance core, calcolato solamente sul test di laboratorio eseguito attraverso Lighthouse come anche i dati di traffico reale e questi sono prevenenti da Chrome User Experience Report. Chrome User Experience Report vi permette di misurare la performance su traffico reale Chrome del vostro sito nel tempo. I dati di Chrome User Experience Report sono disponibili in Page Speed Insights sia a livello di URL che è origin, ma sono anche disponibili su BigQuery o attraverso la Crux API. Invece per poter lavorare in locale ed ottenere un miglioramento sulle metriche di laboratorio, i vostri leati sono Lighthouse, Chrome DevTools e WebVitals Chrome Extension. Tutti questi strumenti vi permettono di individuare facilmente quali metriche causano problematiche su metriche come large sconti full paint, first tempo delay e cumulative layout shift. Per finire, l'ultimo strumento dove potete osservare di nuovo i dati di Chrome User Experience Report, in maniera molto più dettagliata, si trova proprio in Search Console. Dentro Search Console potete trovare il Core Web Vitals Report ma anche il Page Experience Report che vi permette di monitorare quanti URL soddisfano tutti gli indicatori di Page Experience. Tutte le informazioni discusse sono reperibili su web.dev in rispettivi articoli sulle metriche come anche quelli sulle backstractices. Grazie a tutti e ciao!