Vários meses de trabalho para melhorar as Core Web Vitals na página inicial do Mail.ru resultaram em um aumento de 60% no 75o percentil na Mudança de layout cumulativa (CLS), impulsionando o tempo médio da 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 de língua russa e está nos cinco principais sites da Rússia em termos de tráfego. O Mail.ru é um recurso importante para muitas pessoas. Ele recebe centenas de milhões de visitas por mês e é um portal de onde as pessoas podem acessar e-mails, notícias, mídias sociais, pesquisas de performance na Internet e muito mais.
O Mail.ru queria oferecer aos visitantes uma experiência de usuário de alta qualidade, então começou a trabalhar para melhorar as Core Web Vitals. Antes de discutirmos nossa estratégia de otimização, alguns detalhes técnicos da página inicial do Mail.ru devem ser observados.
Embora o projeto já tivesse sido desenvolvido há muito tempo usando nosso mecanismo interno de modelos 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 faz com que ele consome menos recursos. A abordagem do Svelte remove funções não utilizadas de pacotes de produção, porque o código que as implementa não será 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, na sigla em inglês) durante a inicialização da página.
Como rastrear métricas de desempenho
Antes de otimizar as Core Web Vitals, avalie a performance em campo. Antes das Core Web Vitals, rastreamos outras métricas, como a Primeira exibição de conteúdo (FCP, na sigla em inglês), no painel de desempenho interno.
Nosso script de coleta de métricas foi modificado para coletar as Core Web Vitals e transmiti-las ao painel de desempenho para visualização. De acordo com as recomendações do Google, nosso script usa a API PerformanceObserver para gerar as métricas, que fazem parte da plataforma de front-end universal do Mail.ru.
O painel exibiu as seguintes métricas para usuários (valores médios para a 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 | |
| Parcela de usuários de acordo com os limites das Core Web Vitals | good | 52% | 92% | 33% | 35% | 42% | 43% |
| de que precisa | 19% | 5% | 23% | 38% | 16% | 25% | |
| ruim | 29% | 3% | 44% | 27% | 42% | 32% | |
Como melhorar as Core Web Vitals
Existem muitas orientações para melhorar as Core Web Vitals, mas cada projeto tem desafios únicos. Para a página inicial do Mail.ru, as seguintes oportunidades foram identificadas:
- Implementação de marcadores de posição para banners de anúncios para reduzir o CLS.
- Usar a renderização do lado do servidor (SSR, na sigla em inglês) para reduzir a Maior exibição de conteúdo (LCP).
- Divisão de código para reduzir a LCP e a latência na primeira entrada (FID, na sigla em inglês).
Esqueletos para melhoria da CLS
A CLS foi uma das métricas de campo com pior desempenho na página inicial do Mail.ru. A criação de perfil subsequente dessa página no painel Performance do DevTools do Chrome 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 os anúncios antes que eles sejam carregados.
Ao implementar espaços reservados, a primeira etapa é determinar as dimensões do conteúdo que vão substituí-los. Felizmente, a versão para computador da página inicial do Mail.ru tem tamanhos bem documentados para anúncios. Depois de conversar com a equipe de design, esqueletos de interface animados com SVG foram usados como marcadores de posição porque reduzem o tempo de carregamento percebido do conteúdo.
O retorno da SSR
Para facilitar a transição do Fest para o Svelte, reescrevemos gradualmente o projeto existente em vez de começar de novo. Em março de 2021, migramos a maior parte do front-end para o Svelte e trouxemos a SSR para nosso aplicativo de produção após fazer a triagem e corrigir problemas de desempenho no back-end.
Após implementar a SSR, a equipe descobriu a causa da regressão da CLS que inicialmente passava despercebida: a seção de notícias não foi inserida no momento da renderização do primeiro conteúdo da 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 o DevTools do Chrome mostrasse eventos de mudança de layout, não foi possível encontrar o motivo primeiro. Embora a própria SSR não fosse o problema, ela 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 a SSR pode ter na CLS é a movimentação dos componentes antes e depois da hidratação, o que pode gerar mais mudanças de layout. Encontramos isso em particular na versão para dispositivos móveis e exigiu atenção especial à marcação do componente hidratado. Uma boa solução para esse problema foi transferir o máximo possível de lógica de exibição do JavaScript para o CSS.
Divisão de código e polyfills não usados
Para melhorar a velocidade de carregamento da página percebida, foi necessário trabalhar para diminuir os valores de LCP e FID. Uma maneira de fazer isso é pela divisão de código. Além da página inicial do Mail.ru em si, nossa equipe está desenvolvendo um widget para navegação no portal. No momento, ele está incorporado em muitos dos projetos da nossa empresa.
Por motivos históricos, o widget é inserido bem no início da página como um script de carregamento síncrono. A parcela de polyfills nesse script aumentou com o tempo. Para limitar os efeitos negativos na performance do carregamento desses polyfills, implementamos a divisão de código em navegadores modernos e legados.
Decidimos não usar o padrão module/nomodule para carregar pacotes JavaScript para navegadores modernos ou legados, já que o atributo type="module" do elemento <script> não tinha como alvo navegadores modernos o suficiente para nossas necessidades. Para resolver isso, o Mail.ru usa uma ferramenta interna para identificar as versões modernas dos navegadores no back-end e pode se adaptar a esses navegadores adequadamente.
Quando 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 de portal.
Além da redução do tamanho dos pacotes 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 parte está em uma tendência decrescente.Por isso, a implementação da divisão de código permitiu que nossos desenvolvedores usassem as APIs de navegador mais recentes sem introduzir a sobrecarga de polyfill necessária para navegadores legados a todos os usuários.
Resultados
Após o esforço de otimização, observamos os valores médios para a 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 | |
| Parcela de usuários de acordo com os limites das Core Web Vitals | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| de que precisa | 18% | 4% | 3% | 34% | 17% | 24% | |
| ruim | 24% | 3% | 4% | 23% | 34% | 25% | |
Os gráficos abaixo mostram as alterações 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 últimas seções da página migrada para o Svelte
- 19 de abril de 2021: lançamento da iteração com SSR retornada e layout modificado para corrigir regressões de CLS.
A redução nos valores de 1o a 10 de maio está relacionada aos feriados na Rússia.
Os resultados obtidos usando a "Plataforma" estão alinhados com o crescimento dos valores das métricas no Chrome UX Report (CrUX).
Uma comparação entre os valores de duração média da sessão do usuário uma semana antes e uma semana após o lançamento das melhorias mostra um crescimento de 2,7%. Além disso, há um aumento significativo geral nas conversões na maioria das seções da página. Especificamente, as conversões para o aplicativo de e-mail Mail.ru aumentaram em 11,6%, e a conversão da seção de notícias aumentou em 13,5%.
181%
Aumento do limite da parcela do bom limite de CLS
2,7%
Duração média da sessão maior
13,5%
Aumento da taxa de conversão da seção de notícias
O resultado mais inesperado que tivemos foi um aumento de 17,4% na taxa de cliques (CTR) do banner de marketing (o tempo de renderização 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 melhoria de desempenho significativa na grande maioria delas. Mesmo para seções como "Clima" e "Coronavírus", que não são essenciais na nossa página, notamos um aumento de 9,6% e 9,5% nas conversões, respectivamente.
Conclusão
Melhorar o desempenho é um desafio, porque o trabalho envolvido pode ser prolongado. Monitore regularmente as mudanças nas métricas ao longo do tempo e garanta que os novos recursos do produto não causem regressões nas Core Web Vitals. Para isso, monitoramos as mudanças nas Core Web Vitals no orçamento de performance.
Mais importante ainda, destacamos a importância das Core Web Vitals para todos os membros da nossa equipe de produto, de gerentes e designers a testadores e QA. Cada membro da equipe deve estar ciente das métricas de desempenho e estar capacitado para melhorá-las. Nós também incorporamos regularmente objetivos de otimização de desempenho em nossos processos de negócios. Oferecer com sucesso uma experiência do usuário de alta qualidade só é possível por meio do esforço conjunto de todos os membros da equipe.