Comece pelas jornadas, não por uma média do site inteiro
Liste três a cinco jornadas em que o atraso tem custo claro para o cliente ou operação: acessar uma landing de campanha, encontrar um produto, enviar um formulário de lead, autenticar-se ou completar uma solicitação de suporte. Para cada jornada, descreva o início, o resultado útil, a classe de dispositivo principal e a página ou interação que precisa funcionar bem.
Dê a cada jornada sua própria linha de orçamento. Um painel pode carregar mais código que um artigo público, mas sua ação de filtragem precisa de uma meta de responsividade. Uma página de produto rica em mídia pode aceitar imagens maiores, mas precisa de um limite para a imagem principal visível. Isso evita que um caminho crítico fraco desapareça na média de todo o origin.
Nomeie o que o visitante pode ver ou fazer, como ler a oferta, ver um resultado ou receber a confirmação do formulário.
O cache pode mudar materialmente o custo de ativos, então registre se o orçamento cobre a primeira visita, visita repetida ou ambos.
Escolha desfechos e entradas controláveis
Use métricas de desfecho e limites de entrada. O Google descreve Largest Contentful Paint, ou LCP, como desempenho de carregamento; Interaction to Next Paint, ou INP, como responsividade de interação; e Cumulative Layout Shift, ou CLS, como estabilidade visual. Seus limites recomendados de boa experiência são LCP em até 2,5 segundos, INP em até 200 milissegundos e CLS em até 0,1 no percentil 75, considerados separadamente para mobile e desktop.
Adicione limites que exponham uma causa cedo: JavaScript inicial, imagens necessárias antes do conteúdo principal, transferência total para a rota, requisições de terceiros e um widget conhecido por ser caro. Monitore tamanhos de transferência comprimida de forma consistente. Um diagnóstico como Time to First Byte ajuda a investigar carregamento lento, mas não é por si só o resultado do cliente.
Use LCP quando a jornada depender do conteúdo principal ficar visível.
Use INP em campo para busca, filtragem, menus e checkout; use um proxy de laboratório apenas antes de existirem dados em campo.
Limite a rota inicial e os maiores contribuintes para que os responsáveis saibam o que precisa mudar após uma violação.
Defina números a partir da sua linha de base
Capture uma linha de base para cada jornada. No PageSpeed Insights, distinga os dados de campo do Chrome User Experience Report (CrUX), que agregam experiências reais de usuários Chrome, dos dados de laboratório do Lighthouse, que são um teste controlado. Dados de campo verificam a experiência chegando aos usuários; testes de laboratório tornam uma mudança repetível antes da release.
Segmente ao menos por mobile e desktop e, quando possível, por template crítico ou URL. O PageSpeed Insights pode recorrer de dados de URL para dados de origin; algumas páginas não têm dados CrUX. Nesse caso, rotule como linha de base de laboratório e adicione medição real do usuário para jornadas importantes. Mantenha a URL de teste, perfil de dispositivo e rede, estado do cache, data e versão da ferramenta com cada linha de base.
Escolha uma meta que represente uma melhoria planejada sobre a linha de base e teste-a em condições representativas. Um orçamento que bloqueia releases normais é contornado; um acima da experiência de hoje não protege ninguém.
O percentil 75 é o valor no qual 75% das experiências observadas ficam em ou abaixo dele; não é uma média.
Transforme o orçamento numa regra de release
Mantenha o orçamento em um lugar versionado e revisável ao lado do código ou checklist de release. Cada linha precisa da jornada, métrica, perfil de teste ou população, limiar de aviso, limiar de erro, dono, método de medição e rota de exceção. O MDN recomenda níveis de aviso e erro: o aviso serve para planejamento pró‑ativo, enquanto o erro é um limite superior com efeito negativo perceptível.
Automatize checagens confiáveis. Um empacotador (bundler) pode rejeitar um ativo ou ponto de entrada superdimensionado; o webpack suporta limites máximos de asset e entry‑point e hints de erro em produção. Execute testes de laboratório repetíveis para a jornada afetada em pull requests ou candidatas à release. Mantenha métricas de campo para verificação e priorização pós‑release, em vez de usá‑las como uma trava de build pouco confiável.
Quando um limite falha, reduza um ativo, adie código não essencial, altere a experiência, divida a release ou aprove uma exceção. Não aumente silenciosamente o limite para passar o build.
Registre um dono de produto e técnico, impacto ao cliente, data de expiração e tarefa de remediação antes da release.
Bloqueie um limiar de erro reproduzível em uma jornada protegida; notifique e investigue limiares de aviso.
Verifique e remedie após o lançamento
O peso da página não prevê a experiência completa. Ordem de requisição, trabalho que bloqueia renderização, capacidade do dispositivo, condições de rede, cache e terceiros também importam. Mantenha limites de entrada para detectar crescimento e medidas de desfecho para testar se o caminho é utilizável. A interface W3C Resource Timing expõe tempos de recurso e tamanhos de transferência, codificados e decodificados, para diagnóstico mais profundo. Dados de temporização cross‑origin podem ser restritos por permissões de timing, então uma waterfall incompleta não prova ausência de custo de terceiros.
Revise resultados de campo após mudanças significativas de template, plataforma, tags de marketing ou tráfego. Se o LCP piorar, inspecione a resposta do servidor, o recurso LCP e o trabalho que bloqueia a renderização. Se o INP piorar, inspecione interações reais; o Lighthouse não pode medir INP porque não há entrada de usuário, embora Total Blocking Time seja um proxy de laboratório. Use o workflow de otimização proativo da SIU para triagem de uma violação, estabilizar o caminho crítico e verificar a correção no mesmo contexto de medição.
Exceções expiradas revelam rapidamente dívida de desempenho temporária que virou permanente.