Otimização da interatividade das páginas de detalhes do produto para reduzir em 90% o potencial máximo de FID no Lighthouse e uma melhoria de 9% na FID no Chrome User Experience Report.
O Mercado Livre é o maior ecossistema de e-commerce e pagamentos da América Latina. Ele está presente em 18 países e é líder de mercado no Brasil, no México e na Argentina, com base em visitantes únicos e visualizações de página.
O desempenho na Web é o foco da empresa há muito tempo, mas eles recentemente formaram uma equipe para monitorar o desempenho e aplicar otimizações em diferentes partes do site.
Neste artigo, resumimos o trabalho feito por Guille Paz, Pablo Carminatti e Oleh Burkhay, da equipe de arquitetura de front-end do Mercado Livre, para otimizar uma das Core Web Vitals: latência na primeira entrada (FID, na sigla em inglês) e o proxy do laboratório, Tempo total de bloqueio (TBT, na sigla em inglês).
90%
de redução no potencial máximo de FID no Lighthouse
9%
Mais usuários percebem a FID como "rápida" no CrUX
Tarefas longas, latência na primeira entrada e tempo total de bloqueio
A execução de códigos JavaScript caros pode levar a tarefas longas, que são executadas por mais de 50 ms na linha de execução principal do navegador.
A latência na primeira entrada (FID, na sigla em inglês) mede o tempo entre o momento em que o usuário interage com uma página pela primeira vez (por exemplo, ao clicar em um link) e o momento em que o navegador consegue começar a processar gerenciadores de eventos em resposta a essa interação. Um site que executa códigos JavaScript caros provavelmente terá várias tarefas longas, o que acaba afetando negativamente a FID.
Para oferecer uma boa experiência ao usuário, os sites precisam ter uma latência na primeira entrada de menos de 100
milissegundos:
Embora o site do Mercado Livre tenha um bom desempenho na maioria das seções, eles descobriram no Relatório de experiência do usuário do Chrome que as páginas de detalhes do produto tinham uma FID ruim. Com base nessas informações, a empresa decidiu concentrar os esforços em melhorar a interatividade das páginas de produtos no site.
Essas páginas permitem que o usuário realize interações complexas. A meta era a otimização de interatividade, sem interferir com uma funcionalidade valiosa.
Medir a interatividade das páginas de detalhes do produto
A FID requer um usuário real e, portanto, não pode ser medida no laboratório. No entanto, a métrica Tempo total de bloqueio (TBT, na sigla em inglês) é mensurável por laboratório, correlaciona bem com a FID no campo e também captura problemas que afetam a interatividade.
No trace a seguir, por exemplo, embora o tempo total gasto na execução de tarefas na linha de execução principal seja de 560 ms, apenas 345 ms desse tempo são considerados tempo total de bloqueio (a soma das partes de cada tarefa que excede 50 ms):
O Mercado Livre usou o TBT como uma métrica de proxy no laboratório para medir e melhorar a interatividade das páginas de detalhes dos produtos no mundo real.
Esta é a abordagem geral que eles adotaram:
- Use WebPageTest para determinar exatamente quais scripts estavam mantendo a linha de execução principal ocupada em um dispositivo real.
- Use o Lighthouse para determinar o impacto das mudanças em Max Potential First Input Delay (Max Potential FID).
Usar o WebPageTest para visualizar tarefas longas
O WebPageTest (WPT) é uma ferramenta de desempenho da Web que permite executar testes em dispositivos reais em diferentes locais ao redor do mundo.
O Mercado Livre usou a WPT para reproduzir a experiência dos usuários, escolhendo um tipo de dispositivo e um local semelhantes aos usuários reais. Especificamente, eles escolheram um dispositivo Moto 4G e Dulles, Virgínia, porque queriam se aproximar da experiência dos usuários do Mercado Livre no México. Ao observar a visualização da linha de execução principal da WPT, o Mercado Livre descobriu que havia várias tarefas longas consecutivas bloqueando a linha de execução principal por dois segundos:
Analisando a hierarquia correspondente, eles descobriram que uma parte considerável desses dois segundos veio do módulo de análise. O tamanho do pacote principal do aplicativo era grande (950 KB) e levava muito tempo para analisar, compilar e executar.
Usar o Lighthouse para determinar a FID do potencial máximo
O Lighthouse não permite escolher entre diferentes dispositivos e locais, mas é uma ferramenta muito útil para diagnosticar sites e receber recomendações de performance.
Ao executar o Lighthouse nas páginas de detalhes do produto, o Mercado Livre descobriu que o FID do potencial máximo era a única métrica marcada em vermelho, com um valor de 1710ms.
Com base nisso, o Mercado Livre definiu uma meta de melhorar a pontuação de FID de potencial máximo em uma ferramenta de laboratório, como o Lighthouse e o WebPageTest, presumindo que essas melhorias afetariam os usuários reais e, portanto, aparecerão em ferramentas de monitoramento de usuários reais, como o Chrome User Experience Report.
Otimizar tarefas longas
Primeira iteração
Com base no trace de linha de execução principal, o Mercado Livre definiu a meta de otimizar os dois módulos que executavam códigos caros.
A empresa começou a otimizar o desempenho do módulo de monitoramento interno. Esse módulo continha uma tarefa pesada da CPU que não era essencial para o funcionamento do módulo e, portanto, poderia ser removida com segurança. Isso levou a uma redução de 2% no JavaScript para todo o site.
Depois disso, a equipe começou a melhorar o tamanho geral do pacote:
O Mercado Livre usou o webpack-bundle-analyzer (link em inglês) para detectar oportunidades de otimização:
- Inicialmente, eles exigiam o módulo Lodash completo. Ele foi substituído por uma solicitação por método para carregar apenas um subconjunto do Lodash em vez de toda a biblioteca, e usada em conjunto com lodash-webpack-plugin para reduzir ainda mais o Lodash.
A equipe também aplicou as seguintes otimizações do Babel:
- Usar @babel/plugin-transform-runtime para reutilizar os auxiliares do Babel em todo o código e reduzir consideravelmente o tamanho do pacote.
- Usar o babel-plugin-search-and-replace para substituir tokens no tempo de compilação, a fim de remover um arquivo de configuração grande dentro do pacote principal.
- Adição de babel-plugin-transform-react-remove-prop-types para economizar alguns bytes extras removendo os tipos de propriedade.
Como resultado dessas otimizações, o tamanho do pacote foi reduzido em aproximadamente 16%.
Medir o impacto
Com essas mudanças, as tarefas longas consecutivas do Mercado Livre diminuíram de dois segundos para um segundo:
O Lighthouse mostrou uma redução de 57% na latência máxima na primeira entrada:
Segunda iteração
A equipe continuou se aprofundando em tarefas longas para encontrar melhorias subsequentes.
Com base nessas informações, a empresa decidiu implementar as seguintes mudanças:
- Continue reduzindo o tamanho do pacote principal para otimizar o tempo de compilação e análise, por exemplo, removendo dependências duplicadas nos diferentes módulos.
- Aplique a divisão de código no nível do componente para dividir o JavaScript em partes menores e permitir um carregamento mais inteligente dos diferentes componentes.
- Adie a hidratação do componente para permitir um uso mais inteligente da linha de execução principal. Essa técnica é conhecida como hidratação parcial.
Medir o impacto
O trace de WebPageTest resultante mostrou blocos ainda menores de execução de JS:
Além disso, o tempo de FID do potencial máximo no Lighthouse foi reduzido em 60%adicional:
Visualize o progresso de usuários reais
Embora ferramentas de teste de laboratório como WebPageTest e Lighthouse sejam ótimas para iterar soluções durante o desenvolvimento, o verdadeiro objetivo é melhorar a experiência para usuários reais.
O Relatório de experiência do usuário do Chrome apresenta métricas sobre a experiência real dos usuários do Chrome em destinos comuns na Web. Os dados do relatório podem ser obtidos executando consultas no BigQuery, PageSpeedInsights ou API CrUX.
O painel CrUX é uma maneira fácil de visualizar o progresso das principais métricas:
Próximas etapas
A performance na Web nunca é uma tarefa concluída, e o Mercado Livre entende o valor que essas otimizações trazem aos usuários. Embora a empresa continue aplicando várias otimizações em todo o site, incluindo a pré-busca em páginas de informações do produto, otimizações de imagem e outras, a empresa continua adicionando melhorias às páginas de informações do produto para reduzir o tempo total de bloqueio (TBT, na sigla em inglês), usando FID de proxy e muito mais. Essas otimizações incluem:
- Iteração na solução de divisão de código.
- Melhorar a execução de scripts de terceiros.
- Melhorias contínuas no agrupamento de recursos no nível do bundler (webpack).
O Mercado Livre tem uma visão holística da performance. Então, embora continue otimizando a interatividade no site, também começou a avaliar oportunidades de melhoria nas outras duas Core Web Vitals atuais: LCP (Maior exibição de conteúdo) e CLS (Mudança de layout cumulativa) ainda mais.