A equipe da Web da Zalando descobriu que a integração do Lighthouse CI possibilitou uma abordagem proativa à performance, com verificações de status automatizadas capazes de comparar o commit atual com a ramificação principal para evitar regressões de performance.
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, sabemos a relação entre a performance do site e a receita. No passado, testamos como o aumento artificial do tempo de carregamento nas páginas de 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 aumento no engajamento com uma taxa de rejeição mais baixa 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
O apoio da empresa nem sempre se traduz em performance
Apesar do forte comprometimento com a performance dentro da empresa, se a performance não for definida como um critério de entrega do produto, ela pode ser facilmente esquecida. Quando estávamos redesenhando o site da Zalando em 2020, nos concentramos em oferecer novos recursos enquanto mantínhamos uma excelente experiência do usuário e aplicávamos um facelift ao site com fontes personalizadas e cores mais vibrantes. No entanto, quando o site e o app redesenhados estavam prontos para lançamento, as métricas dos primeiros usuários revelaram que a nova versão era mais lenta. A First Contentful Paint ficou até 53% mais lenta, e o Tempo para interação medido foi até 59% mais lento.
A Web na Zalando
O site da Zalando foi criado por uma equipe central que desenvolveu um framework, com mais de 15 equipes de recursos contribuindo com microsserviços de front-end. Além de oferecer suporte à nova versão, também fizemos a transição de parte do nosso site para uma arquitetura mais centralizada.
A arquitetura anterior, chamada Mosaic, incluía uma maneira de medir a performance da página com métricas internas. No entanto, era difícil comparar as métricas de desempenho antes do lançamento para usuários reais, porque não tínhamos ferramentas internas de monitoramento de desempenho. Apesar de ser implantado todos os dias, os desenvolvedores que trabalham em melhorias de desempenho tinham um ciclo de feedback de cerca de um dia.
As Métricas da Web e o Lighthouse ao resgate
Não estávamos totalmente satisfeitos com as métricas internas, porque elas não se adaptaram bem à nova configuração. Mais importante, eles não se concentravam na experiência do cliente. Mudamos para as Principais métricas da Web porque elas oferecem um conjunto de métricas condensado, abrangente e centrado no usuário.
Para melhorar o desempenho antes do lançamento, precisamos criar um ambiente de laboratório adequado. Isso forneceu medições reproduzíveis, além de condições de teste que representam nosso percentil 90 dos dados de campo. Agora, os engenheiros que trabalham em melhorias de desempenho sabem onde concentrar os esforços para causar o maior impacto. Já estávamos usando os relatórios de auditoria do Lighthouse localmente. Nossa primeira iteração foi desenvolver um serviço baseado no módulo de nó do Lighthouse, em que as mudanças podiam ser testadas no ambiente de preparo. Isso nos deu um ciclo de feedback de desempenho confiável de cerca de uma hora, o que nos permitiu igualar o desempenho e salvar o lançamento.
Como dar feedback de desempenho aos desenvolvedores em solicitações de envio
Não queríamos parar por aí, porque queríamos aproveitar a oportunidade para não sermos apenas reativos à performance, mas também proativos. A transição 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-hospeda para ter uma melhor integração com os serviços da empresa. Nosso aplicativo de servidor LHCI é criado como uma imagem do Docker, que é implantada no cluster do Kubernetes com um banco de dados PostgreSQL e relata ao GitHub.
Nossa estrutura já estava fornecendo algum feedback de 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 do GitHub. Isso faz com que o pipeline de CI falhe se não atender aos limites de desempenho, com um link para os relatórios detalhados do Lighthouse, conforme mostrado nas imagens a seguir.
Como ampliar a cobertura de performance
Começamos com uma abordagem muito pragmática. No momento, 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 o padrão de URL e as declarações correspondentes. Com isso, temos certeza de que a cobertura de performance vai aumentar.
Agora temos muito mais confiança ao criar versões maiores, e os desenvolvedores podem aproveitar um ciclo de feedback muito mais curto sobre o desempenho do código.