Um relatório de cobertura de JavaScript mostra qual código foi executado durante uma observação. O código não executado durante a inicialização ainda pode alimentar um menu, checkout ou outra rota. Use o relatório para selecionar uma investigação e, em seguida, verifique as jornadas dos usuários afetados antes de alterar o pacote.
Comece com o recurso e as condições
Execute o Milten JS Scanner na página que deseja investigar. Salve a URL, a data e as condições do teste junto com o resultado. O scanner observa um carregamento de página sem cliques nem rolagem. Ele informa o carregamento dos scripts, a cobertura e os erros de JavaScript; não comprova que um arquivo seja desnecessário em todo o site.
Compare os dados de carregamento de um arquivo com seus dados de execução. Uma grande transferência, um longo período de execução e uma elevada parcela não executada são observações diferentes. Um script pode ser baixado rapidamente e ainda assim manter o thread principal ocupado. Um arquivo que não foi carregado não possui nenhuma medida de execução útil para essa execução.
Siga um exemplo ilustrativo de checkout
Suponha que app.js contenha código da página de destino e do checkout. A função de checkout não é executada quando a página de destino abre. Este é um exemplo didático, não um resultado medido em um site de cliente.
Encontre a URL do recurso e verifique como a página o importa. Abra o checkout, use o menu e visite outras páginas que compartilham o bundle. Registre as ações testadas. No Chrome DevTools Coverage, a gravação pode continuar durante as interações. Essa observação abrange mais do que uma análise restrita ao carregamento inicial.
Se o checkout precisar do código, removê-lo interromperia uma ação útil. Pode valer a pena investigar carregar esse recurso quando o usuário chega à finalização da compra. A decisão depende da aplicação e dos efeitos na próxima interação.
Use os mapas de código-fonte disponíveis
Um mapa de código-fonte relaciona um bundle gerado aos módulos originais. A visualização de módulos do Milten depende de um mapa válido, compatível e legível pelo scanner. Sem ele, essa parte do relatório fica incompleta. Os dados sobre recursos e erros ainda podem ajudar a localizar o problema.
Sem um mapa utilizável, examine o caminho de importação do recurso e a saída do build. A ausência da visualização de módulos não comprova que todo o código foi executado. O guia de mapas de código-fonte do MDN explica a relação entre o código gerado e o original.
Faça uma alteração e teste a jornada afetada
Escolha uma oportunidade confirmada, como separar um recurso usado com pouca frequência ou atrasar uma integração opcional. Mantenha a mudança pequena o suficiente para comparar. Verifique se o recurso necessário ainda funciona, se nenhum novo erro de console aparece e se a rede carrega os arquivos pretendidos.
Use o Speed Scanner para examinar o carregamento e o INP Scanner para investigar uma interação lenta. O TBT e as tarefas longas da carga inicial não medem a mesma coisa que o INP de visitas reais. Para objetos que se acumulam após navegações repetidas, use o Memory Leaks e reproduza o percurso relatado.
Compare execuções comparáveis
Repita o teste na mesma URL, com as mesmas condições de dispositivo, rede e cache. Preserve os dois relatórios e registre as interações testadas manualmente. Após publicar a alteração, verifique o build de produção: o de desenvolvimento pode se comportar de forma diferente.
Posso remover todos os bytes não executados?
Não, o resultado descreve um intervalo de observação, não todos os estados possíveis da aplicação. Teste as ações relevantes e as rotas compartilhadas antes de remover o código.
Um pacote menor garante uma página mais rápida?
Não, a ordem de carregamento, a resposta do servidor, a execução e as interações subsequentes também são importantes. Compare a jornada do usuário, bem como o tamanho do arquivo.
Analise o JavaScript de uma página. Para um contexto de carregamento mais amplo, leia velocidade do site e SEO.
