Un case study delle modifiche apportate dal team web di YouTube per migliorare le prestazioni, aumentare la percentuale di superamento dei Segnali web essenziali e migliorare le metriche aziendali chiave.
Il team di Chrome spesso parla di "creare un web migliore", ma che cosa significa? Le esperienze web dovrebbero essere veloci, accessibili e utilizzare le funzionalità del dispositivo nel momento in cui gli utenti ne hanno più bisogno. Il dogfooding fa parte della cultura di Google, pertanto il team di Chrome ha collaborato con YouTube per condividere ciò che abbiamo imparato in una nuova serie intitolata "Creazione di un web migliore". Nella prima parte della serie vedremo in che modo YouTube ha creato un'esperienza web più veloce.
Creazione di un web più veloce
In YouTube, il rendimento si riferisce alla velocità con cui video e altri contenuti, come consigli e commenti, vengono caricati sulle pagine web. Il rendimento viene misurato anche in base alla velocità con cui YouTube risponde alle interazioni degli utenti, come la ricerca, il controllo del player, i Mi piace e le condivisioni.
I mercati in crescita, come Brasile, India e Indonesia, sono importanti per il web mobile di YouTube. Poiché molti utenti in queste aree geografiche dispongono di dispositivi più lenti e di una larghezza di banda di rete limitata, garantire un'esperienza rapida e senza interruzioni è un obiettivo fondamentale.
Per offrire un'esperienza inclusiva a tutti gli utenti, YouTube ha deciso di migliorare le metriche sul rendimento come i Segnali web essenziali tramite il caricamento lento e la modernizzazione del codice.
Migliorare i Segnali web essenziali
Per identificare le aree da migliorare, il team di YouTube ha utilizzato il Report sull'esperienza utente di Chrome (CrUX) per scoprire in che modo utenti reali visualizzavano video e pagine dei risultati di ricerca sui dispositivi mobili sul campo. Si è reso conto che le metriche di Core Web Vitals avevano un notevole margine di miglioramento, con una metrica Largest Contentful Paint (LCP), in alcuni casi, con un tempo di 4-6 secondi. Questo valore era sostanzialmente più elevato rispetto all'obiettivo di 2,5 secondi.
Per identificare le aree di miglioramento, si è affidata a Lighthouse per controllare le pagine di visualizzazione di YouTube, rivelando un basso punteggio Lighthouse (lab) con un First Contentful Paint (FCP) di 3,5 secondi e un LCP di 8,5 secondi.
Per ottimizzare FCP e LCP, il team di YouTube ha condotto vari esperimenti con due importanti scoperte.
La prima scoperta è stata la possibilità di migliorare le prestazioni spostando il codice HTML del video player sopra lo script per renderlo interattivo. I test di laboratorio hanno indicato che questo potrebbe migliorare sia FCP che LCP da 4,4 a 1,1 secondi.
La seconda scoperta è che l'LCP prende in considerazione solo le immagini poster dell'elemento
<video>e non i frame dello stream video stesso. YouTube ha tradizionalmente ottimizzato la piattaforma per ottimizzare la velocità prima dell'inizio della riproduzione del video, quindi per migliorare il valore di LCP il team ha iniziato anche a ottimizzare la velocità di pubblicazione dell'immagine poster. Ha provato con alcune varianti di immagini poster e ha scelto quella con il miglior punteggio nei test sugli utenti. Come risultato di questo lavoro, sia FCP che LCP hanno mostrato un netto miglioramento, con un miglioramento dell'LCP sul campo da 4,6 a 2,0 secondi.
Anche se queste ottimizzazioni miglioravano l'LCP, il team ha ritenuto che l'attuale definizione della metrica LCP non venisse acquisita completamente, dal punto di vista dell'utente, quando i "contenuti principali" della pagina erano stati caricati, che è l'obiettivo della metrica LCP.
Per rispondere a queste preoccupazioni, i membri del team di YouTube hanno collaborato con altri membri del team di Chrome per esplorare modi in cui la metrica LCP poteva essere migliorata al fine di affrontare il loro caso d'uso. Dopo aver valutato la fattibilità e l'impatto di alcune opzioni, i team hanno trovato una proposta per prendere in considerazione il tempo di colorazione del primo fotogramma di un elemento video come candidato LCP.
Una volta che questo cambiamento sarà implementato in Chrome, il team di YouTube non vede l'ora di continuare il proprio lavoro di ottimizzazione per l'LCP. Inoltre, la versione aggiornata della metrica indicherà che queste ottimizzazioni avranno un impatto più diretto sulle esperienze degli utenti reali.
Modularizzazione con caricamento lento
Le pagine di YouTube contenevano molti moduli caricati con ansia. Per ottimizzare la modalità di rendering di oltre 50 componenti, il team ha creato un componente per la mappa dei moduli JS che indicava al client quali moduli caricare. Contrassegnando i componenti come lenti, i moduli JS verrebbero caricati in un secondo momento, riducendo il tempo di caricamento iniziale della pagina e la quantità di codice JavaScript inutilizzato inviato al client.
Tuttavia, dopo l'implementazione del caricamento lento, il team ha notato un effetto a cascata che comporta il caricamento dei componenti con caricamento lento e delle loro dipendenze in momenti non ottimali.
Per risolvere il problema, il team ha determinato l'insieme minimo di componenti necessari in una vista e li ha raggruppati in un'unica richiesta di rete. I risultati sono stati una migliore velocità delle pagine, una riduzione dei tempi di analisi di JavaScript e, in ultima analisi, migliori tempi di rendering iniziali.
Gestione dello stato tra i componenti
YouTube stava riscontrando problemi di prestazioni a causa dei controlli del player, in particolare sui dispositivi meno recenti. L'analisi del codice ha mostrato che il player, che consente agli utenti di controllare funzionalità come la velocità di riproduzione e l'avanzamento, era diventato eccessivamente componente nel tempo.
Ogni evento di tocco nella barra di avanzamento ha attivato due ricalcoli di stile aggiuntivi e ha richiesto 21,17 ms durante le esecuzioni di test delle prestazioni in laboratorio. Con l'aggiunta di nuovi controlli nel corso del tempo, il modello di controllo decentralizzato causa spesso dipendenze circolari e perdite di memoria, con un impatto negativo sulle prestazioni della pagina di visualizzazione.
Per risolvere i problemi dovuti al controllo decentralizzato, il team ha aggiornato l'interfaccia utente del player in modo da sincronizzare tutti gli aggiornamenti, mediante il refactoring del player a un componente di primo livello che trasmetteva i dati ai suoi figli. In questo modo è stato garantito un solo ciclo di aggiornamento (rendering) dell'interfaccia utente per ogni modifica dello stato, eliminando gli aggiornamenti concatenati. L'evento touch-move della nuova barra di avanzamento del player non richiede ricalcoli di stile durante l'esecuzione di JavaScript e ora richiede solo il 25% del tempo del precedente player.
Questa modernizzazione del codice ha comportato anche ulteriori miglioramenti delle prestazioni, come un miglioramento dei tempi di caricamento delle visualizzazioni sui vecchi dispositivi, un minor numero di riproduzioni abbandonate e un numero ridotto di errori non irreversibili.
Conclusione
Grazie all'investimento in prestazioni di YouTube, le pagine di visualizzazione si caricano molto più velocemente: il 76% degli URL dei siti web mobile di YouTube ora supera le soglie delle metriche di Core Web Vitals sul campo. Sui computer, l'LCP del lab per la pagina di visualizzazione è stato ridotto da circa 4,6 a 1,6 secondi. Le prestazioni di interazione e rendering del sito, specialmente sul video player di YouTube, registrano fino al 75% di tempo in meno nell'esecuzione di JavaScript rispetto a prima.
I miglioramenti apportati alle prestazioni di YouTube web nel corso dell'ultimo anno hanno anche migliorato le metriche aziendali, tra cui il tempo di visualizzazione e gli utenti attivi giornalieri. Sulla base del successo di questi sforzi, prevediamo di continuare a esplorare altri modi per ottimizzare in futuro.
Nella seconda parte di questa serie, "Creazione di un web accessibile", scoprirai in che modo YouTube ha reso il sito web più accessibile agli utenti di screen reader.
Grazie speciali a Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra e i team di YouTube e Chrome per il loro contributo a questo lavoro.