Diversi mesi di lavoro per migliorare Core Web Vitals sulla home page di Mail.ru hanno portato a un aumento del 60% nel 75° percentile di Cumulative Layout Shift (CLS), aumentando il tempo medio della sessione del 2,7% e i tassi di conversione delle sezioni principali di oltre il 10%.
Da dove abbiamo iniziato
Mail.ru è uno dei principali servizi di posta elettronica nell'Internet di lingua russa ed è tra i 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 abbiamo iniziato a lavorare per migliorare i Segnali web essenziali. Prima di discutere della nostra strategia di ottimizzazione, è opportuno segnare alcuni dettagli tecnici sulla home page di Mail.ru.
Sebbene il progetto sia stato sviluppato da molto tempo utilizzando il nostro motore di modelli interno Fest, nel 2019 abbiamo iniziato a migrare a Svelte 3.
Svelte implementa la reattività in un modo che non utilizza il DOM virtuale, il che riduce l'utilizzo 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, generando bundle più piccoli. In questo modo potresti ridurre il tempo di blocco totale (TBT) durante l'avvio della pagina.
Monitoraggio delle metriche sul rendimento
Prima di ottimizzare i Segnali web essenziali, è utile valutare le prestazioni sul campo. Prima di Core Web Vitals, monitoravamo altre metriche, come First Contentful Paint (FCP), nella nostra dashboard interna sul rendimento.
Il nostro script di raccolta delle metriche è stato modificato per raccogliere i Segnali web essenziali e trasmetterli alla nostra dashboard delle prestazioni per la visualizzazione. In linea con i consigli di Google, il nostro script utilizza l'API PerformanceObservationr per ottenere le metriche, che fanno parte della piattaforma frontend universale all'interno di Mail.ru.
La dashboard mostrava le seguenti metriche relative agli utenti (valori medi per la settimana dal 15 al 21 marzo 2021):
| Nome gruppo metriche | Segnali web essenziali | Altri Segnali web | |||||
|---|---|---|---|---|---|---|---|
| Nome metrica | LCP | FID | CLS | FCP | Da confermare | TTI | |
| Percentuale di utenti in base alle soglie dei Segnali web essenziali | buona | 52% | 92% | 33% | 35% | 42% | 43% |
| ha bisogno di miglioramenti | 19% | 5% | 23% | 38% | 16% | 25% | |
| scadente | 29% | 3% | 44% | 27% | 42% | 32% | |
Migliorare i Segnali web essenziali
Nonostante esistano molte indicazioni per migliorare i Segnali web essenziali, ogni progetto pone delle sfide specifiche. Per la home page di Mail.ru, sono state individuate le seguenti opportunità:
- Implementazione dei segnaposto per i banner degli annunci al fine di ridurre la CLS.
- Utilizzo del rendering lato server (SSR) per ridurre la Largest Contentful Paint (LCP).
- Suddivisione del codice per ridurre LCP e First Input Delay (FID).
Scheletri per il miglioramento della metrica CLS
Il CLS è stato una delle metriche sul campo con il rendimento peggiore per la home page di Mail.ru. La successiva profilazione 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 prenotare spazio per gli annunci prima che vengano caricati.
Quando implementi i segnaposto, il primo passaggio consiste nel determinare le dimensioni dei contenuti che li sostituiranno. Fortunatamente, le dimensioni degli annunci della versione desktop della home page di Mail.ru sono rigorosamente documentate. Dopo aver parlato con il team di progettazione, gli scheletri di UI animati in formato SVG sono stati utilizzati come segnaposto in quanto riducono il tempo di caricamento percepito dei contenuti.
Il ritorno di SSR
Per facilitare la transizione da Festival a Svelte, abbiamo riscritto in modo incrementale il progetto esistente invece di ricominciare da capo. A marzo 2021 abbiamo eseguito la migrazione della maggior parte del frontend a Svelte e alla fine abbiamo introdotto SSR nella nostra applicazione di produzione dopo aver valutato e risolto i problemi di prestazioni dei backend.
Dopo aver implementato SSR, il team ha scoperto la causa della regressione CLS che inizialmente è passata inosservata: la sezione di 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 portato a uno spostamento dello scheletro pubblicitario, che ha peggiorato la CLS.
Anche se DevTools di Chrome mostrava gli eventi di variazione del layout, all'inizio non siamo riusciti a trovare il motivo. Sebbene la SSR in sé non fosse il problema, è stato utile per trovare la soluzione in seguito. La correzione del codice responsabile del ritardo di visualizzazione ha migliorato la stabilità del layout del componente di notizie.
Un altro effetto che la SSR può avere sulla CLS è il movimento dei componenti prima e dopo l'idratazione, che può portare a ulteriori variazioni della struttura. Abbiamo riscontrato questo problema in particolare nella versione per dispositivi mobili e richiedeva particolare attenzione al markup del componente idratato. Una buona soluzione a questo problema era trasferire la maggior quantità di logica di visualizzazione da JavaScript a CSS, ove possibile.
Suddivisione del codice e polyfill non utilizzati
Per migliorare la velocità percepita di caricamento della pagina, è stato necessario lavorare per diminuire i valori LCP e FID. Un modo per raggiungere questo obiettivo è tramite la suddivisione del codice. Oltre alla home page di Mail.ru, il nostro team sta sviluppando un widget per la navigazione nel portale. Attualmente è incorporato 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 è cresciuta nel tempo. Per limitare gli effetti negativi delle prestazioni del caricamento di questi polyfill, abbiamo implementato la suddivisione del codice per i browser moderni e precedenti.
Abbiamo deciso di non utilizzare il pattern module/nomodule per caricare bundle JavaScript per i browser moderni o precedenti, poiché l'attributo type="module" dell'elemento <script> non era indirizzato a browser abbastanza moderni per le nostre esigenze. Per risolvere questo problema, Mail.ru utilizza uno strumento interno per identificare le versioni moderne del browser nel backend e può adattarsi a questi browser di conseguenza.
Una volta identificati 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 alla riduzione delle dimensioni dei bundle e agli effetti positivi sui Segnali web essenziali, la suddivisione del codice migliora anche l'esperienza degli sviluppatori. Solo il 3,5% dei nostri utenti utilizza browser legacy e questa quota è in una tendenza al ribasso, quindi l'implementazione della suddivisione del codice ha permesso ai nostri sviluppatori di utilizzare le API browser più recenti senza introdurre il polyfill necessario per i browser legacy a tutti gli utenti.
Risultati
Dopo lo sforzo di ottimizzazione, abbiamo osservato i valori medi per la settimana del 24-30 maggio 2021 nei dati dei nostri campi:
| Nome gruppo metriche | Segnali web essenziali | Altri Segnali web | |||||
|---|---|---|---|---|---|---|---|
| Nome metrica | LCP | FID | CLS | FCP | Da confermare | TTI | |
| Percentuale di utenti in base alle soglie dei Segnali web essenziali | buona | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| ha bisogno di miglioramenti | 18% | 4% | 3% | 34% | 17% | 24% | |
| scadente | 24% | 3% | 4% | 23% | 34% | 25% | |
I grafici seguenti mostrano le variazioni nei valori delle metriche di rendimento delle pagine web in base alla "Piattaforma". Annota le due date importanti sui grafici:
- 23 marzo 2021: è stata eseguita la migrazione del rilascio dell'iterazione con le sezioni dell'ultima pagina in Svelte;
- 19 aprile 2021: rilascio dell'iterazione con SSR restituito e layout modificati 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 della durata media delle sessioni utente una settimana prima dell'implementazione dei miglioramenti iniziali e una settimana dopo l'implementazione mostra una crescita del 2,7%. Inoltre, si è verificato un aumento complessivo significativo delle conversioni nella maggior parte delle sezioni della pagina. In particolare, le conversioni verso l'app email Mail.ru sono aumentate dell'11,6%, mentre la conversione della sezione di notizie è aumentata del 13,5%.
Il 181%
Aumento della quota della soglia CLS buona
2,7%
Durata media della sessione più elevata
13,5%
Aumento del tasso di conversione delle sezioni di notizie
Il risultato più imprevisto che abbiamo ottenuto è stato un aumento del 17,4% della percentuale di clic (CTR) del banner di marketing (il tempo di rendering è stato notevolmente ridotto dall'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 quali Meteo e Coronavirus, che non sono fondamentali nella nostra pagina, notiamo un aumento delle conversioni rispettivamente del 9,6% e del 9,5%.
Conclusione
Migliorare le prestazioni è impegnativo, in quanto il lavoro coinvolto può essere prolungato. Devi monitorare regolarmente i cambiamenti 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 variazioni di Segnali web essenziali nel nostro budget relativo alle prestazioni.
In particolare, abbiamo sottolineato l'importanza dei Segnali web essenziali per tutti i membri del nostro team di prodotto, dai manager e i designer ai tester e al QA. Ogni membro del team deve conoscere le metriche di rendimento ed essere in grado di migliorarle. Incorporiamo regolarmente gli obiettivi di ottimizzazione delle prestazioni nei nostri processi aziendali. Fornire un'esperienza utente di alta qualità è possibile solo grazie alla collaborazione di tutti i membri del team.