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 verifica della stabilità visiva
Le variazioni del layout possono essere molto disgreganti. Per Telegraph Media Group (TMG), la stabilità visiva è particolarmente importante perché i lettori utilizzano prevalentemente le nostre applicazioni per consumare le notizie. Se il layout cambia durante la lettura di un articolo, il lettore probabilmente perderà il segno. Questa può essere un'esperienza frustrante e di distrazione.
Dal punto di vista dell'ingegneria, assicurarsi che le pagine non si spostino e non interrompano il lettore può essere complicato, soprattutto quando le aree dell'applicazione vengono caricate in modo asincrono e aggiunte alla pagina in modo dinamico.
In TMG, abbiamo più team che contribuiscono con codice lato client:
- Ingegneria di base. Implementazione di soluzioni di terze parti per potenziare aree come i consigli sui contenuti e i commenti.
- Marketing. Eseguiamo test A/B per valutare in che modo i nostri lettori interagiscono con nuove funzionalità o modifiche.
- Pubblicità. Gestione delle richieste di annunci e delle offerte preliminari per gli annunci.
- Requisiti redazionali. Codice incorporato all'interno di articoli come tweet o video, nonché widget personalizzati (ad esempio il tracker dei casi di coronavirus).
Garantire che ciascuno di questi team non causi interruzioni nel layout della pagina può essere difficile. Utilizzando la metrica Spostamento cumulativo del layout per misurare la frequenza con cui si verifica per i nostri lettori, i team hanno ottenuto informazioni più dettagliate sull'esperienza utente reale e un obiettivo chiaro da raggiungere. Di conseguenza, il CLS del 75° percentile è migliorato da 0,25 a 0,1 e il bucket di passaggio è aumentato dal 57% al 72%.
250%
Miglioramento del CLS al 75° percentile
15%
Più utenti con un buon punteggio CLS
Dove abbiamo iniziato
Utilizzando le dashboard CrUX, abbiamo potuto stabilire che le nostre pagine si spostavano più di quanto avremmo voluto.
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 modifiche al layout
Abbiamo utilizzato una combinazione di Chrome DevTools e WebPageTest per capire cosa causava il cambiamento del layout. In DevTools, abbiamo utilizzato la sezione Esperienza della scheda Rendimento per evidenziare le singole istanze di layout in mutazione e il loro contributo al punteggio complessivo.
WebPageTest evidenzia dove si verifica il cambiamento di layout nella visualizzazione della sequenza temporale quando è selezionata l'opzione "Evidenzia cambiamenti di layout".
Dopo aver esaminato ogni variazione nei nostri modelli più visitati, abbiamo stilato un elenco di idee su come possiamo migliorare.
Ridurre le variazioni del layout
Ci siamo concentrati su quattro aree in cui potevamo ridurre i cambiamenti di layout: - annunci - immagini - intestazioni - contenuti incorporati
Annunci
Gli annunci vengono caricati dopo la visualizzazione iniziale tramite JavaScript. Alcuni dei contenitori caricati non avevano un'altezza riservata.
Anche se non conosciamo l'altezza esatta, possiamo prenotare lo spazio utilizzando le dimensioni degli annunci più comuni caricate nell'area.
In alcuni casi abbiamo valutato erroneamente l'altezza media dell'annuncio. Per i lettori di tablet, lo slot si chiudeva.
Abbiamo rivisto l'area e regolato l'altezza in modo da utilizzare le dimensioni più comuni.
Immagini
Molte delle immagini del sito web sono caricate in modo lazy e hanno uno spazio riservato.
Tuttavia, le immagini in linea nella parte superiore degli articoli non avevano spazio riservato nel contenitore né attributi larghezza e altezza associati ai tag. Ciò ha causato uno spostamento del layout durante il caricamento.
È sufficiente aggiungere gli attributi larghezza e altezza alle immagini per garantire che il layout non subisca variazioni.
Intestazione
L'intestazione si trovava sotto i contenuti nel markup ed era posizionata in alto utilizzando CSS. L'idea originale era dare la priorità al caricamento dei contenuti prima della navigazione, ma questo ha causato un momentaneo spostamento della pagina.
Lo spostamento dell'intestazione nella parte superiore del markup ha consentito il rendering della pagina senza questo spostamento.
Incorporamenti
Alcuni degli elementi incorporati di uso frequente hanno un formato definito. Ad esempio, video di YouTube. Durante il caricamento del player, recuperiamo la miniatura da YouTube e la utilizziamo come segnaposto durante il caricamento del video.
Misurare l'impatto
Abbiamo potuto misurare l'impatto a livello di funzionalità abbastanza facilmente utilizzando gli strumenti menzionati all'inizio dell'articolo. Tuttavia, volevamo misurare il valore CLS sia a livello di modello che a livello di sito. In modo sintetico, abbiamo utilizzato SpeedCurve per convalidare le modifiche sia in pre-produzione che in produzione.
Una volta che il codice è stato implementato in produzione, possiamo convalidare i risultati nei nostri dati RUM (forniti da mPulse).
Il controllo dei dati RUM ci offre un buon livello di certezza che le modifiche che stiamo apportando stiano avendo un impatto positivo per i nostri lettori.
I numeri finali che abbiamo esaminato si riferiscono ai dati RUM raccolti da Google. Questo è particolarmente importante ora, perché a breve avranno un impatto sul ranking della pagina. Per iniziare, abbiamo utilizzato il report sull'esperienza utente di Chrome, sia nei dati mensili a livello di origine disponibili tramite la dashboard CrUX, sia eseguendo query su BigQuery per recuperare i dati storici della p75. In questo modo abbiamo potuto facilmente vedere che per tutto il traffico misurato da CrUX, il nostro CLS al 75° percentile è migliorato del 250%, passando da 0,25 a 0,1 e il nostro bucket di passaggio è aumentato dal 57% al 72%.
Inoltre, abbiamo potuto utilizzare l'API Report sull'esperienza utente di Chrome e creare alcune dashboard interne suddivise in modelli.
Evitare le regressioni del CLS
Un aspetto importante per migliorare le prestazioni è evitare le regressioni. Abbiamo impostato alcuni budget di rendimento di base per le nostre metriche principali e abbiamo incluso il CLS.
Se il test supera il budget, verrà inviato un messaggio a un canale Slack per consentirci di esaminare la causa. Abbiamo anche configurato report settimanali, in modo che, anche se i modelli rimangono in budget, siamo a conoscenza di eventuali modifiche che hanno avuto un impatto negativo.
Inoltre, prevediamo di espandere i nostri budget per utilizzare i dati RUM e quelli sintetici, utilizzando mPulse per impostare sia avvisi statici sia potenzialmente il rilevamento di anomalie, che ci avvisano di eventuali variazioni fuori dall'ordinario.
È importante per noi approcciarci alle nuove funzionalità tenendo presente il CLS. Molte delle modifiche che ho citato sono quelle che abbiamo dovuto correggere dopo che sono state rilasciate ai nostri lettori. La stabilità del layout verrà presa in considerazione per il design della soluzione di qualsiasi nuova funzionalità in futuro, in modo da evitare cambiamenti imprevisti del layout fin dall'inizio.
Conclusione
I miglioramenti apportati finora sono stati abbastanza facili da implementare e hanno avuto un impatto significativo. Molte delle modifiche descritte in questo articolo non hanno richiesto molto tempo per essere implementate e sono state applicate a tutti i modelli più utilizzati, il che significa che hanno avuto un impatto positivo diffuso per i nostri lettori.
Ci sono ancora aree del sito che dobbiamo migliorare. Stiamo esplorando modi per poter eseguire più logica lato client lato server, in modo da migliorare ulteriormente il CLS. Continueremo a monitorare le nostre metriche con l'obiettivo di migliorarle costantemente e offrire ai nostri lettori la migliore esperienza utente possibile.