Vários meses de trabalho para melhorar as Core Web Vitals na página inicial do Mail.ru resultaram em um aumento de 60% na 75ª percentil no deslocamento cumulativo do layout (CLS, na sigla em inglês), aumentando o tempo médio de sessão em 2,7% e as taxas de conversão das seções principais em mais de 10%.
Onde começamos
O Mail.ru é um dos principais serviços de e-mail na Internet em russo e está entre os cinco sites mais acessados da Rússia. O Mail.ru é um recurso importante para muitas pessoas. Ele recebe centenas de milhões de visitas por mês e é um portal em que as pessoas podem acessar e-mail, notícias, mídias sociais, pesquisas na Internet e muito mais.
O Mail.ru queria oferecer aos visitantes uma experiência de usuário de alta qualidade. Por isso, começou a trabalhar para melhorar as Core Web Vitals. Antes de discutir nossa estratégia de otimização, é preciso observar alguns detalhes técnicos da página inicial do Mail.ru.
Embora o projeto tenha sido desenvolvido há muito tempo usando nosso mecanismo de modelagem interno Fest, começamos a migrar para o Svelte 3 em 2019.
O Svelte implementa a reatividade de uma forma que não usa o DOM virtual, o que reduz o uso de recursos. A abordagem do Svelte remove funções não utilizadas dos pacotes de produção porque o código que as implementa não é gerado pelo compilador se as funções não forem usadas. O código não utilizado é removido durante a compilação, resultando em pacotes menores. Isso pode ajudar a reduzir o tempo total de bloqueio (TBT) durante a inicialização da página.
Acompanhar métricas de performance
Antes de otimizar as Core Web Vitals, é útil avaliar a performance no campo. Antes dos Core Web Vitals, rastreamos outras métricas, como a First Contentful Paint (FCP), no nosso painel de desempenho interno.
Nosso script de coleta de métricas foi modificado para coletar as Core Web Vitals e transmiti-las ao nosso painel de performance para visualização. De acordo com as recomendações do Google, nosso script usa a API PerformanceObserver para coletar métricas, que fazem parte da plataforma de front-end universal no Mail.ru.
O painel exibiu as seguintes métricas para os usuários (valores médios da semana de 15 a 21 de março de 2021):
| Nome do grupo de métricas | Core Web Vitals | Outras Métricas da Web | |||||
|---|---|---|---|---|---|---|---|
| Nome da métrica | LCP | FID | CLS | First Contentful Paint (FCP) | TBT | TTI | |
| Porcentagem de usuários de acordo com os limites das Core Web Vitals | bom | 52% | 92% | 33% | 35% | 42% | 43% |
| needs-improvement | 19% | 5% | 23% | 38% | 16% | 25% | |
| ruim | 29% | 3% | 44% | 27% | 42% | 32% | |
Como melhorar as Core Web Vitals
Embora existam muitas orientações para melhorar as Core Web Vitals, cada projeto tem desafios únicos. Para a página inicial do Mail.ru, as seguintes oportunidades foram identificadas:
- Implementar marcadores de posição para banners de anúncios e reduzir a CLS.
- Usar a renderização do lado do servidor (SSR) para reduzir a maior exibição de conteúdo (LCP).
- Divisão de código para reduzir a LCP e o First Input Delay (FID).
Esqueletos para melhoria da CLS
A CLS foi uma das métricas de campo com pior desempenho na página inicial do Mail.ru. O perfil subsequente dessa página no painel Performance do Chrome DevTools revelou que os anúncios eram a origem do problema. Para melhorar a estabilidade do layout, nossa equipe decidiu usar marcadores de posição para reservar espaço para anúncios antes do carregamento.
Ao implementar marcadores de posição, a primeira etapa é determinar as dimensões do conteúdo que vai substituí-los. Felizmente, a versão para computador da página inicial do Mail.ru tem tamanhos de anúncios estritamente documentados. Depois de conversar com a equipe de design, esqueletos de interface animados em SVG foram usados como marcadores de posição, porque eles reduzem o tempo de carregamento percebido do conteúdo.
O retorno do SSR
Para facilitar a transição do Fest para o Svelte, reescrevi o projeto atual de forma incremental em vez de começar de novo. Em março de 2021, migramos a maior parte do front-end para o Svelte e, depois de resolver os problemas de desempenho do back-end, trouxemos o SSR para nosso aplicativo de produção.
Depois de implementar o SSR, a equipe descobriu a causa da regressão do CLS que inicialmente passou despercebida: a seção de notícias não foi inserida no momento da renderização do primeiro conteúdo na página. Houve um atraso entre a pintura inicial da marcação da página fornecida pelo servidor e a inserção da seção de notícias no cliente. Esse comportamento resultou em uma mudança no esqueleto do anúncio, o que piorou a CLS.
Embora as ferramentas do desenvolvedor do Chrome mostrassem eventos de Layout Shift, não conseguimos encontrar o motivo disso no início. Embora o SSR não fosse o problema, ele ajudou a descobrir a solução mais tarde. A correção do código responsável pelo atraso de pintura melhorou a estabilidade do layout do componente de notícias.
Outro efeito que o SSR pode ter na CLS é o movimento de componentes antes e depois da hidratação, o que pode levar a mais mudanças de layout. Encontramos esse problema na versão para dispositivos móveis e foi necessário prestar atenção especial ao markup do componente hidratado. Uma boa solução para esse problema foi transferir o máximo possível da lógica de exibição do JavaScript para o CSS quando possível.
Divisão de código e polyfills não usados
Para melhorar a velocidade de carregamento percebida da página, foi necessário trabalhar para diminuir os valores de LCP e FID. Uma maneira de fazer isso é com a divisão de código. Além da página inicial do Mail.ru, nossa equipe está desenvolvendo um widget para navegação no portal. Atualmente, ele está integrado a muitos dos projetos da nossa empresa.
Por motivos históricos, o widget é inserido no início da página como um script de carregamento síncrono. A participação de polyfills nesse script aumentou com o tempo. Para limitar os efeitos negativos de desempenho do carregamento desses polyfills, implementamos a divisão de código para navegadores modernos e legados.
Decidimos não usar o padrão module/nomodule para carregar pacotes JavaScript em navegadores modernos ou legados, porque o atributo type="module" do elemento <script> não era direcionado a navegadores modernos o suficiente para nossas necessidades. Para resolver esse problema, o Mail.ru usa uma ferramenta interna para identificar versões modernas de navegadores no back-end e pode se adaptar a esses navegadores.
Depois que os navegadores puderam ser identificados no back-end, implementamos a divisão de código para navegadores modernos e legados. O resultado foi uma redução de 43,3% no tamanho do widget JavaScript carregado de forma síncrona para navegadores modernos. Essa prática também foi aplicada a alguns outros scripts do portal.
Além da redução do tamanho do pacote e dos efeitos positivos nas Core Web Vitals, a divisão de código também melhora a experiência do desenvolvedor. Apenas 3,5% dos nossos usuários usam navegadores legados, e essa porcentagem está em declínio.Portanto, a implementação da divisão de código permitiu que nossos desenvolvedores usassem as APIs de navegador mais recentes sem introduzir o aumento de tamanho de polyfill necessário para navegadores legados a todos os usuários.
Resultados
Após o esforço de otimização, observamos os valores médios da semana de 24 a 30 de maio de 2021 nos nossos dados de campo:
| Nome do grupo de métricas | Core Web Vitals | Outras Métricas da Web | |||||
|---|---|---|---|---|---|---|---|
| Nome da métrica | LCP | FID | CLS | First Contentful Paint (FCP) | TBT | TTI | |
| Porcentagem de usuários de acordo com os limites das Core Web Vitals | bom | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 18% | 4% | 3% | 34% | 17% | 24% | |
| ruim | 24% | 3% | 4% | 23% | 34% | 25% | |
Os gráficos abaixo mostram mudanças nos valores das métricas de desempenho da página da Web de acordo com a "Plataforma". Observe as duas datas importantes nos gráficos:
- 23 de março de 2021: lançamento da iteração com as seções da última página migradas para o Svelte.
- 19 de abril de 2021: lançamento da iteração com SSR retornado e layout modificado para corrigir regressões de CLS.
A diminuição dos valores de 1 a 10 de maio se deve aos feriados de maio na Rússia.
Os resultados obtidos com a opção "Plataforma" estão alinhados com o crescimento dos valores de métrica no Relatório de UX do Chrome (CrUX).
Uma comparação dos valores médios da duração da sessão do usuário uma semana antes do lançamento das melhorias iniciais e uma semana depois do lançamento mostra um crescimento de 2,7%. Além disso, há um aumento significativo na conversão na maioria das seções da página. Em particular, as conversões para o app de e-mail Mail.ru aumentaram 11,6%, e a conversão da seção de notícias aumentou 13,5%.
181%
Aumento da porcentagem de bom limiar de CLS
2,7%
Duração média da sessão mais alta
13,5%
Aumento da taxa de conversão da seção de notícias
O resultado mais inesperado foi um aumento de 17,4% na taxa de cliques (CTR) do banner de marketing.O tempo de renderização dele foi reduzido significativamente com a introdução de SSR e tags de pré-carregamento.
Depois de analisar o restante das seções da página, notamos uma melhora significativa no desempenho da maioria delas. Mesmo em seções como "Clima" e "Coronavírus", que não são importantes na nossa página, observamos um aumento de 9,6% e 9,5%, respectivamente.
Conclusão
Melhorar a performance é um desafio porque o trabalho envolvido pode ser prolongado. Monitore regularmente as mudanças nas métricas ao longo do tempo e verifique se todos os novos recursos do produto não causam regressões nas Core Web Vitals. Para isso, monitoramos as mudanças nas Core Web Vitals no nosso orçamento de performance.
O mais importante é que enfatizamos a importância das Core Web Vitals para todos os membros da nossa equipe de produtos, de gerentes e designers a testadores e controle de qualidade. Cada membro da equipe precisa conhecer as métricas de performance e ter autonomia para melhorá-las. Também incorporamos os objetivos de otimização de performance aos nossos processos de negócios em uma cadência regular. Oferecer uma experiência do usuário de alta qualidade só é possível com o esforço conjunto de todos os membros da equipe.