Como a Zalando reduziu o tempo de feedback de desempenho de 1 para 15 minutos com o Lighthouse CI

A equipe da Web da Zalando descobriu que a integração do Lighthouse CI permitiu uma abordagem proativa no desempenho, com verificações de status automatizadas capazes de comparar a confirmação atual com a ramificação principal para evitar regressões de desempenho.

Jan Brockmeyer
Jan Brockmeyer
Jeremy Colin
Jeremy Colin

Com mais de 35 milhões de clientes ativos, a Zalando é a principal plataforma de moda on-line da Europa. Nesta postagem, explicamos por que começamos a usar o Lighthouse CI, a facilidade de implementação e as vantagens para nossa equipe.

Na Zalando, conhecemos a relação entre desempenho do site e receita. No passado, testamos como o aumento artificial do tempo de carregamento nas páginas do catálogo afetou as taxas de rejeição, as taxas de conversão e a receita por usuário. Os resultados foram claros. Uma melhoria de 100 milissegundos no tempo de carregamento da página levou a um maior engajamento com menor taxa de rejeição e um aumento de 0,7% na receita por sessão.

100ms

Melhoria no tempo de carregamento da página

0,7%

Aumento da receita por sessão

A adesão da empresa nem sempre se traduz em desempenho

Apesar do forte compromisso de desempenho dentro da empresa, se o desempenho não estiver definido como um critério de entrega de produto, ele poderá facilmente ignorar. Quando estávamos reformulando o site da Zalando em 2020, focamos em entregar novos recursos mantendo uma excelente experiência do usuário e reformulando o site com fontes personalizadas e cores mais vibrantes. No entanto, quando o site e o app reformulados estavam prontos para lançamento, as métricas de usuários iniciais revelaram que a nova versão era mais lenta. A Primeira exibição de conteúdo foi até 53% mais lenta, e nosso tempo medido até a interação foi até 59% mais lento.

A web na Zalando

O site da Zalando foi criado por uma equipe principal que desenvolve um framework, com mais de 15 equipes de recursos contribuindo com microsserviços de front-end. Além de oferecer suporte ao novo lançamento, também fizemos a transição de parte do nosso site para uma arquitetura mais centralizada.

A arquitetura anterior, chamada Mosaic (link em inglês), incluía uma maneira de medir o desempenho da página com métricas internas. No entanto, era difícil comparar as métricas de desempenho antes do lançamento para os usuários reais, porque não tínhamos ferramentas internas de monitoramento de desempenho do laboratório. Apesar da implantação diária, houve um ciclo de feedback de cerca de um dia para os desenvolvedores que trabalhavam em melhorias de desempenho.

As Métricas da Web e o Lighthouse para ajudar

Não ficamos totalmente satisfeitos com nossas métricas internas, porque elas não se adaptaram bem à nossa nova configuração. Mais importante ainda, eles não estavam centrados na experiência do cliente. Mudamos para as Core Web Vitals, porque elas oferecem um conjunto de métricas condensado, porém abrangente, e centrado no usuário.

Para melhorar o desempenho antes do lançamento, precisávamos criar um ambiente de laboratório adequado. Isso forneceu medições reproduzíveis, além das condições de teste que representam nosso 90o percentil dos dados de campo. Agora, os engenheiros que trabalhavam para melhorar o desempenho sabiam onde concentrar os esforços para causar o maior impacto. Já estávamos usando os relatórios de auditoria do Lighthouse localmente. Portanto, nossa primeira iteração foi desenvolver um serviço baseado no módulo de nó do Lighthouse, em que as alterações poderiam ser testadas no nosso ambiente de teste. Isso nos deu um ciclo de feedback de desempenho confiável de cerca de uma hora, o que nos permitiu alcançar o desempenho no mesmo nível e salvar nossa versão.

Dar feedback de desempenho aos desenvolvedores sobre solicitações de envio

Não queríamos parar por aí, porque queríamos aproveitar a oportunidade não apenas de ser reativo quanto à performance, mas também proativos. Passar do módulo de nó do Lighthouse para o servidor do Lighthouse CI (LHCI) não foi muito difícil. Optamos pela solução auto-hospedada para nos dar uma melhor integração com os nossos serviços existentes da empresa. Nosso aplicativo do servidor LHCI é criado como uma imagem do Docker, que é implantada em nosso cluster do Kubernetes com um banco de dados PostgreSQL e gera relatórios para nosso GitHub.

Nosso framework já dava feedback sobre o desempenho aos desenvolvedores: os tamanhos dos pacotes de componentes estavam sendo comparados aos valores de limite em cada confirmação. Agora podemos informar as métricas do Lighthouse como verificações de status no GitHub. Isso causa falha no pipeline de CI se não atenderem aos limites de desempenho, com um link para os relatórios detalhados do Lighthouse, conforme mostrado nas imagens a seguir.

Imagem da interface do GitHub mostrando linhas de verificações bem-sucedidas.
As verificações de status de CI do Lighthouse no GitHub facilitam o entendimento e a resolução da regressão antes que ela chegue à produção.
Imagem de comparação no Lighthouse CI mostrando a comparação entre a confirmação e a ramificação principal
Relatório de confirmação detalhado do Lighthouse CI em comparação com a ramificação principal.

Como ampliar a cobertura da performance

Começamos com uma abordagem muito pragmática. Atualmente, o Lighthouse só é executado em duas das nossas páginas mais importantes: a página inicial e a página de detalhes do produto. Felizmente, o Lighthouse CI facilita a extensão das configurações de execução. As equipes de recursos que trabalham em páginas específicas do nosso site podem configurar declarações e padrões de URL correspondentes. Com isso em vigor, temos certeza de que nossa cobertura de desempenho vai aumentar.

Agora, estamos muito mais confiantes ao criar versões maiores, e os desenvolvedores podem aproveitar um ciclo de feedback muito mais curto sobre o desempenho do código.