Como definir um orçamento de performance para uma landing page criada por IA

Uma landing page rápida pode ficar lenta aos poucos. Entra uma fonte. Depois um pixel, um vídeo, outra biblioteca e uma imagem maior. Nenhuma mudança parece grave isoladamente. A soma chega à produção sem que o time tenha definido quanto a página pode gastar.

Um orçamento de performance é um conjunto de limites verificáveis. Ele diz quanto JavaScript, imagem e trabalho de terceiros uma rota pode enviar, além de quão cedo o conteúdo precisa aparecer e responder.

O orçamento não escolhe produto no lugar da equipe. Ele torna o custo visível antes da republicação.

Comece pela rota e pela tarefa principal

Não use um único limite para todo o site. Uma página de campanha, uma área autenticada e uma galeria têm conteúdo e interações diferentes.

Para cada rota importante, anote:

rota:
tarefa principal:
elemento de LCP esperado:
primeira interação esperada:
recursos obrigatórios:
integrações opcionais:
dispositivo e rede prioritários:

Na landing page, a tarefa pode ser entender a oferta e enviar um formulário. Nesse caso, título, prova, CTA e formulário têm prioridade. Chat, mapa e vídeo podem esperar uma intenção real.

O guia de Core Web Vitals mostra como medir LCP, INP e CLS na URL publicada antes de definir limites.

Meça uma linha de base reproduzível

Gere uma build limpa e escolha as rotas que representam o produto. Rode pelo menos três medições por rota com a mesma versão de navegador, viewport, CPU e rede.

Registre a mediana de:

• LCP;
• CLS;
• Total Blocking Time no laboratório;
• bytes de JavaScript, CSS, imagens e fontes;
• quantidade de requisições;
• origens e requisições de terceiros;
• maior cadeia crítica;
• elemento e tamanho do LCP.

Depois consulte dados reais quando houver tráfego suficiente. O fluxo de análise de uma landing page publicada inclui Core Web Vitals agregados do Site. Uma janela vazia em um Site novo significa apenas que a agregação ainda não produziu dados.

Laboratório e campo respondem perguntas diferentes. O teste local mantém condições controladas e cabe no PR. Os dados reais mostram aparelhos, redes, rotas e interações que o laboratório não reproduziu.

Escolha poucos limites que levem a uma decisão

Um orçamento com vinte métricas vira um relatório ignorado. Comece com limites que indiquem qual recurso revisar.

A definição do web.dev para performance budget inclui tamanho, quantidade de requests e tempos percebidos. Use essa divisão como estrutura, não copie números de outro projeto.

Defina o limite a partir do que a página precisa fazer

O primeiro orçamento de uma página existente pode usar a linha de base como teto provisório. Isso bloqueia crescimento enquanto o time prepara uma redução.

Exemplo:

Página /campanha em celular simulado

LCP de laboratório: aviso acima de 2.500 ms
CLS de laboratório: erro acima de 0,10
JavaScript transferido: erro acima de 180 KB
imagens transferidas: erro acima de 650 KB
scripts de terceiros: aviso acima de 3 requests antes do LCP
cadeia crítica: aviso acima de 3 descobertas sequenciais

Esses valores são um exemplo de formato, não uma recomendação universal. Uma rota que hoje transfere 900 KB de JavaScript não deve adotar 180 KB no CI e permanecer vermelha por meses. Comece com um teto que passe na versão revisada, crie uma meta de redução separada e aperte o limite quando a correção entrar.

Para Core Web Vitals de campo, os patamares documentados pelo web.dev consideram boa experiência LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1 no percentil 75. Esses valores ajudam a definir o destino. A medição de laboratório não substitui esse percentil nem reproduz INP real.

Não use a nota geral como único orçamento

Uma nota 90 no Lighthouse é fácil de comunicar, mas pode esconder a origem da regressão. Os pesos e as curvas da nota mudam entre versões da ferramenta. A própria documentação de pontuação do Lighthouse alerta para variações de ambiente e para a distribuição dos resultados.

Mantenha a nota como sinal. Aplique limites diretos para os custos que a equipe consegue corrigir:

• bytes de script;
• bytes de imagem;
• quantidade de fontes;
• terceiros;
• LCP;
• CLS;
• Total Blocking Time.

Uma nota que continua verde não justifica adicionar 100 KB de JavaScript sem função clara.

Separe aviso de bloqueio

Nem todo limite precisa falhar o PR no primeiro dia.

Use aviso quando:

• a métrica tem variação alta;
• o time ainda está confirmando a linha de base;
• um fornecedor externo introduz ruído;
• a rota tem poucos dados reais;
• a correção precisa de uma decisão de produto.

Use erro quando:

• o valor é determinístico, como bytes gerados;
• a regressão é grande o bastante para superar o ruído;
• o time já validou o teste em execuções repetidas;
• existe uma ação clara para voltar ao limite.

Um gate que falha sem explicar o delta ensina a equipe a ignorá-lo. Mostre valor anterior, valor atual, teto, rota e recurso responsável.

Aplique limites de recursos no Lighthouse CI

O Lighthouse CI aceita assertions para tamanhos e contagens. Um arquivo de configuração pode começar assim:

{
  "ci": {
    "collect": {
      "numberOfRuns": 5,
      "url": ["http://localhost:4321/", "http://localhost:4321/campanha"]
    },
    "assert": {
      "assertions": {
        "largest-contentful-paint": [
          "warn",
          { "maxNumericValue": 2500, "aggregationMethod": "median" }
        ],
        "cumulative-layout-shift": [
          "error",
          { "maxNumericValue": 0.1, "aggregationMethod": "median" }
        ],
        "resource-summary:script:size": ["error", { "maxNumericValue": 184320 }],
        "resource-summary:image:size": ["error", { "maxNumericValue": 665600 }],
        "resource-summary:third-party:count": ["warn", { "maxNumericValue": 3 }]
      }
    }
  }
}

Na configuração de assertions, maxNumericValue usa bytes para tamanho de recursos. Um budgets.json usa kilobytes. A documentação atual do Lighthouse CI chama essa diferença de unidade explicitamente.

Rode várias coletas e escolha uma agregação declarada. Mediana costuma ser mais útil que a melhor execução. Não altere para optimistic apenas para fazer o gate passar.

Use limites diferentes por rota

A home pode ter uma imagem editorial grande. A página de preços pode ser quase toda texto. A campanha pode precisar de um único script de experimento por período.

O Lighthouse CI aceita assertMatrix para aplicar assertions por padrão de URL. Mesmo sem essa ferramenta, mantenha uma tabela versionada:

Os números continuam sendo exemplos. Meça a sua página e explique por que cada rota recebe um teto diferente.

Faça o agente mostrar a troca

Quando uma alteração ultrapassa o orçamento, peça um diagnóstico antes de aceitar a exceção.

Recurso novo: player de vídeo
Custo: +82 KB de JavaScript, +6 requests, +1 origem
Rota: /campanha
Benefício esperado: demonstração após clique
Alternativa: poster e fachada até interação
Decisão: usar fachada e manter o orçamento inicial

O artigo sobre scripts de terceiros mostra como medir por fornecedor. O guia de vídeos e iframes mostra como evitar que um player opcional consuma o carregamento inicial.

Uma exceção válida precisa de responsável, prazo e novo valor. Sem isso, o teto só cresce.

Meça o pacote e a URL publicada

O build informa tamanho de arquivos. A URL revela compressão, cache, redirects, terceiros e ordem real de carregamento. Use os dois.

Antes da publicação:

1. gere o pacote limpo;
2. rode os limites determinísticos de tamanho;
3. sirva a build no mesmo modo usado pelo CI;
4. execute as medições repetidas;
5. compare o delta com a base da branch;
6. publique apenas se o resultado passar ou tiver exceção registrada.

Depois da publicação:

1. acompanhe deploy_status até sucesso;
2. abra a URL padrão e o domínio próprio;
3. confirme headers, compressão e cache;
4. rode uma medição de fumaça na rota principal;
5. acompanhe dados reais quando a janela tiver volume suficiente.

A documentação de Publicação descreve o deploy por Version. O guia de republicação sem assets antigos ajuda a conferir se HTML e arquivos pertencem à mesma versão.

Revise o orçamento sem apagar o histórico

Um orçamento não fica congelado. A página muda, os navegadores mudam e a equipe aprende a medir melhor.

Ao revisar um teto, registre:

• valor anterior;
• valor novo;
• motivo;
• rota afetada;
• medição usada;
• responsável;
• data para nova revisão.

Reduza o limite quando uma otimização comprovada entrar. Aumente apenas quando a função nova justificar o custo e a equipe tiver testado uma alternativa menor.

Prompt para criar o orçamento

Defina um orçamento de performance para estas rotas sem publicar ainda.

Build e URL atual: [caminhos e URL]
Rotas e tarefas principais: [lista]
Público e dispositivo prioritário: [contexto]

1. Rode cinco medições comparáveis por rota.
2. Registre LCP, CLS, TBT, bytes por tipo, requests e terceiros.
3. Separe métricas de laboratório, dados reais e valores determinísticos.
4. Proponha poucos limites com aviso ou erro e explique cada ação.
5. Configure gates por rota e mostre unidades e agregação.
6. Compare a branch com a linha de base.
7. Não afrouxe limites para esconder uma regressão.

O orçamento funciona quando muda uma decisão antes do deploy. Se ele só produz uma tabela depois que a página ficou lenta, chegou tarde.