Diversi mesi di lavoro per migliorare Core Web Vitals sulla home page di Mail.ru hanno portato a un aumento del 60% del 75° percentile in Cumulative Layout Shift (CLS), aumentando il tempo di sessione medio del 2,7% e i tassi di conversione delle sezioni principali di oltre il 10%.
Dove abbiamo iniziato
Mail.ru è uno dei principali servizi email su internet in lingua russa e fa parte dei primi 5 siti in Russia in termini di traffico. Mail.ru è una risorsa importante per molte persone. Riceve diverse centinaia di milioni di visite al mese ed è un portale da cui le persone possono accedere a email, notizie, social media, ricerche su internet e altro ancora.
Mail.ru voleva offrire ai suoi visitatori un'esperienza utente di alta qualità, quindi ha iniziato a lavorare per migliorare Core Web Vitals. Prima di discutere la nostra strategia di ottimizzazione, è necessario prendere nota di alcuni dettagli tecnici della home page di Mail.ru.
Sebbene il progetto fosse stato sviluppato a lungo utilizzando il nostro motore di creazione di modelli interno Fest, abbiamo iniziato a eseguire la migrazione a Svelte 3 nel 2019.
Svelte implementa la reattività in modo da non utilizzare il DOM virtuale, il che lo rende meno dispendioso in termini di risorse. L'approccio di Svelte rimuove le funzioni inutilizzate dai bundle di produzione perché il codice che le implementa non viene generato dal compilatore se le funzioni non vengono utilizzate. Il codice inutilizzato viene rimosso durante la compilazione, con conseguente riduzione delle dimensioni dei bundle. In questo modo, puoi contribuire a ridurre il tempo di blocco totale (TBT) durante l'avvio della pagina.
Monitoraggio delle metriche sul rendimento
Prima di ottimizzare Core Web Vitals, è utile valutare il rendimento sul campo. Prima di Core Web Vitals, nella nostra dashboard interna sul rendimento monitoravamo altre metriche, come First Contentful Paint (FCP).
Il nostro script di raccolta delle metriche è stato modificato per raccogliere i Core Web Vitals e trasmetterli alla nostra dashboard sul rendimento per la visualizzazione. In linea con i consigli di Google, il nostro script utilizza l'API PerformanceObserver per ottenere le metriche, che fanno parte della "piattaforma" frontend universale all'interno di Mail.ru.
La dashboard mostrava le seguenti metriche per gli utenti (valori medi per la settimana dal 15 al 21 marzo 2021):
| Nome del gruppo di metriche | Segnali web essenziali | Altri Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Nome metrica | LCP | FID | CLS | FCP | TBT | TTI | |
| Percentuale di utenti in conformità con le soglie dei Core Web Vitals | molto | 52% | 92% | 33% | 35% | 42% | 43% |
| needs-improvement | 19% | 5% | 23% | 38% | 16% | 25% | |
| scadente | 29% | 3% | 44% | 27% | 42% | 32% | |
Migliorare i Core Web Vitals
Sebbene esistano molte indicazioni per migliorare Core Web Vitals, ogni progetto presenta sfide uniche. Per la home page di Mail.ru sono state identificate le seguenti opportunità:
- Implementazione di segnaposto per gli annunci banner per ridurre il CLS.
- Utilizza il rendering lato server (SSR) per ridurre il Largest Contentful Paint (LCP).
- Suddivisione del codice per ridurre LCP e First Input Delay (FID).
Skeleton per il miglioramento del CLS
Il CLS era una delle metriche sul campo con il rendimento peggiore per la home page di Mail.ru. La profilazione successiva di questa pagina nel riquadro Prestazioni di DevTools di Chrome ha rivelato che il problema era causato dagli annunci. Per migliorare la stabilità del layout, il nostro team ha deciso di utilizzare i segnaposto per riservare spazio per gli annunci prima del loro caricamento.
Quando implementi i segnaposto, il primo passaggio consiste nel determinare le dimensioni dei contenuti che li sostituiranno. Fortunatamente, la versione desktop della home page di Mail.ru ha dimensioni degli annunci rigorosamente documentate. Dopo aver parlato con il team di progettazione, sono stati utilizzati scheletri dell'interfaccia utente animati in SVG come segnaposto perché riducono il tempo di caricamento percepito dei contenuti.
Il ritorno di SSR
Per facilitare la transizione da Fest a Svelte, abbiamo riscritto in modo incrementale il progetto esistente anziché ricominciare da capo. Entro marzo 2021, abbiamo eseguito la migrazione della maggior parte del frontend a Svelte e abbiamo infine implementato SSR nella nostra applicazione di produzione dopo aver valutato e risolto i problemi di prestazioni del backend.
Dopo aver implementato l'SSR, il team ha scoperto la causa della regressione del CLS, inizialmente passata inosservata: la sezione delle notizie non è stata inserita al momento del rendering dei primi contenuti della pagina. Si è verificato un ritardo tra la visualizzazione iniziale del markup della pagina fornito dal server e l'inserimento della sezione di notizie sul client. Questo comportamento ha comportato uno spostamento dello scheletro dell'annuncio, che ha peggiorato il CLS.
Sebbene DevTools di Chrome mostrasse eventi di spostamento del layout, inizialmente non siamo riusciti a trovare il motivo. Anche se il problema non era l'SSR, questo ha contribuito a scoprire la soluzione in un secondo momento. La correzione del codice responsabile del ritardo di visualizzazione ha migliorato la stabilità del layout del componente delle notizie.
Un altro effetto che l'SSR può avere sul CLS è il movimento dei componenti prima e dopo l'idratazione, che può portare a ulteriori cambiamenti di layout. Abbiamo riscontrato questo problema in particolare nella versione mobile e abbiamo dovuto prestare particolare attenzione al markup dei componenti idratati. Una buona soluzione a questo problema è stata trasferire il più possibile la logica di visualizzazione da JavaScript a CSS, se possibile.
Suddivisione del codice e polyfill inutilizzati
Per migliorare la velocità di caricamento percepita della pagina, è stato necessario ridurre i valori LCP e FID. Un modo per farlo è tramite la suddivisione del codice. Oltre alla home page di Mail.ru, il nostro team sta sviluppando un widget per la navigazione nel portale. Al momento è integrato in molti dei progetti della nostra azienda.
Per motivi storici, il widget viene inserito all'inizio della pagina come script di caricamento sincrono. La quota di polyfill in questo script è aumentata nel tempo. Per limitare gli effetti negativi sul rendimento del caricamento di questi polyfill, abbiamo implementato la suddivisione del codice sia per i browser moderni che per quelli precedenti.
Abbiamo deciso di non utilizzare il pattern module/nomodule per il caricamento di bundle JavaScript per browser moderni o precedenti, in quanto l'attributo type="module" dell'elemento <script> non aveva come target browser sufficientemente moderni per le nostre esigenze. Per risolvere il problema, Mail.ru utilizza uno strumento interno per identificare le versioni moderne dei browser sul backend e può adattarsi di conseguenza a questi browser.
Una volta che è stato possibile identificare i browser nel backend, abbiamo implementato la suddivisione del codice per i browser moderni e legacy. Il risultato è stato una riduzione del 43,3% delle dimensioni del widget JavaScript caricato in modo sincrono per i browser moderni. Questa pratica è stata applicata anche ad altri script del portale.
Oltre a ridurre le dimensioni del bundle e ad avere effetti positivi sui Core Web Vitals, la suddivisione del codice migliora anche l'esperienza dello sviluppatore. Solo il 3,5% dei nostri utenti utilizza browser legacy e questa percentuale è in calo, pertanto l'implementazione della suddivisione del codice ha consentito ai nostri sviluppatori di utilizzare le API browser più recenti senza introdurre il bloat dei polyfill necessario per tutti gli utenti dei browser legacy.
Risultati
Dopo l'ottimizzazione, abbiamo osservato i valori medi per la settimana dal 24 al 30 maggio 2021 nei nostri dati sul campo:
| Nome del gruppo di metriche | Segnali web essenziali | Altri Web Vitals | |||||
|---|---|---|---|---|---|---|---|
| Nome metrica | LCP | FID | CLS | FCP | TBT | TTI | |
| Percentuale di utenti in conformità con le soglie dei Core Web Vitals | molto | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 18% | 4% | 3% | 34% | 17% | 24% | |
| scadente | 24% | 3% | 4% | 23% | 34% | 25% | |
I grafici seguenti mostrano le variazioni dei valori delle metriche sul rendimento delle pagine web in base alla "Piattaforma". Prendi nota delle due date importanti sui grafici:
- 23 marzo 2021: rilascio dell'iterazione con le sezioni dell'ultima pagina migrate a Svelte.
- 19 aprile 2021: rilascio dell'iterazione con SSR restituito e layout modificato per correggere le regressioni CLS.
La diminuzione dei valori dal 1° al 10 maggio è dovuta alle festività di maggio in Russia.
I risultati ottenuti utilizzando la "piattaforma" sono in linea con la crescita dei valori delle metriche nel Report sull'esperienza utente di Chrome (CrUX).
Un confronto dei valori medi della durata della sessione utente una settimana prima dell'implementazione dei miglioramenti iniziali e una settimana dopo l'implementazione mostra una crescita del 2,7%. Inoltre, si registra un aumento significativo delle conversioni nella maggior parte delle sezioni della pagina. In particolare, le conversioni all'app email Mail.ru sono aumentate dell'11,6%, mentre quelle alla sezione delle notizie sono aumentate del 13,5%.
181%
Aumento della quota della soglia CLS buona
2,7%
Durata media della sessione più elevata
13,5%
Aumento del tasso di conversione della sezione delle notizie
Il risultato più inaspettato che abbiamo ottenuto è stato un aumento del 17,4% della percentuale di clic (CTR) del banner di marketing (il tempo di rendering è stato ridotto in modo significativo con l'introduzione dei tag SSR e di precaricamento).
Dopo aver analizzato le altre sezioni della pagina, abbiamo notato un miglioramento significativo delle prestazioni nella maggior parte di esse. Anche per sezioni come Meteo e Coronavirus, che non sono fondamentali nella nostra pagina, abbiamo registrato un aumento delle conversioni rispettivamente del 9,6% e del 9,5%.
Conclusione
Migliorare il rendimento è un compito impegnativo in quanto il lavoro necessario potrebbe richiedere molto tempo. Devi monitorare regolarmente le variazioni delle metriche nel tempo e assicurarti che tutte le nuove funzionalità del prodotto non causino regressioni in Core Web Vitals. Per raggiungere questo obiettivo, monitoriamo le modifiche ai Core Web Vitals nel nostro budget di rendimento.
Soprattutto, abbiamo sottolineato l'importanza di Core Web Vitals a tutti i membri del nostro team di prodotto, da manager e designer a tester e QA. Ogni membro del team deve conoscere le metriche sul rendimento ed essere in grado di migliorarle. Inoltre, includiamo gli obiettivi di ottimizzazione del rendimento nei nostri processi aziendali con una cadenza regolare. Offrire un'esperienza utente di alta qualità è possibile solo grazie allo sforzo congiunto di tutti i membri del team.