Um filtro demora para atualizar, um menu abre com atraso ou o texto digitado aparece depois de uma pausa, mesmo que a página carregue rápido. Investigue a resposta às ações e o trabalho de JavaScript. Em aplicações com Workers ou iframes, examine também a troca de mensagens.
Por que um site rápido pode demorar para responder às ações
Após o clique, o navegador precisa tratar o evento, executar JavaScript e mostrar o frame atualizado. Se o thread principal estiver ocupado, algum trabalho aguardará sua vez. Portanto, uma boa velocidade de carregamento não garante resposta rápida de menus, filtros e formulários.
Mover cálculos para um Web Worker pode liberar o thread principal, mas acrescenta troca de dados. A janela da página, os Workers e os iframes trocam mensagens por postMessage(). Uma mensagem enviada pode precisar aguardar o processamento.
Onde ocorrem atrasos na fila de mensagens
Comece com três razões possíveis:
- O receptor está executando uma tarefa síncrona de longa duração. A nova mensagem será processada quando o thread estiver livre.
- Existem muitas mensagens. Mesmo manipuladores rápidos criam uma fila se o trabalho chegar mais rápido do que está sendo processado.
- Uma grande quantidade de dados é transferida. A serialização no remetente e a desserialização no destinatário exigem tempo nos respectivos threads.
Por exemplo, uma busca envia uma solicitação ao Worker a cada letra digitada. Se ele ainda calcula os resultados anteriores, as solicitações se acumulam. O usuário já terminou de digitar, mas a aplicação continua processando a entrada antiga. Meça a frequência das mensagens, o tempo de processamento e o volume transferido.
Como o INP mede a resposta da página
INP, Interaction to Next Paint, avalia a resposta a cliques, toques e teclas durante a visita. O valor representa uma das interações mais lentas, considerando as regras de exclusão de valores discrepantes. A latência inclui a espera pelo processamento, a execução dos manipuladores e o tempo até a exibição do próximo quadro.
Um bom valor de INP não é superior a 200ms. A faixa acima de 200 a 500 ms requer melhoria, acima de 500 ms é considerada ruim. Para avaliar um site, o percentil 75 de visitas é usado separadamente em dispositivos móveis e desktop.
A fila de mensagens pode contribuir para essa latência quando seu processamento ocupa o thread principal e interfere na entrada ou na renderização. Mas o tempo de resposta do Worker não pode ser automaticamente considerado INP.
Voltemos à pesquisa: a letra inserida pode aparecer imediatamente e os resultados serão atualizados posteriormente. O próximo quadro já foi mostrado, embora o trabalho útil ainda não tenha sido concluído. Nesse cenário, meça a resposta à entrada e o tempo aos resultados reais separadamente. Um indicador de carregamento rápido não prova que a pesquisa em si se tornou mais rápida.
Verificação de INP e análise de JavaScript em Milten
Verificação de INP ajuda a investigar atrasos de interação em uma execução de teste. Selecione a página com a ação problemática: menu, catálogo, formulário ou carrinho. No relatório, verifique quais interações foram concluídas e quais causas de atraso foram encontradas. A conclusão aplica-se a esta execução de teste e às suas condições.
JS Scanner analisa JavaScript ao carregar uma única página no Chromium, sem cliques ou rolagem. Ele mostra tamanhos e cargas de script, execução de código, tarefas de longa execução, erros e scripts com um nome de host diferente. Um mapa de módulos dentro de pacotes estará disponível se o site fornecer mapas de código-fonte.
Compare relatórios para selecionar uma área a ser inspecionada. Um arquivo pesado em JS Scanner pode explicar o carregamento ao iniciar a página, mas sua presença ainda não comprova o motivo do clique lento. O comportamento após o carregamento precisa ser reproduzido separadamente. Ambas as ferramentas ajudam você a restringir sua pesquisa; elas não fornecem um rastreamento de todas as mensagens entre todas as janelas e Workers.
O código que não foi executado durante o carregamento pode ser necessário após um clique ou em outro estado da página. Verifique esses scripts antes de removê-los. Um script com um nome de host diferente também não é necessariamente supérfluo: o próprio CDN do projeto pode cair neste grupo.
Como encontrar a causa de um INP ruim
- Grave as etapas de reprodução. Especifique o estado da página, do dispositivo e da interface. Por exemplo: abra um catálogo, insira rapidamente uma consulta e selecione um filtro.
- Se houver RUM ou CrUX, use os dados de campo para selecionar o problema mais perceptível. A execução laboratorial não substitui as estatísticas de visitas reais.
- Execute uma verificação INP e combine a cobertura do relatório com a atividade problemática. Caso não tenha sido reproduzido, examine-o separadamente no navegador.
- Explore o carregamento de JavaScript via JS Scanner. Selecione arquivos suspeitos e tarefas longas que podem se sobrepor com atraso.
- Registre o cenário problemático no DevTools. Para um Worker ou iframe, rastreie a mensagem enviada, o processamento iniciado, a resposta e a atualização da tela. Os IDs de solicitação ajudarão a distinguir a resposta à entrada antiga da atual.
- Após a correção, repita os mesmos passos com o mesmo dispositivo, CPU e configurações de rede. Compare várias execuções e verifique os dados de campo à medida que eles se acumulam.
O que mudar para otimizar o INP
Otimização de INP começa reduzindo o trabalho que atrasa o próximo quadro. Reduza os manipuladores síncronos, divida tarefas longas e deixe o navegador renderizar feedback antes de cálculos desnecessários.
Em uma aplicação com Workers, confira se todo o trabalho enviado é necessário. Para buscas, agrupe atualizações frequentes e descarte resultados desatualizados. Ajuste o intervalo de debounce à interface: um intervalo longo demais atrasa a própria busca.
Reduza as mensagens às informações de que o destinatário precisa. Em vez de todo o catálogo, após cada mudança de filtro, às vezes basta passar os parâmetros de consulta. Para dados binários adequados, considere objetos transferíveis. Considere a transferência de propriedade: o buffer transferido fica indisponível para o remetente.
Teste cada hipótese separadamente. Se você reduziu o tamanho da mensagem, compare o tempo de transmissão e processamento. Se você moveu o cálculo, verifique a resposta da interface e o tempo até o resultado. Isso mostrará qual edição ajudou.
É possível ver automaticamente a sobrecarga da fila?
A proposta do WICG agora busca estender a API Long Animation Frames para detectar congestionamento persistente de filas de tarefas em documentos e Workers. A medição de mensagens individuais e dos custos de serialização não faz parte do escopo atual.
A proposta é experimental. Não faça a investigação depender dos primeiros exemplos de observação de delayed-message. Comece com um percurso reproduzível, o INP Scanner, a análise de JavaScript e uma gravação no DevTools. Acompanhe uma ação lenta até o resultado de que o usuário precisa.
