L'ottimizzazione di Core Web Vitals sul sito web The Economic Times ha migliorato notevolmente l'esperienza utente e ha ridotto sostanzialmente la frequenza di rimbalzo sull'intero sito web.
Con il miglioramento della velocità di internet di giorno in giorno, gli utenti si aspettano che i siti web rispondano e si comportino più velocemente che mai. The Economic Times gestisce oltre 45 milioni di utenti attivi ogni mese. Ottimizzando per Core Web Vitals in tutto il dominio, nelle pagine AMP e non AMP, siamo riusciti a ridurre notevolmente la frequenza di rimbalzo e a migliorare l'esperienza di lettura.
Misurazione dell'impatto
Ci siamo concentrati su Largest Contentful Paint (LCP) e Cumulative Layout Shift (CLS), in quanto sono gli aspetti più importanti per offrire un'esperienza di lettura ottimale ai nostri utenti. Dopo aver implementato varie correzioni di prestazioni come descritto di seguito, The Economic Times è riuscito a migliorare in modo significativo le metriche dei report sugli esperimenti utente di Chrome (CrUX) in pochi mesi.
Nel complesso, la metrica CLS è migliorata del 250%, passando da 0,25 a 0,09. Nel complesso, l'LCP è migliorato dell'80% da 4,5 a 2,5 secondi.
Inoltre, i valori LCP nell'intervallo "Scadente" sono stati ridotti del 33% da ottobre 2020 a luglio 2021:
Inoltre, i valori CLS nell'intervallo "Scadente" sono stati ridotti del 65% e i valori CLS nell'intervallo "Buono" sono aumentati del 20% nello stesso periodo di tempo:
Il risultato è stato che The Economic Times, che in precedenza non rispettava le soglie dei Segnali web essenziali, ora ha superato le soglie di Segnali web essenziali in tutta la sua origine e ha ridotto la frequenza di rimbalzo del 43% in generale.
Che cos'è la metrica LCP e come l'abbiamo migliorata?
L'elemento più grande è quello più pertinente per migliorare l'esperienza utente e riconoscere la velocità di caricamento. Le metriche sul rendimento come First Contentful Paint (FCP) mostrano solo l'esperienza iniziale di caricamento della pagina. Il valore LCP, invece, segnala il tempo di rendering della sezione più grande di immagini, testo o video visibile all'utente.
Oltre a passare a un provider DNS più veloce e a ottimizzare le immagini, ecco alcune delle tecniche che abbiamo applicato per migliorare l'LCP.
Prima le richieste critiche
Poiché tutti i browser moderni limitano il numero di richieste simultanee, gli sviluppatori devono prima caricare i contenuti critici. Per caricare una pagina web complessa, dobbiamo scaricare asset come elementi di intestazione, CSS, risorse JavaScript, immagine hero, corpo dell'articolo, commenti, altre notizie correlate, piè di pagina e annunci. Abbiamo valutato gli elementi richiesti per la metrica LCP e abbiamo fornito la preferenza di dover caricare prima questi elementi per migliorarlo. Abbiamo inoltre posticipato le chiamate che non facevano parte del rendering iniziale della pagina.
Aspetto del testo
Abbiamo sperimentato la proprietà font-display in quanto influisce sia sulla metrica LCP sia sulla metrica CLS. Abbiamo provato font-display: auto;, poi siamo passati a font-display: swap;. In questo modo, il testo viene visualizzato inizialmente nel carattere migliore corrispondente e disponibile, per poi passare al carattere una volta scaricato. In questo modo, il testo viene visualizzato rapidamente, indipendentemente dalla velocità della rete.
Migliore compressione
Brotli è un algoritmo di compressione alternativo a Gzip e Deflate sviluppato da Google. Abbiamo sostituito i caratteri e gli asset e modificato la compressione del server da Gzip a Brotli per ridurre l'ingombro:
- Le dimensioni dei file JavaScript sono del 15% più piccole rispetto a Gzip.
- Le dimensioni dei file HTML sono del 18% più piccole rispetto a Gzip.
- Le dimensioni dei file CSS e dei caratteri sono del 17% più piccole rispetto a Gzip.
Preconnessione a domini di terze parti
preconnect deve essere usato con cautela, in quanto può comunque richiedere tempo prezioso della CPU e ritardare altre risorse importanti, soprattutto nelle connessioni sicure.
Tuttavia, se è noto che verrà eseguito un recupero di una risorsa su un dominio di terze parti, preconnect è valido. Se questo si verifica solo occasionalmente su un sito web con traffico elevato, preconnect potrebbe attivare lavori TCP e TLS non necessari. Pertanto, dns-prefetch era più adatto per le risorse di terze parti, ad esempio social media, analisi e così via, per eseguire ricerche DNS in anticipo.
Suddividi il codice in blocchi
Nell'intestazione del sito abbiamo caricato solo le risorse che contengono una parte essenziale della logica di business o erano fondamentali per il rendering della pagina above the fold. Inoltre, abbiamo diviso il nostro codice in blocchi con la suddivisione del codice. Questo ci ha aiutato a migliorare ulteriormente la metrica LCP della pagina.
Migliore memorizzazione nella cache
Per tutte le route front-end, abbiamo aggiunto un livello Redis che serviva i modelli dalla cache. In questo modo si riduce il tempo di calcolo sul server e si crea l'intera UI in ogni richiesta, diminuendo l'LCP nelle richieste successive.
Riepilogo degli obiettivi e dei risultati di LCP
Prima di iniziare il progetto di ottimizzazione, il team ha confrontato il punteggio LCP a 4,5 secondi (per il 75° percentile degli utenti, in base ai dati dei campi del report CrUX). Dopo il progetto di ottimizzazione, è stato ridotto a 2,5 secondi.
Che cos'è il CLS e come l'abbiamo migliorato?
Hai mai notato movimenti imprevisti dei contenuti di una pagina durante la navigazione su un sito web? Una delle cause è il caricamento asincrono di contenuti multimediali (immagini, video, annunci e così via) nella pagina con dimensioni sconosciute. Non appena le risorse multimediali vengono caricate, modificano il layout della pagina.
Approfondiremo le misure che abbiamo adottato per migliorare il CLS sul sito web di The Economic Times.
Utilizzare i segnaposto
Abbiamo utilizzato un segnaposto con stile per le unità pubblicitarie e gli elementi multimediali di dimensioni note al fine di evitare variazioni del layout durante il caricamento della libreria di annunci e il rendering degli annunci sulla pagina. In questo modo si eliminano le variazioni del layout riservando spazio per l'annuncio.
Dimensioni del contenitore definite
Abbiamo specificato le dimensioni esplicite per tutte le immagini e i contenitori in modo che il motore del browser non debba calcolare la larghezza e l'altezza degli elementi DOM quando sono disponibili. In questo modo è stato possibile evitare inutili variazioni del layout e operazioni di colorazione extra.
Riepilogo degli obiettivi e dei risultati del CLS
Prima di iniziare il progetto di ottimizzazione, il team ha stabilito un benchmark di 0,25 per il punteggio CLS. Siamo riusciti a ridurlo in modo significativo del 90% fino a 0,09.
Che cos'è First Input Delay (FID) e come lo abbiamo migliorato?
First Input Delay è la metrica che monitora l'adattabilità di un sito web all'input degli utenti. La causa principale di un punteggio FID scadente è un lavoro JavaScript intensivo che mantiene occupato il thread principale del browser, il che può ritardare le interazioni degli utenti. Abbiamo migliorato FID in diversi modi.
Suddividi attività JavaScript lunghe
Le attività lunghe sono attività di almeno 50 millisecondi. Le attività lunghe occupano il thread principale del browser e gli impediscono di rispondere all'input dell'utente. Abbiamo suddiviso le attività a lunga esecuzione in attività più piccole, ove possibile su richiesta dell'utente, il che ha contribuito a ridurre il gonfiore di JavaScript.
Rimanda JavaScript inutilizzato
Abbiamo dato la priorità ai contenuti delle pagine rispetto agli script di terze parti come i dati e le analisi per mantenere la pagina più reattiva. Tuttavia, esistono alcune limitazioni su alcune librerie poiché devono essere caricate nel documento <head> per monitorare con precisione il percorso dell'utente.
Riduci i polyfill
Abbiamo ridotto la nostra dipendenza da alcuni polyfill e librerie, poiché i browser supportano API moderne e meno utenti utilizzano i browser precedenti, come Internet Explorer.
Annunci con caricamento lento
Il caricamento lento degli annunci below the fold ha contribuito a ridurre i tempi di blocco dei thread principali e, di conseguenza, a migliorare il FID.
Riepilogo degli obiettivi e dei risultati del FID
Dagli esperimenti di routine, siamo stati in grado di ridurre il nostro FID da 200 ms a meno di 50 ms oggi.
Prevenzione delle regressioni
The Economics Times prevede di introdurre controlli automatici del rendimento in produzione per evitare regressioni delle prestazioni delle pagine. Il team prevede di valutare Lighthouse-CI per automatizzare i test di laboratorio, al fine di prevenire le regressioni nel ramo di produzione.