Nel giro di un paio di mesi, il principale sito web di notizie del Regno Unito è riuscito a migliorare il CLS del 75° percentile del 250%, passando da 0,25 a 0,1.
La sfida della stabilità visiva
Le variazioni del layout possono essere molto dirompenti. Al Telegraph Media Group (TMG) la stabilità visiva è particolarmente importante perché i lettori usano prevalentemente le nostre applicazioni per riprendere le notizie. Se il layout cambia durante la lettura di un articolo, il lettore probabilmente perderà il punto in cui si trovava. Può essere un'esperienza frustrante e fastidiosa.
Da un punto di vista ingegneristico, assicurarsi che le pagine non si spostino e interrompano il lettore può essere difficile, soprattutto quando le aree dell'applicazione vengono caricate in modo asincrono e aggiunte alla pagina in modo dinamico.
In TMG, diversi team contribuiscono al codice lato client:
- Core engineering. Implementare soluzioni di terze parti per potenziare i consigli sui contenuti e i commenti.
- Marketing. Esecuzione di test A/B per valutare l'interazione dei lettori con nuove funzionalità o modifiche.
- Pubblicità. Gestire le richieste di annunci e le pre-offerte pubblicitarie.
- Requisiti redazionali. Incorporamento del codice all'interno di articoli come tweet o video, nonché widget personalizzati (ad esempio, tracker dei casi di coronavirus).
Assicurarsi che ciascuno di questi team non causi la scossa del layout della pagina può essere difficile. Utilizzando la metrica Cumulative Layout Shift per misurare la frequenza con cui si verifica per i nostri lettori, i team hanno ottenuto maggiori informazioni sull'esperienza utente reale e un obiettivo chiaro a cui puntare. In questo modo, il CLS del 75° percentile è migliorato da 0,25 a 0,1 e il bucket di passaggio è aumentato dal 57% al 72%.
Il 250%
Miglioramento del CLS al 75° percentile
15%
Altri utenti con un buon punteggio CLS
Da dove abbiamo iniziato
Utilizzando le dashboard di CrUX, abbiamo potuto stabilire che le nostre pagine si stavano spostando più del previsto.
Idealmente, volevamo che almeno il 75% dei nostri lettori avesse un'esperienza "buona", quindi abbiamo iniziato a identificare le cause dell'instabilità del layout.
Come abbiamo misurato le variazioni del layout
Abbiamo utilizzato una combinazione di Chrome DevTools e WebPageTest per identificare la causa della variazione del layout. In DevTools, abbiamo utilizzato la sezione Esperienza della scheda Prestazioni per evidenziare le singole istanze di layout in continuo cambiamento e il modo in cui hanno contribuito al punteggio complessivo.
WebPageTest evidenzia chiaramente dove si verifica la variazione del layout nella visualizzazione cronologica quando è selezionata l'opzione "Evidenzia variazioni layout".
Dopo aver esaminato ogni variazione dei modelli più visitati, abbiamo elaborato un elenco di idee su come migliorare.
Ridurre le variazioni del layout
Ci siamo concentrati su quattro aree in cui potevamo ridurre le variazioni del layout: - annunci - immagini - intestazioni - incorporamenti
Annunci
Gli annunci vengono caricati dopo la visualizzazione iniziale tramite JavaScript. Alcuni dei container in cui sono stati caricati non avevano un'altezza riservata.
Anche se non conosciamo l'altezza esatta, siamo in grado di prenotare spazio utilizzando le dimensioni dell'annuncio più comuni caricate nell'area annuncio.
In alcuni casi avevamo erroneamente valutato l'altezza media dell'annuncio. Per i lettori di tablet, lo slot si stava collassando.
Abbiamo rivisto nuovamente l'area e modificato l'altezza in modo da utilizzare la dimensione più comune.
Immagini
Molte immagini sul sito web sono caricate tramite caricamento lento e hanno il loro spazio riservato.
Tuttavia, le immagini incorporate nella parte superiore degli articoli non avevano nessuno spazio riservato nel contenitore, né attributi di larghezza e altezza associati ai tag. Di conseguenza, il layout cambiava durante il caricamento.
La semplice aggiunta degli attributi di larghezza e altezza alle immagini assicurava che il layout non si spostasse.
Titolo
L'intestazione si trovava sotto i contenuti nel markup ed è stata posizionata nella parte superiore utilizzando CSS. L'idea iniziale era di dare la priorità al caricamento dei contenuti prima della navigazione, ma ciò causava uno spostamento temporaneo della pagina.
Lo spostamento dell'intestazione nella parte superiore del markup ha consentito la visualizzazione della pagina senza questa variazione.
Incorporamenti
Alcuni degli incorporamenti utilizzati di frequente hanno proporzioni definite. Ad esempio, i video di YouTube. Durante il caricamento del player, estraiamo la miniatura da YouTube e la utilizziamo come segnaposto durante il caricamento del video.
Misurazione dell'impatto
Siamo riusciti a misurare molto facilmente l'impatto a livello di funzionalità utilizzando gli strumenti indicati all'inizio dell'articolo. Tuttavia, volevamo misurare il CLS sia a livello di modello che a livello di sito. Abbiamo utilizzato in modo sintetico SpeedCurve per convalidare le modifiche sia in pre-produzione che in produzione.
Siamo quindi in grado di convalidare i risultati nei nostri dati RUM (forniti da mPulse) una volta che il codice ha raggiunto la produzione.
Controllare i dati del RUM ci consente di avere la certezza che le modifiche che stiamo apportando stanno avendo un impatto positivo per i nostri lettori.
Le cifre finali che abbiamo esaminato si riferiscono ai dati RUM raccolti da Google. Questo aspetto è particolarmente importante al momento, in quanto presto avranno un impatto sul ranking della pagina. Per iniziare, abbiamo usato il report sull'esperienza utente di Chrome, sia nei dati mensili a livello di origine disponibili tramite la dashboard di CrUX, sia nelle query su BigQuery per recuperare i dati storici di P75. In questo modo, abbiamo potuto notare facilmente che per tutto il traffico misurato da CrUX, il nostro 75° percentile CLS è migliorato del 250% da 0,25 a 0,1 e il nostro bucket di passaggio è aumentato dal 57% al 72%.
Inoltre, abbiamo potuto utilizzare l'API Chrome UX Reporte creare alcune dashboard interne suddivise in modelli.
Come evitare le regressioni CLS
Un aspetto importante per migliorare le prestazioni è evitare le regressioni. Abbiamo impostato alcuni budget di rendimento di base per le nostre metriche chiave e incluso il CLS in queste.
Se il test supera il budget, verrà inviato un messaggio a un canale Slack per consentirci di esaminare la causa. Inoltre, abbiamo configurato report settimanali in modo che, anche se i modelli rimangono nel budget, veniamo a conoscenza di eventuali modifiche che hanno avuto un impatto negativo.
Prevediamo inoltre di espandere i nostri budget per utilizzare i dati RUM e i dati sintetici, utilizzando mPulse per impostare sia avvisi statici che il potenziale rilevamento di anomalie, in modo da venire a conoscenza di eventuali modifiche fuori dal comune.
Per noi è importante affrontare le nuove funzionalità tenendo presente la metrica CLS. Molte delle modifiche di cui ho parlato sono quelle che abbiamo dovuto correggere dopo che sono state comunicate ai nostri lettori. La stabilità del layout verrà presa in considerazione per la progettazione della soluzione di qualsiasi nuova funzionalità futura, in modo da poter evitare variazioni impreviste del layout dall'inizio.
Conclusione
I miglioramenti apportati finora sono stati molto facili da implementare e hanno avuto un impatto significativo. L'applicazione di molte delle modifiche descritte in questo articolo non ha richiesto molto tempo e sono state applicate a tutti i modelli di uso più comune, il che significa che hanno avuto un impatto positivo diffuso per i nostri lettori.
Ci sono ancora aree del sito che dobbiamo migliorare. Stiamo valutando nuovi modi per utilizzare al meglio la logica lato client lato server per migliorare ulteriormente la metrica CLS. Continueremo a monitorare e monitorare le nostre metriche con l'obiettivo di migliorarle costantemente e offrire ai nostri lettori la migliore esperienza utente possibile.