Este estudo de caso descreve um fluxo de trabalho passo a passo para depurar e melhorar o INP
no React usado pela Trendyol com o uso de ferramentas do Google, como PageSpeed
Insights (PSI), Chrome DevTools e a API scheduler.yield.
Dois componentes essenciais de qualquer site de e-commerce são a página de informações do produto e a página de detalhes do produto (PDP). O tráfego de e-commerce geralmente vem de páginas de informações do produto, seja por meio de campanhas por e-mail, mídias sociais ou publicidade on-line. Por isso, é fundamental garantir que a experiência do PLP seja cuidadosamente pensado para reduzir o tempo necessário para fazer uma compra. Priorização a qualidade da experiência do usuário é essencial para o sucesso. Publicações de pesquisa como Milliseconds Make Millions (em inglês) já revelaram a importância o impacto do desempenho na Web nas vontade de gastar dinheiro e engajar com marcas on-line.
A Trendyol é uma plataforma de e-commerce com cerca de 30 milhões de clientes e 240.000 vendedores, o que nos impulsionou a nos tornarmos o primeiro negócio na Turquia com um valor de mais de US $10 bilhões e uma das principais plataformas de e-commerce do o mundo.
Para alcançar o objetivo de proporcionar a melhor experiência do usuário possível em grande escala mantendo a flexibilidade do conteúdo e trabalhando com uma versão mais antiga do A React, Trendyol se concentrou em Interaction to Next Paint (INP) como uma métrica importante para melhorar. Este estudo de caso descreve a jornada da Trendyol de melhorar a INP em sua O PLP, o que resulta em uma redução de 50% do INP e um aumento de 1% na pesquisa métrica de negócios resultante.
Processo de investigação INP da Trendyol
O INP mede a capacidade de resposta de um site em relação à entrada do usuário. Um bom INP indica que o navegador seja capaz de responder de forma rápida e confiável a todas as entradas e pintar a página novamente, que é um componente essencial de uma boa experiência do usuário.
A jornada da Trendyol para melhorar a INP em seu PLP começou com uma análise detalhada a experiência do usuário antes de qualquer melhoria ser feita. Com base em um relatório PSI, a experiência real do usuário do PLP teve um INP de 963 milissegundos um dispositivo móvel, conforme mostrado na próxima figura.
Para garantir uma boa capacidade de resposta, os proprietários de sites devem buscar um INP abaixo ou no 200 milissegundos, o que significa que, naquela época, o INP da Trendyol estava no "ruim" do intervalo 10.240.0.0/16.
Felizmente, o PSI fornece os dois dados de campo para páginas incluídas no registro de usuários do Chrome
Experience Report (CrUX, na sigla em inglês) e dados detalhados de diagnóstico do laboratório. Estou conferindo o laboratório
dados, a auditoria de tempo de execução JavaScript do Lighthouse sugeriu que o
O script search-result-v2 estava ocupando a linha de execução principal por mais tempo do que o outro
scripts na página.
Para identificar gargalos reais, usamos o painel de desempenho do Chrome DevTools para resolver problemas da experiência de PLP e identificar a origem do problema. Emulação de desempenho de dispositivos móveis com lentidão de CPU 4x no Chrome DevTools revelou uma tarefa de 700 a 900 milissegundos na linha de execução principal. Se o servidor linha de execução estiver ocupada com outras tarefas por mais de 50 milissegundos, ela poderá a impossibilidade de responder às entradas dos usuários em tempo hábil, resultando em um problema experiência do usuário.
A tarefa mais longa foi causada por um callback da API Intersection Observer no script de resultados da pesquisa em um componente do React. Nesse ponto, começamos dividir essa tarefa longa em pequenos pedaços para dar ao navegador mais oportunidades de responder a trabalhos de maior prioridade, incluindo interações do usuário.
O uso da operação setState, que aciona o React,
a rerenderização dentro do callback Intersection Observer tem um alto custo,
o que pode ser problemático para dispositivos mais simples, ocupando a linha de execução principal para
muito longo.
Um método que os desenvolvedores usaram para dividir as tarefas em outras menores
envolve setTimeout. Usamos essa técnica para adiar a execução da
setState para uma tarefa separada. Embora setTimeout permita adiar
execução do JavaScript, ele não fornece nenhum controle sobre a prioridade. Isso fez
participar do teste de origem do scheduler.yield para garantir a
continuação da nossa execução de script após acessar a linha de execução principal:
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
Adicionar esse método de rendimento ao código PLP resultou em um INP aprimorado, já que o tarefa principal longa foi dividida em uma série de tarefas menores, o que permite trabalhos com maior prioridade, como interações do usuário e trabalho de renderização subsequente, para ocorrer antes do que aconteceriam de outra forma.
A Trendyol usa o framework PuzzleJs para implementar um microfront-end. usando o React v16.9.0. Com o React 18, o mesmo desempenho pode ser mas por vários motivos, a Trendyol não consegue melhorar tempo de resposta.
Resultados de negócios
Para medir o impacto da melhoria do INP implementada, fizemos um teste A/B para como as métricas de negócios foram afetadas. No geral, nossas mudanças no PLP resultaram em uma melhoria significativa, incluindo uma redução de 50% no INP e uma redução de 1% de aumento nas taxas de cliques da página de listagens para a página de detalhes do produto por sessão de usuário. Na figura a seguir, você pode ver como a INP melhorou PLP ao longo do tempo:
Conclusão
Otimizar o INP é um processo complexo e iterativo, mas pode ser mais fácil com um fluxo de trabalho claro. Uma abordagem simples para depurar e melhorar seu o INP do seu site depende da coleta ou não dos seus próprios dados de campo. Se você não são, o PSI e o Lighthouse são um bom ponto de partida. Depois de identificar páginas com problemas, use o DevTools para se aprofundar e tentar reproduzir problemas.
Ir à linha de execução principal de vez em quando para dar ao navegador mais
oportunidades para trabalhos urgentes tornará seu site mais responsivo, garantindo
que seus clientes tenham uma melhor experiência do usuário. APIs de programação mais recentes
como scheduler.yield(), facilitam essa tarefa.
Um agradecimento especial a Jeremy Wagner, Barry Pollard e Houssein Djirdeh das Google e à equipe de engenharia da Trendyol pela contribuição deles.