Analise o perfil de uma jornada do cliente antes de alterar o código
Escolha uma rota e uma interação importantes, como abrir a navegação, filtrar resultados ou enviar um formulário. Grave-a no painel Performance do Chrome DevTools com o navegador em um estado limpo. Repita a ação e capture uma execução com a CPU limitada, além de outra na máquina de desenvolvimento; traces de desktop podem ocultar trabalho que prejudica um celular menos potente.
Use o trace para testar uma hipótese estreita, não para culpar um componente a partir de um relatório de bundle. No gráfico de chamas Main, barras mais largas consomem mais tempo e barras empilhadas mostram a pilha de chamadas. Um triângulo vermelho em uma Task identifica uma possível long task; selecione-o e siga o link para o código iniciador. Salve traces de antes e depois para mudanças significativas.
Grave pouco antes da ação e pare após o resultado visível.
Mantenha rota, estado da conta e sequência de ação consistentes.
Atribua cada custo principal à equipe ou fornecedor capaz de alterá-lo.
Leia o trace como uma fila de trabalho
Uma tarefa longa é um limiar de investigação, não um diagnóstico completo. A especificação Long Tasks do W3C relata tarefas que duram 50 milissegundos ou mais. Em uma tarefa, procure a avaliação de JavaScript, um manipulador de eventos, o recálculo de estilo, o layout ou a pintura. A pilha de chamadas indica por onde começar; a duração mostra se o problema está no código, na renderização ou em um frame de terceiros.
Priorize custos que se repetem durante uma interação valiosa. Um handler curto ainda pode parecer lento quando dispara layout ou espera atrás de trabalho anterior. O trace é uma medição de laboratório, então confirme a correção em dispositivos representativos e, quando disponível, com telemetria de campo respeitosa à privacidade.
A análise do código durante a inicialização exige uma solução diferente de um manipulador acionado após um toque.
Encontre padrões repetidos de escrita de estilo e leitura de layout antes de refatorar.
Anexe o trace, o cenário e os maiores custos ao item de trabalho.
Envie menos código quando isso importa
Faça um inventário dos scripts por rota e finalidade. Remova pacotes não usados, duplicatas, experimentos encerrados e código de funcionalidades descontinuadas. Depois, divida funcionalidades específicas de uma rota ou pouco usadas para que sejam carregadas quando necessário, em vez de no caminho inicial. O carregamento dinâmico pode reduzir o trabalho de inicialização, mas pode criar atraso visível quando o usuário precisa do recurso imediatamente.
Pergunte se um componente precisa de um framework cliente completo, se uma utilidade duplica capacidade existente, e se HTML estático com uma pequena melhoria funcionaria. Teste o estado fallback de um módulo carregado sob demanda. A página deve adiar graciosamente uma capacidade opcional em vez de exibir um controle inoperante.
Documente quais scripts são permitidos em uma rota e por quê.
Considere isso para editores opcionais, mapas, players ou visões de relatórios.
Teste autenticação, acessibilidade, pagamento e conclusão de formulários; busque revisão qualificada quando controles forem afetados.
Divida o trabalho para que o navegador possa responder
Nomear funções menores não cria tarefas separadas para o navegador quando elas rodam de forma síncrona. Para um loop longo, processe em lotes, atualize o estado visível ao usuário e então ceda antes de continuar. Isso permite que o navegador processe entrada e renderização entre lotes.
Quando houver suporte, scheduler.yield() cede o controle da thread principal e retoma o trabalho depois; detecte o suporte ao recurso e use uma alternativa nos navegadores sem suporte. Não ceda após cada operação minúscula: isso gera sobrecarga e pode aumentar o tempo de conclusão. Escolha os limites com base em medições, preserve o cancelamento e evite que resultados obsoletos substituam um estado mais recente.
Mostre aceitação ou progresso antes de trabalho de acompanhamento não visível.
Ceda antes que o trabalho medido se torne longo, em vez de uma vez por item.
A orientação atual do web.dev não recomenda uma nova estratégia baseada em isInputPending().
Mova o cálculo, não a interface, para um worker
Um Web Worker executa um script em uma thread de background separada do thread principal de execução. Ele é adequado para parsing caro, transformação de dados, indexação de busca e outros cálculos que não precisam de acesso direto à interface. Envie uma entrada definida, retorne um resultado definido e mantenha renderização e mudanças de estado visíveis no thread principal.
Workers não são universais. Eles não podem manipular o DOM diretamente nem usar Window, e a comunicação por mensagem costuma copiar dados. Criação de worker, movimentação de dados e coordenação de erros podem superar um cálculo pequeno. Meça a interação completa, termine workers não necessários e projete um fallback se o trabalho do worker falhar.
Comece com um cálculo cujo input e output possam ser serializados e testados.
Descarte resultados gerados para um filtro, rota ou ação mais antiga.
Comunique progresso significativo através da interface normal.
Governança do JavaScript de terceiros como dependência de produção
Analytics, publicidade, experimentos, embeds sociais, players de vídeo e widgets de suporte podem adicionar requisições, avaliação de JavaScript, iframes e dependências. Um script de fornecedor pode ser necessário, mas está fora do controle direto da equipe de aplicação e pode afetar performance, privacidade, segurança e continuidade. Faça inventário do propósito, rotas, condição de carregamento, aprovador, requisito de consentimento e dono da remoção.
Quando condições e contratos permitem, compare uma página representativa com e sem uma origem de terceiros. Ferramentas de performance podem expor avaliação custosa, payloads e atribuição de long-task. Mantenha uma integração leve ou adiada somente quando seu valor documentado justificar o custo medido. Confirme conteúdo central e o trabalho da transação primária quando uma dependência opcional estiver lenta ou ausente.
Carregue uma tag apenas em rotas e condições que a necessitem.
Inclua alterações em tag-manager na revisão de performance, privacidade, segurança e rollback.
Documente e teste como desabilitar uma integração não crítica.
Faça da responsividade uma salvaguarda de release
Converta o trace vencedor em uma pequena verificação de regressão para a jornada importante. Defina interações cobertas, restrição de dispositivo ou CPU, resposta esperada e revisor. Acompanhe isso com revisão de bundle e inventário de terceiros para que um novo pacote ou tag não possa reintroduzir silenciosamente trabalho no thread principal.
Status Is UP usa essa evidência para otimização proativa e remediação segura, não para substituir monitoramento de disponibilidade em produção. Antes de uma mudança de alto risco, prepare rollback e verifique o fluxo crítico após o release. Resultados variam por dispositivo, rede, navegador, conteúdo e estado da conta; trate limites como guardrails, não garantias.
Exija traces de antes e depois para navegação compartilhada, checkout, busca ou bundles grandes.
Saiba a feature flag, configuração de tag ou versão de deploy que restaura comportamento conhecido e bom.
Faça um novo perfil após grandes releases, mudanças de fornecedor ou alterações na distribuição de dispositivos.