Em alguns meses, o principal site de notícias do Reino Unido conseguiu melhorar a CLS do percentil 75 em 250%, de 0,25 para 0,1.
O desafio da estabilidade visual
As mudanças de layout podem ser muito perturbadoras. No Telegraph Media Group (TMG), a estabilidade visual é particularmente importante porque os leitores usam principalmente nossos aplicativos para consumir as notícias. Se o layout mudar durante a leitura de um artigo, o leitor provavelmente vai perder o lugar. Isso pode ser uma experiência frustrante e que distrai.
Do ponto de vista da engenharia, garantir que as páginas não mudem e interrompam o leitor pode ser desafiador, especialmente quando áreas do aplicativo são carregadas de forma assíncrona e adicionadas à página dinamicamente.
Na TMG, temos várias equipes que contribuem com o código do lado do cliente:
- Engenharia de base. Implementação de soluções de terceiros para melhorar áreas como recomendações de conteúdo e comentários.
- Marketing. Executar testes A/B para avaliar como nossos leitores interagem com novos recursos ou mudanças.
- Publicidade. Gerenciar solicitações de anúncios e lances prévios de anúncios.
- Editorial. Incorporação de código em artigos, como tweets ou vídeos, e widgets personalizados (por exemplo, rastreador de casos de coronavírus).
Pode ser difícil garantir que cada uma dessas equipes não causem solavancos no layout da página. Usando a métrica Shift de layout cumulativo para medir a frequência com que isso ocorre para nossos leitores, as equipes tiveram mais insights sobre a experiência real do usuário e uma meta clara a ser alcançada. Isso resultou em uma melhoria da CLS do percentil 75, de 0,25 para 0,1, e no crescimento do bucket de passagem, de 57% para 72%.
250%
Melhoria na CLS do percentil 75
15%
Mais usuários com boa pontuação de CLS
Onde começamos
Usando os painéis do Crux, foi possível determinar que nossas páginas estavam mudando mais do que gostaríamos.
O ideal era que pelo menos 75% dos nossos leitores tivessem uma "boa" experiência. Por isso, começamos a identificar as causas da instabilidade do layout.
Como medimos as mudanças de layout
Usamos uma combinação de Chrome DevTools e WebPageTest para ajudar a reconhecer o que estava causando a mudança do layout. No DevTools, usamos a seção Experience da guia Performance para destacar instâncias individuais de layout de mudança e como elas contribuíram para a pontuação geral.
O WebPageTest destaca onde a mudança de layout ocorre na visualização da linha do tempo quando a opção "Destaque de mudanças de layout" está selecionada.
Depois de analisar cada mudança nos modelos mais visitados, criamos uma lista de ideias sobre como melhorar.
Reduzir as trocas de layout
Focamos em quatro áreas em que poderíamos reduzir as mudanças de layout: - anúncios - imagens - cabeçalhos - incorporações
Anúncios
Os anúncios são carregados após a pintura inicial pelo JavaScript. Alguns dos contêineres carregados não tinham altura reservada.
Embora não saibamos a altura exata, podemos reservar espaço usando o tamanho de anúncio mais comum carregado no slot.
Em alguns casos, avaliamos mal a altura média do anúncio. Para leitores de tablets, o slot estava sendo recolhido.
Revisitamos o slot e ajustamos a altura para usar o tamanho mais comum.
Imagens
Muitas das imagens do site são carregadas de forma lazy e têm espaço reservado para elas.
No entanto, as imagens inline na parte de cima dos artigos não tinham espaço reservado no contêiner nem atributos de largura e altura associados às tags. Isso fez com que o layout mudasse à medida que eles eram carregados.
Basta adicionar os atributos de largura e altura às imagens para garantir que o layout não seja alterado.
Cabeçalho
O cabeçalho estava abaixo do conteúdo na marcação e foi posicionado na parte de cima usando CSS. A ideia original era priorizar o carregamento do conteúdo antes da navegação, mas isso fez com que a página mudasse momentaneamente.
Mover o cabeçalho para a parte de cima da marcação permitiu que a página fosse renderizada sem essa mudança.
Incorporações
Alguns dos embeds usados com frequência têm uma proporção definida. Por exemplo, vídeos do YouTube. Enquanto o player está carregando, extraímos a miniatura do YouTube e a usamos como marcador enquanto o vídeo é carregado.
Como medir o impacto
Foi possível medir o impacto no nível do recurso com bastante facilidade usando as ferramentas mencionadas no início do artigo. No entanto, queríamos medir a CLS no nível do modelo e do site. De forma sintética, usamos SpeedCurve para validar as mudanças na pré-produção e na produção.
Depois que o código chegar à produção, poderemos validar os resultados nos dados do RUM (fornecidos pelo mPulse).
A verificação dos dados do RUM nos dá um bom nível de confiança de que as mudanças que estamos fazendo estão tendo um impacto positivo para nossos leitores.
Os números finais que analisamos são referentes aos dados do RUM coletados pelo Google. Isso é especialmente relevante agora, porque em breve eles vão afetar a classificação da página. Para começar, usamos o Relatório de UX do Chrome, tanto nos dados mensais da origem disponíveis no painel CrUX quanto consultando o BigQuery para recuperar dados históricos de p75. Dessa forma, foi fácil notar que, para todo o tráfego medido pelo CrUX, nossa CLS de percentil 75 melhorou em 250%, de 0,25 para 0,1, e nosso bucket de passagem cresceu de 57% para 72%.
Além disso, foi possível usar a API do Relatório de UX do Chrome e criar alguns painéis internos divididos em modelos.
Como evitar regressões de CLS
Um aspecto importante para melhorar a performance é evitar regressões. Configuramos alguns orçamentos de performance básicos para nossas principais métricas e incluímos o CLS neles.
Se o teste exceder o orçamento, uma mensagem será enviada para um canal do Slack para que possamos investigar a causa. Também configuramos relatórios semanais para que, mesmo que os modelos permaneçam dentro do orçamento, saibamos de qualquer mudança que tenha um impacto negativo.
Também planejamos expandir nossos orçamentos para usar dados do RUM e dados sintéticos, usando o mPulse para definir alertas estáticos e, potencialmente, detecção de anomalias, que nos informariam sobre qualquer mudança fora do comum.
É importante que abordemos novos recursos pensando na CLS. Muitas das mudanças que mencionei são aquelas que tivemos que corrigir depois de serem lançadas para nossos leitores. A estabilidade do layout será uma consideração para o design da solução de qualquer novo recurso daqui para frente, para que possamos evitar mudanças de layout inesperadas desde o início.
Conclusão
As melhorias que fizemos até agora foram muito fáceis de implementar e tiveram um impacto significativo. Muitas das mudanças que descrevi neste artigo não levaram muito tempo para serem implementadas e foram aplicadas a todos os modelos mais usados, o que significa que elas tiveram um impacto positivo generalizado para nossos leitores.
Ainda há áreas do site que precisamos melhorar. Estamos buscando maneiras de fazer mais da nossa lógica do lado do cliente no lado do servidor, o que vai melhorar a CLS ainda mais. Vamos continuar rastreando e monitorando nossas métricas com o objetivo de melhorá-las constantemente e oferecer aos nossos leitores a melhor experiência de usuário possível.