Por que métricas e metas são diferentes de “otimizar uma vez”
Performance front-end não é um projeto com fim definido: é um sistema que precisa de acompanhamento contínuo. Mudanças de produto, novos componentes, testes A/B, bibliotecas, tags de marketing e até alterações de infraestrutura podem melhorar ou piorar a experiência sem que ninguém perceba imediatamente. Por isso, este capítulo foca em como transformar performance em um processo: definir um baseline (linha de base), estabelecer metas objetivas, detectar regressões cedo e acompanhar evolução com disciplina.
O objetivo aqui não é repetir como medir Core Web Vitals ou como diagnosticar gargalos específicos. A proposta é organizar o “ciclo de vida” das métricas: o que acompanhar, como definir limites, como automatizar alertas e como criar um fluxo de decisão quando algo piora.
Conceitos essenciais: baseline, metas, regressão e evolução
Baseline (linha de base)
Baseline é o retrato confiável do desempenho atual, medido de forma consistente e representativa. Ele serve como referência para responder perguntas como: “estamos melhorando?”, “o que mudou após o deploy?” e “qual é o impacto de uma nova feature?”. Um baseline útil tem três características:
Representatividade: cobre páginas e fluxos que importam (ex.: home, listagem, detalhe, checkout, login), não apenas uma URL isolada.
Segmentação: separa por dispositivo (mobile/desktop), tipo de rede e, quando fizer sentido, por região. Um único número médio pode esconder problemas graves.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Estabilidade: é calculado com janela de tempo e amostragem suficientes para reduzir ruído (variações naturais do tráfego e do ambiente).
Metas (targets) e orçamentos (budgets)
Metas são valores desejados para métricas de experiência (por exemplo, percentis de LCP/INP/CLS). Orçamentos são limites operacionais para “insumos” que influenciam performance, como peso total de JS, quantidade de requests, tamanho de fontes, número de third-parties, ou tempo máximo de execução de scripts em uma rota.
Uma forma prática de pensar: metas dizem “como o usuário deve sentir”; orçamentos dizem “o que o time pode gastar” para chegar lá.
Regressão
Regressão é uma piora significativa em relação ao baseline, detectada após uma mudança (deploy, feature flag, alteração de dependência, nova campanha). O ponto crítico é “significativa”: pequenas oscilações são normais. Regressão é quando a piora ultrapassa um limiar definido e exige ação.
Evolução
Evolução é a melhoria sustentada ao longo do tempo, comprovada por tendências e não por um “pico” pontual. Ela aparece quando o baseline é atualizado de forma controlada e quando as metas são revisadas conforme o produto amadurece.
Escolhendo o conjunto de métricas: experiência, saúde técnica e negócio
Um acompanhamento robusto combina três camadas. Isso evita o erro comum de olhar apenas para uma métrica e perder a causa ou o impacto.
1) Métricas de experiência (o que o usuário percebe)
Core Web Vitals acompanhadas por percentis (p75 é um padrão comum para experiência “típica” em campo).
Métricas complementares úteis para contexto, como TTFB e FCP, desde que não virem “alvos” isolados sem relação com a experiência.
2) Métricas de saúde técnica (o que o sistema está fazendo)
Erros de JavaScript (taxa e top erros por rota). Erros podem degradar interações e gerar retrabalho de renderização.
Uso de CPU e tempo de execução em rotas críticas (por exemplo, tempo total de execução de scripts por navegação).
Indicadores de payload: tamanho total transferido, tamanho de JS/CSS por rota, número de requests, quantidade de third-parties.
3) Métricas de negócio (por que isso importa)
Conversão por segmento (mobile vs desktop, rede lenta vs rápida).
Engajamento (bounce, páginas por sessão, tempo até ação-chave).
Receita e funil em fluxos críticos (checkout, cadastro, lead).
Essa combinação permite responder: “piorou a experiência”, “por qual causa técnica” e “qual impacto no funil”.
Definindo baseline na prática (passo a passo)
Passo 1: selecione páginas e fluxos que representem o produto
Crie uma lista curta (comece com 5 a 10) de rotas críticas e rotas de alto tráfego. Evite tentar cobrir tudo de início. Um exemplo de recorte:
Home
Listagem (categoria ou busca)
Detalhe (produto/artigo)
Login/cadastro
Checkout (ou formulário principal)
Passo 2: defina segmentos fixos para comparação
Sem segmentação, o baseline muda “sozinho” quando o mix de tráfego muda. Defina segmentos mínimos:
Mobile e desktop
Rede (quando disponível): 4G/3G ou “rápida/lenta”
Região (se o produto for sensível a latência)
Passo 3: escolha a janela de tempo do baseline
Para reduzir ruído, use uma janela que capture variações de dia da semana e campanhas. Uma prática comum:
Baseline inicial: 14 a 28 dias (se houver tráfego suficiente).
Acompanhamento contínuo: janelas móveis de 7 e 28 dias para ver curto e médio prazo.
Passo 4: defina quais estatísticas serão “oficiais”
Evite médias simples para métricas de experiência. Prefira percentis e distribuição. Um conjunto prático:
p75 por rota e por segmento (indicador principal)
p95 para capturar cauda longa (útil para detectar problemas em dispositivos mais fracos)
Distribuição por faixas (bom/precisa melhorar/ruim) para comunicação com stakeholders
Passo 5: documente o baseline e “congele” a referência
Registre os valores do baseline em um local versionado (repositório, wiki interna ou dashboard com anotação). Inclua:
Data de início/fim da janela
Rotas e segmentos
Valores p75/p95
Observações de contexto (ex.: campanha grande, mudança de CDN, migração)
Isso evita discussões do tipo “mas antes era melhor” sem evidência comparável.
Como definir metas realistas e acionáveis
Metas por rota, não apenas globais
Uma meta única para o site inteiro costuma falhar porque rotas têm complexidades diferentes. Defina metas por grupo:
Rotas de entrada (home, landing): metas mais agressivas, pois impactam aquisição.
Rotas de navegação (listagem, busca): foco em consistência e interações rápidas.
Rotas transacionais (checkout): tolerância menor a instabilidade e travamentos; metas rígidas para interações.
Metas como “degraus” (milestones)
Se o baseline atual está distante do ideal, metas muito ambiciosas viram frustração. Use degraus trimestrais ou por ciclo de release. Exemplo de estrutura:
Meta 1: reduzir p75 em X% sem mudanças estruturais grandes
Meta 2: atingir faixa “boa” em rotas críticas após refactors planejados
Meta 3: consolidar e evitar regressões com budgets e gates
Metas com tolerância e critérios de sucesso
Defina o que é “passou” e o que é “alerta”. Exemplo de critério:
Sucesso: p75 melhora ou se mantém dentro de ±2% do baseline
Alerta: piora entre 2% e 5% por 2 dias consecutivos
Regressão: piora > 5% ou mudança de faixa (bom → precisa melhorar) em rota crítica
Os percentuais variam conforme o ruído do seu produto. O importante é existir um acordo explícito.
Performance budgets: transformando metas em limites de engenharia
Budgets evitam que o produto “gaste” performance aos poucos. Eles funcionam bem quando são simples, mensuráveis e aplicados no pipeline.
Exemplos de budgets úteis
JS por rota: limite de KB transferidos e/ou KB comprimidos (gzip/brotli) para o bundle inicial.
Número de requests críticos: limite para recursos necessários antes da primeira interação relevante.
Third-parties: limite de quantidade e lista permitida (allowlist) por rota.
Tempo de execução: limite de tempo total de tasks no carregamento (quando você tiver esse dado em laboratório).
Budgets por “camada”
Uma prática que reduz conflitos é separar budgets por responsabilidade:
Produto: número de componentes acima da dobra, widgets opcionais, variações de layout
Front-end: tamanho de bundles, dependências, CSS/JS por rota
Marketing/Analytics: tags, pixels, scripts externos e suas condições de carregamento
Isso facilita negociação: em vez de “performance piorou”, você aponta qual budget foi ultrapassado e por quem.
Detecção de regressões: do deploy ao alerta
Regressão precisa ser detectada cedo, idealmente antes de atingir grande parte dos usuários. Para isso, combine sinais de laboratório (pré-release) e de campo (pós-release).
Estratégia 1: gates no CI para impedir regressões óbvias
Use testes automatizados para bloquear PRs ou builds que ultrapassem budgets. O gate não precisa ser perfeito; ele precisa ser consistente e rápido.
Exemplo de configuração conceitual de budgets em JSON (o formato exato depende da ferramenta):
{ "budgets": [ { "path": "/", "resourceSizes": { "script": 180, "stylesheet": 60 }, "requests": 60 }, { "path": "/produto/*", "resourceSizes": { "script": 220 }, "requests": 75 } ], "thresholds": { "warn": 0.03, "fail": 0.07 }}Interpretação: para cada rota, há limites de tamanho por tipo de recurso e número de requests. Além disso, define-se tolerância de variação (warn/fail) para evitar falhas por ruído pequeno.
Estratégia 2: comparação por commit/PR com “diff” de performance
Além de um “pass/fail”, é útil mostrar o delta: quanto aumentou o JS, quantos requests a mais, qual rota foi impactada. Isso reduz o tempo de investigação.
Checklist do que um bom relatório de PR deve trazer:
Rotas testadas e ambiente
Delta de tamanho de bundles por rota
Delta de requests e recursos críticos
Top mudanças (ex.: nova dependência, novo chunk)
Estratégia 3: monitoramento pós-deploy com alertas por rota
Em produção, configure alertas para mudanças relevantes em percentis e distribuição. Boas práticas:
Alertas por segmento: regressões podem afetar apenas mobile ou rede lenta.
Alertas com janela mínima: evite alertar com poucas amostras; defina um mínimo de sessões/visitas.
Alertas com deduplicação: um incidente deve gerar um alerta, não centenas.
Um modelo simples de regra: “se p75 piorar mais que 5% em relação à média dos últimos 14 dias, por 2 horas, em rota crítica e com pelo menos N amostras, abrir incidente”.
Investigação rápida de regressões: playbook operacional
Quando um alerta dispara, o tempo até identificar a causa é o que separa um processo saudável de um caos recorrente. Um playbook reduz improviso.
Passo a passo do playbook
1) Confirme se é regressão real (e não ruído)
Verifique se há amostra suficiente no segmento afetado.
Compare com a janela anterior equivalente (ex.: mesmo dia da semana).
Veja se a regressão aparece em mais de uma rota ou apenas em uma.
2) Correlacione com mudanças recentes
Liste deploys, rollouts de feature flags e mudanças de configuração nas últimas horas/dias.
Verifique se houve inclusão/alteração de third-party, tags ou experimentos.
Considere mudanças de tráfego (campanhas) que podem alterar o mix de dispositivos.
3) Isole o escopo
É apenas mobile? Apenas uma região? Apenas usuários logados? Apenas uma rota?
O problema ocorre em navegação inicial, transições internas, ou ambos?
4) Escolha a ação: rollback, mitigação ou correção
Rollback: quando a regressão é grande e claramente ligada ao último deploy.
Mitigação: desativar feature flag, reduzir rollout, remover temporariamente third-party.
Correção: quando há causa conhecida e patch rápido (ex.: ajuste de carregamento condicional).
5) Registre o incidente com aprendizado
Registre: causa raiz, impacto, tempo de detecção, tempo de mitigação e qual budget/controle falhou. Isso alimenta melhorias no processo (novos gates, budgets mais adequados, testes adicionais).
Acompanhamento de evolução: dashboards, cadência e anotações
Dashboards que ajudam (e os que atrapalham)
Dashboards eficazes são poucos e orientados a decisão. Um conjunto enxuto:
Visão executiva: distribuição (bom/precisa melhorar/ruim) e tendência 28 dias para rotas críticas.
Visão de engenharia: p75/p95 por rota e segmento, com breakdown por versão/release quando possível.
Visão de budgets: evolução de peso de JS/CSS, requests e third-parties por rota.
Evite dashboards com dezenas de gráficos sem dono. Se ninguém toma decisão a partir de um gráfico, ele vira ruído.
Cadência de revisão
Diária (rápida): checar alertas e regressões pós-deploy em rotas críticas.
Semanal: revisar tendências, identificar rotas que pioraram gradualmente e priorizar correções.
Mensal/trimestral: revisar metas, atualizar baseline e renegociar budgets conforme roadmap.
Anotações (annotations) para explicar mudanças
Uma prática simples que aumenta muito a clareza: anotar no dashboard eventos relevantes, como:
Deploy grande
Início de campanha
Ativação de experimento
Entrada de novo third-party
Migração de infraestrutura
Sem anotações, o time perde tempo tentando “adivinhar” por que a curva mudou.
Atualizando o baseline sem mascarar problemas
Baseline não é fixo para sempre. Se o produto melhora de forma sustentada, faz sentido atualizar a referência. O risco é atualizar cedo demais e “normalizar” uma regressão.
Regras práticas para atualizar baseline
Atualize apenas após um período estável (ex.: 2 a 4 semanas) sem incidentes relevantes.
Atualize por rota e segmento, não globalmente.
Registre a mudança e o motivo (ex.: “refactor de rota X reduziu p75 em 12%”).
Baseline duplo: curto e longo prazo
Para evitar cegueira, mantenha duas referências:
Baseline curto (ex.: 14 dias): sensível a mudanças recentes e útil para regressões.
Baseline longo (ex.: 90 dias): mostra evolução real e evita que melhorias pontuais pareçam tendência.
Integração com o fluxo de desenvolvimento: Definition of Done e ownership
Performance como critério de entrega
Para não depender de “boa vontade”, inclua critérios objetivos no fluxo:
Definition of Done para features em rotas críticas: não ultrapassar budgets; não piorar métricas além da tolerância; justificar trade-offs quando houver.
Checklist de PR: impacto em bundles, inclusão de dependências, inclusão de third-party, mudanças de carregamento.
Ownership: quem responde por qual métrica
Defina responsáveis por áreas:
Um dono por rota/fluxo crítico (produto + engenharia)
Um dono por budgets (front-end platform ou guilda)
Um ponto focal para third-parties (marketing/analytics + engenharia)
Sem ownership, alertas viram “problema de todo mundo” e acabam sendo de ninguém.
Exemplo prático: montando um sistema mínimo de acompanhamento em 1 semana
Dia 1: recorte e baseline inicial
Escolha 5 rotas críticas e 2 segmentos (mobile/desktop).
Defina janela de 14 dias para baseline inicial.
Registre p75/p95 e distribuição por rota.
Dia 2: metas e tolerâncias
Defina metas por rota (degrau de melhoria) e tolerâncias de regressão.
Escreva critérios de alerta e incidente.
Dia 3: budgets simples
Defina budgets de JS por rota e limite de third-parties.
Crie allowlist de scripts externos permitidos.
Dia 4: gate no CI
Adicione verificação automática de budgets no pipeline.
Configure saída com “diff” (delta) para facilitar revisão em PR.
Dia 5: dashboard enxuto com anotações
Monte 3 visões: executiva, engenharia e budgets.
Habilite anotações de deploy e eventos.
Dia 6: alertas pós-deploy
Configure alertas por rota e segmento com mínimo de amostras.
Defina canal e responsável de triagem.
Dia 7: playbook e rotina
Documente o playbook de regressão (confirmar, correlacionar, isolar, agir, registrar).
Agende revisão semanal de tendências e mensal de metas/baseline.
