Melhoria da mudança de layout cumulativa no Telegraph Media Group

Em alguns meses, o principal site de notícias do Reino Unido conseguiu melhorar a CLS no 75o percentil em 250%, de 0,25 para 0,1.

Chris Boakes

O desafio de estabilidade visual

Trocas de layout podem ser muito disruptivas. No Telegraph Media Group (TMG), a estabilidade visual é particularmente importante porque os leitores usam predominantemente nossos aplicativos para conferir as notícias. Se o layout mudar durante a leitura de uma matéria, o leitor provavelmente vai se perder. Isso pode ser uma experiência frustrante e perturbadora.

Do ponto de vista da engenharia, garantir que as páginas não mudem e interrompam o leitor pode ser um desafio, especialmente quando áreas do aplicativo são carregadas de forma assíncrona e adicionadas à página de forma dinâmica.

No TMG, temos várias equipes que contribuem com código do lado do cliente:

  • Engenharia principal. Implementar soluções de terceiros para potencializar á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 pré-lances de anúncios.
  • Requisitos editoriais. Incorporar código em artigos, como tweets ou vídeos, além de widgets personalizados (por exemplo, rastreador de casos de coronavírus).

Garantir que cada uma dessas equipes não faça com que o layout da página fique difícil. Usando a métrica Mudança de layout cumulativa para medir a frequência com que ela ocorre para os leitores, as equipes conseguiram mais insights sobre a experiência real do usuário e um objetivo claro a ser alcançado. Isso resultou na melhoria da CLS no 75o percentil de 0,25 para 0,1, e o bucket de passagem aumentou de 57% para 72%.

250%

Melhoria de CLS no 75o percentil

15%

Mais usuários com uma boa pontuação de CLS

Onde começamos

Usando os painéis do CrUX, conseguimos estabelecer que nossas páginas estavam mudando mais do que gostaríamos.

Painel CrUX mostrando cerca de 55% a 60% de bons, 15% precisam de melhorias e 25% de pontuações ruins.
Nossas pontuações da Mudança de layout cumulativa entre junho de 2020 e fevereiro de 2021

O ideal seria que pelo menos 75% dos nossos leitores tivessem uma experiência "boa", então 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 mudanças no layout. No DevTools, usamos a seção Experiência da guia Desempenho para destacar instâncias individuais de mudança de layout e como elas contribuíram para a pontuação geral.

A primeira página do Telegraph com um anúncio no cabeçalho destacada por uma sobreposição azul.
Identifique uma mudança de layout causada pelo carregamento de anúncios no lado do cliente acima do cabeçalho usando a seção "Experiência" do Chrome DevTools.

O WebPageTest destaca onde a mudança de layout ocorre na visualização da linha do tempo quando a opção "Destacar mudanças de layout" é selecionada.

Visualização de tira de filme do WebPageTest do site do Telegraph com o layoutshift destacado em uma sobreposição vermelha.
WebPageTest destacando onde o layout foi alterado.

Depois de analisar cada mudança em nossos modelos mais visitados, tivemos uma lista de ideias de como podemos melhorar.

Reduzir mudanças de layout

Focamos 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 exibição inicial via JavaScript. Alguns dos contêineres em que eles foram carregados não tinham altura reservada.

Animação do site do Telegraph. A lista de histórias é empurrada para baixo quando um anúncio é carregado acima dela.
O bloco "Mais matérias" abaixo do anúncio é deslocado para baixo depois que ele é carregado.

Não sabemos a altura exata, mas podemos reservar espaço usando o tamanho de anúncio mais comum carregado no espaço.

Animação do site do Telegraph. Um retângulo marcador de posição para o anúncio é colocado acima da lista de histórias. O anúncio é carregado no lugar do marcador de posição sem causar uma mudança de layout.
Ao reservar espaço para o anúncio, o bloco "Mais matérias" abaixo permanece estático antes e depois do carregamento do anúncio.

Em alguns casos, tínhamos avaliado a altura média do anúncio de forma incorreta. Para leitores de tablet, o slot estava sendo recolhido.

Animação da visualização em um tablet do site do Telegraph. O espaço do marcador é maior do que o anúncio, então o conteúdo muda para cima depois que o anúncio é carregado.
O espaço do anúncio que é recolhido após o carregamento para leitores em dispositivos com tamanho de tablet.

Analisamos o slot novamente e ajustamos a altura para usar o tamanho mais comum.

Animação da visualização em um tablet do site do Telegraph. Quando o marcador corresponde ao tamanho do anúncio, não há mudança de layout quando o anúncio é carregado.
Garante que o espaço reservado para o espaço do anúncio corresponda à altura mais frequentemente veiculada do anúncio.

Imagens

Muitas imagens no site são carregadas lentamente e têm o espaço reservado para elas.

Animação de cards de prévia da matéria carregando.
Carregamento lento de imagens sem interromper o layout.

No entanto, as imagens in-line 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 fazia com que o layout mudasse à medida que eles eram carregados.

Animação do carregamento da página da matéria. Quando a imagem principal é carregada na parte superior da página, o texto se move para baixo.
Uma mudança de layout causada pela imagem principal do artigo.

Simplesmente adicionar os atributos de largura e altura às imagens garantiu que o layout não mudasse.

Animação do carregamento da página do artigo com o marcador reservado para a imagem principal. Quando a imagem principal é carregada na parte superior da página, não há mudança de layout.
A imagem da matéria principal é carregada sem mudar o layout.

O cabeçalho ficava abaixo do conteúdo na marcação e era posicionado na parte superior usando CSS. A ideia original era priorizar o carregamento do conteúdo antes da navegação, mas isso fazia com que a página mudasse momentaneamente.

ALT_TEXT_HERE
O cabeçalho do carregamento da página de forma desigual.

Mover o cabeçalho para a parte de cima da marcação permitiu que a página fosse renderizada sem essa mudança.

ALT_TEXT_HERE
O layout não é mais interrompido pelo cabeçalho do carregamento da página.

Incorporações

Algumas das incorporações mais usadas têm uma proporção definida. Por exemplo, vídeos do YouTube. Enquanto o player carrega, extraímos a miniatura do YouTube e a usamos como um marcador de posição enquanto o vídeo carrega.

O espaço do player de vídeo carrega uma miniatura de baixa resolução enquanto o player de vídeo é carregado.
O slot do player de vídeo carregando uma miniatura de baixa resolução enquanto o player de 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 o CLS no nível do modelo e do site. Sinteticamente, usamos SpeedCurve para validar alterações na pré-produção e na produção.

Gráfico SpeedCurve mostrando uma queda acentuada na pontuação de CLS.
Como rastrear o progresso do CLS de forma sintética usando o SpeedCurve.

Podemos então validar os resultados nos nossos dados RUM (fornecidos pelo mPulse) assim que o código atingir a produção.

Gráfico do mPulse mostrando uma queda na pontuação de CLS.
Validar as melhorias de CLS em todo o site com dados do mPulse RUM antes e depois de fazer alterações.

Verificar os dados do RUM proporciona 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 dos dados de RUM que o Google coleta. Isso é especialmente relevante agora, já que em breve terão um impacto na classificação da página. Para começar, usamos o Chrome UX Report, tanto nos dados mensais no nível da origem disponíveis no painel CrUX quanto ao consultar o BigQuery para recuperar dados históricos do p75. Dessa forma, conseguimos ver facilmente que, para todo o tráfego medido pelo CrUX, nossa CLS de 75o percentil melhorou 250% de 0,25 para 0,1, e o bucket de aprovação aumentou de 57% para 72%.

Painel do CrUX mostrando que o CLS p75 para telegraph.co.uk é 0.1.
Resultados do painel do Crux.
BigQuery mostrando valores p75 melhorando a cada mês, de 0,25 para 0,1.
Execução do BigQuery mostrando os valores p75 de 2021 até o momento.

Além disso, conseguimos usar a API Chrome UX Report e criar alguns painéis internos divididos em modelos.

Painel interno mostrando a pontuação média boa de 76,2, "Precisa de melhorias" de 9,3 e a pontuação ruim de 14,6.
Painéis internos com a API Chrome UX Report destacando nossa pontuação média e as páginas com pior desempenho que usam esse modelo.

Como evitar regressões de CLS

Um aspecto importante para melhorar o desempenho é evitar regressões. Configuramos alguns orçamentos de desempenho básicos para nossas principais métricas e incluímos CLS nelas.

Um painel de orçamento de performance que mostra verificações sintéticas que medem a CLS em alguns dos nossos modelos de alto tráfego. No momento, o orçamento está definido em 0,025.

Se o teste exceder o orçamento, ele vai enviar uma mensagem a um canal do Slack para que possamos investigar a causa. Também configuramos relatórios semanais para que, mesmo que os modelos permaneçam no orçamento, estejamos cientes de quaisquer alterações que tiveram um impacto negativo.

Também planejamos expandir nossos orçamentos para usar dados RUM e sintéticos, usando o mPulse para definir alertas estáticos e potencialmente detecção de anomalias que nos informariam sobre quaisquer mudanças que estejam fora do comum.

É importante pensar nos novos recursos tendo em mente a CLS. Muitas das mudanças que mencionei são aquelas que tivemos que corrigir depois que elas foram 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 inesperadas de layout desde o início.

Conclusão

As melhorias que fizemos até agora foram muito fáceis de implementar e tiveram um impacto significativo. Muitas mudanças descritas neste artigo não levaram muito tempo para serem entregues e foram aplicadas a todos os modelos mais usados, o que significa que eles tiveram um impacto positivo generalizado para nossos leitores.

Ainda há áreas do site que precisamos melhorar. Estamos analisando maneiras de fazer mais da nossa lógica do lado do cliente no lado do servidor, o que vai melhorar ainda mais o CLS. Vamos continuar rastreando e monitorando nossas métricas com o objetivo de aprimorá-las constantemente e oferecer aos nossos leitores a melhor experiência do usuário possível.