Core Web Vitals em sites criados por IA: como medir e corrigir

Um site criado por IA pode parecer rápido no computador em que nasceu e ainda entregar uma experiência lenta ou instável para quem abre a URL em outro celular, rede ou navegador.

Isso acontece porque “carregou para mim” não mede quando o conteúdo principal apareceu, quanto uma interação demorou para responder nem se a interface mudou de lugar durante o uso. Core Web Vitals transforma essas três partes da experiência em métricas observáveis.

O agente pode ajudar a localizar imagens pesadas, JavaScript excessivo e elementos sem dimensões. Mas a ordem importa: medir a página publicada, identificar a métrica afetada, corrigir a causa provável, validar e republicar. Pedir apenas “deixe o site mais rápido” costuma produzir muitas mudanças sem evidência.

O que os Core Web Vitals medem

Os Core Web Vitals atuais são LCP, INP e CLS:

A avaliação usa o 75º percentil das visitas, separado entre dispositivos móveis e desktop. Portanto, uma execução rápida do Lighthouse não prova que a maioria dos visitantes recebe a mesma experiência.

A referência oficial de Web Vitals explica os limites e a metodologia. Trate os valores como metas de experiência, não como uma pontuação para decorar.

Meça a versão que realmente está no ar

Comece pela URL pública, não pelo preview do editor.

O PageSpeed Insights combina duas fontes:

• dados de campo, vindos do Chrome UX Report (CrUX), quando existe volume suficiente de visitas;
• dados de laboratório, gerados pelo Lighthouse em uma condição controlada.

Dados de campo representam experiências reais agregadas. Dados de laboratório são mais reproduzíveis e ajudam a investigar a causa. Eles podem discordar sem que um dos dois esteja necessariamente errado.

Uma página nova ou com pouco tráfego pode não ter dados CrUX no nível da URL. Nesse caso, registre o resultado de laboratório como linha de base, teste em celular real quando possível e volte aos dados de campo depois. O guia oficial sobre diferenças entre laboratório e campo ajuda a interpretar esse intervalo.

Antes de mudar qualquer arquivo, anote:

URL medida:
data e horário:
versão ou commit publicado:
dispositivo:
fonte do dado: campo ou laboratório
LCP:
INP:
CLS:
elemento ou diagnóstico destacado:

Sem essa linha de base, uma nota melhor depois da republicação pode ser apenas variação entre execuções.

Descubra qual métrica pede atenção

Não tente corrigir as três métricas ao mesmo tempo. Comece pela que está fora da faixa boa e use o diagnóstico para chegar ao elemento responsável.

LCP: o conteúdo principal aparece tarde

Em landing pages, o elemento de LCP costuma ser a imagem hero ou um grande bloco de texto na primeira dobra.

Problemas frequentes em páginas geradas por IA incluem:

• imagem hero muito maior que o espaço em que será exibida;
• arquivo PNG quando uma versão WebP ou AVIF seria suficiente;
• imagem principal carregada com loading="lazy";
• recurso principal inserido somente depois que JavaScript executa;
• fonte bloqueando a renderização do título;
• CSS e scripts grandes atrasando a pintura;
• redirecionamentos antes da URL final.

O elemento principal deve ser descoberto cedo no HTML. A orientação oficial para otimizar LCP recomenda não aplicar lazy loading à imagem de LCP e investigar separadamente tempo de resposta, descoberta do recurso, duração do download e atraso de renderização.

Um pedido cirúrgico para o agente seria:

O PageSpeed identificou [elemento] como LCP desta URL.
Inspecione o HTML final, o tamanho do arquivo e a ordem de carregamento.

Proponha a menor mudança que antecipe a descoberta ou reduza o custo
desse recurso. Não altere copy, layout, tracking nem imagens fora da
primeira dobra. Mostre o diagnóstico antes de editar.

Comprimir a imagem pode ajudar, mas não resolve um elemento escondido até a execução de JavaScript. Corrija a parte do carregamento que o relatório realmente aponta.

INP: a página reage tarde ao toque ou clique

INP observa a responsividade das interações ao longo da visita. Uma landing estática tende a ter pouco JavaScript, mas widgets, menus, carrosséis, animações, formulários e scripts de terceiros podem ocupar a thread principal.

Investigue:

• listeners que fazem trabalho demais a cada clique ou digitação;
• validação pesada executada em todo input;
• grandes pacotes JavaScript carregados para um componente pequeno;
• animações acionadas por script quando CSS seria suficiente;
• widgets de chat, vídeo ou rastreamento iniciados antes de serem necessários;
• tarefas longas que bloqueiam a próxima pintura.

Peça ao agente para localizar a interação lenta e o código executado naquele caminho. Remover toda interatividade para melhorar uma métrica não é uma correção aceitável se a página deixa de cumprir o objetivo.

CLS: elementos mudam de lugar

CLS alto aparece quando o visitante tenta ler ou tocar em algo e o conteúdo se desloca.

As causas comuns são:

• imagens, vídeos ou iframes sem largura e altura reservadas;
• banner ou formulário inserido acima do conteúdo existente;
• fonte que troca de tamanho e reorganiza a primeira dobra;
• animações que alteram propriedades de layout;
• mensagens de validação que empurram campos e botões;
• conteúdo assíncrono sem espaço previsto.

Defina dimensões ou aspect-ratio, reserve a área de componentes tardios e prefira animações com transform e opacity quando fizer sentido. Testes de laboratório podem não capturar deslocamentos que acontecem mais tarde; a documentação sobre CLS recomenda complementar o laboratório com dados de campo.

Revise os padrões típicos de código gerado por IA

Agentes são bons em criar uma primeira versão visual, mas podem repetir soluções caras porque elas produzem impacto imediato:

• várias famílias e pesos de fonte;
• imagens de fundo enormes;
• bibliotecas completas para uma única animação;
• carrossel automático na primeira dobra;
• efeitos associados ao movimento do mouse ou ao scroll;
• hidratação de toda a página para controlar um detalhe;
• elementos decorativos duplicados em mobile e desktop.

Não remova tudo por princípio. Relacione cada recurso ao objetivo da página e ao diagnóstico medido.

Uma matriz simples ajuda:

Essa revisão preserva o que faz a página funcionar e retira o que só aumenta a superfície técnica.

Corrija uma causa por rodada

Uma boa rodada tem:

1. uma métrica prioritária;
2. um elemento ou caminho suspeito;
3. uma alteração pequena;
4. checks locais;
5. nova publicação;
6. nova medição comparável.

Por exemplo:

Fato: a imagem hero é o LCP e começa a carregar tarde.
Hipótese: o recurso só é descoberto depois do CSS.
Mudança: renderizar a imagem no HTML inicial com dimensões explícitas
e prioridade adequada, preservando enquadramento e texto.
Validação: build, inspeção mobile, URL publicada e nova medição.

Evite misturar troca de framework, nova copy, remoção de seções e compressão de todas as imagens na mesma versão. Mesmo que a nota melhore, você não saberá qual alteração produziu o efeito.

Valide antes de republicar

Performance não substitui qualidade. Antes de colocar a correção no ar:

• rode os checks do projeto;
• verifique visualmente larguras pequenas e grandes;
• teste navegação por teclado e foco;
• envie o formulário de ponta a ponta;
• confirme que links e analytics continuam funcionando;
• compare a imagem e a primeira dobra com a versão aprovada;
• execute o checklist de QA para landing pages com IA.

Se a mudança alterou o pacote final, publique todos os arquivos relacionados. A documentação de Publicação explica o formato esperado para uma página isolada ou um Site com múltiplos arquivos.

Republique no mesmo endereço

Uma correção de desempenho não precisa criar outro Site. Identifique o destino pelo Site ID, gere novamente o pacote completo e publique a nova versão no mesmo endereço.

O fluxo de republicação com agente de IA ajuda a preservar slug, URL e contexto de medição. Depois que o deploy terminar:

1. abra a URL final;
2. confirme que a versão nova está ativa;
3. repita o teste com dispositivo e condições semelhantes;
4. registre o novo resultado;
5. observe dados de campo quando houver volume suficiente.

Não declare vitória por uma única execução. Resultados de laboratório variam, e dados de campo refletem uma janela de visitas.

Combine desempenho com sinais de uso

O Analytics do Site no Ar não mede Core Web Vitals. Ele mostra pageviews, visitantes, tempo de engajamento, páginas, origens, países, dispositivos e respostas 404 em janelas de 7, 30 ou 90 dias.

Use essas dimensões para priorizar a investigação, não para fabricar causalidade. Se a maior parte do tráfego é mobile, comece a revisão de performance pelo mobile. Se uma rota concentra visitas, meça essa rota antes de otimizar uma página quase sem acesso.

O guia de Analytics com agente de IA mostra como separar fatos, hipóteses e decisões. Core Web Vitals acrescenta uma camada diferente: a qualidade de carregamento, interação e estabilidade percebida.

Um prompt completo para conduzir a rodada

Analise os Core Web Vitals da URL [URL].

Contexto:
- versão publicada: [commit ou referência]
- dispositivo prioritário: [mobile/desktop]
- resultado de campo: [valores ou indisponível]
- resultado de laboratório: [valores]

1. Identifique a métrica prioritária e o elemento responsável.
2. Separe evidência observada de hipótese.
3. Proponha uma única correção de menor escopo.
4. Preserve conteúdo, identidade, acessibilidade, tracking e integrações.
5. Rode os checks do projeto e descreva como verificar visualmente.
6. Não publique até eu aprovar o diff.

Depois da aprovação, o agente pode atualizar os arquivos, executar os checks, republicar e devolver a URL para nova medição.

Core Web Vitals não é uma etapa cosmética no fim do projeto. É um ciclo de observação e correção sobre a experiência que chegou ao visitante. Conecte o fluxo de publicação pela documentação de Configuração, preserve a URL entre versões e faça cada mudança responder a uma evidência concreta.