Depuração de Web Vitals em frontends gerados por IA: correções precisas

Como os problemas de Web Vitals aparecem em apps reais

Problemas de Web Vitals raramente parecem apenas “um número fora do lugar”. Eles parecem um site que parece pronto, mas não está.

Quando o LCP está ruim, as pessoas ficam olhando uma área em branco ou um placeholder de baixa qualidade por tempo demais, e então o conteúdo principal aparece de repente. Às vezes é óbvio, como uma manchete do hero que surge tarde. Outras vezes é sutil, como a imagem do produto demorando demais enquanto o resto já está visível.

Quando o CLS está ruim, a página se move por baixo do usuário. Você tenta tocar um botão e ele desliza para baixo porque uma barra foi carregada, uma fonte foi trocada ou uma imagem finalmente recebeu sua altura.

Quando o INP está ruim, a página parece carregada mas dá a sensação de lentidão. Toques e cliques demoram a responder, campos de entrada travam e menus abrem atrasados.

Frontends gerados por IA frequentemente sofrem regressões após pequenas edições porque layout, busca de dados e efeitos colaterais ficam embaralhados nos mesmos componentes. Uma mudança “pequena” como adicionar um badge, trocar uma fonte ou renderizar condicionalmente uma promoção pode deslocar o layout inicial, atrasar o maior elemento ou adicionar trabalho extra exatamente quando o usuário interage.

O objetivo é simples: quando uma métrica dispara, você quer dizer “é este elemento dentro deste componente, e piorou depois desta mudança.” Isso torna as correções mais seguras, fáceis de repetir e fáceis de verificar.

Configure uma linha de base repetível antes de mudar qualquer coisa

Trabalho de performance só importa se você pode provar que fez melhoras.

Comece mantendo seu setup consistente: Chrome (estável), DevTools e uma build parecida com a de produção (minificada, mesmas feature flags, mesmos endpoints de API se possível). Escolha uma página de teste estável onde o conteúdo não mude muito entre execuções. Se sua app precisa de login, crie uma conta de teste dedicada com dados consistentes.

Limite seu escopo a 1–3 páginas de alto valor. Para muitos frontends gerados por IA, isso é uma landing pública (primeira impressão), uma página de preços (conversão) e um fluxo “importante” como checkout ou uma tela de dashboard chave. Se tentar consertar tudo de uma vez, fica difícil saber o que ajudou.

Mantenha as execuções comparáveis. Use o mesmo dispositivo sempre, o mesmo perfil de rede no DevTools e os mesmos passos (aba limpa, hard reload, mesmos cliques). Mesmo pequenas diferenças, como uma extensão injetando scripts ou um conjunto de dados diferente, podem fazer INP e CLS parecerem melhores ou piores por acaso.

Anote sua linha de base em linguagem simples:

• Data, página, build/commit
• Valores de LCP/CLS/INP observados
• Uma frase sobre o que parecia errado (exemplo: “a imagem do hero aparece de repente e empurra a manchete”)

Essa nota é seu cheque de realidade mais tarde, especialmente em UIs geradas por IA onde uma “correção” pode mover o problema para outro componente.

Dados de campo vs dados de laboratório: quando usar cada um

A depuração anda mais rápido quando você separa duas perguntas: “O que os usuários reais estão sentindo?” e “O que consigo reproduzir e consertar hoje?” Dados de campo respondem a primeira. Dados de laboratório respondem à segunda. Normalmente você precisa de ambos para não perseguir o problema errado.

Dados de campo (monitoramento de usuários reais, analytics ou dados no estilo Chrome UX Report) mostram tendências entre dispositivos, redes, rotas e comportamentos. É a melhor maneira de confirmar se LCP, CLS ou INP estão realmente ruins em produção e em quais páginas.

Dados de laboratório (execuções do Lighthouse, gravações de Performance no DevTools, testes com rede limitada) é onde você faz o trabalho. Permite reproduzir o mesmo cenário, inspecionar o que foi pintado e ver qual tarefa bloqueou o input. Resultados de laboratório podem ser ruidosos, mas são controláveis.

Uma forma prática de combinar:

• Use dados de campo para escolher o template de página pior e a métrica pior (por exemplo, CLS móvel na landing).
• Reproduza no laboratório e grave até conseguir disparar o mesmo tipo de deslocamento ou atraso.
• Corrija uma coisa por vez: um componente, uma imagem ou um comportamento de script.
• Verifique duas vezes: o laboratório deve melhorar imediatamente e o campo deve melhorar com o tempo conforme os usuários receberem a nova versão.

Se só puder escolher uma fonte para decidir o que enviar, confie primeiro em um problema reproduzível em laboratório e use dados de campo como confirmação.

Como traçar o LCP até o elemento e componente exatos

LCP costuma ser uma grande coisa que o usuário espera ver: uma imagem do hero, uma manchete, um card de produto ou um bloco de cabeçalho. O trabalho é identificar esse elemento exato e, em seguida, voltar até o componente e ao que ele está esperando.

Encontre o elemento de LCP em um trace de Performance

No Chrome DevTools, grave um trace de Performance enquanto carrega a página (incognito ajuda, e use um perfil de rede normal). No trace, procure o marcador LCP, clique nele para ver o elemento reportado.

Um fluxo simples que funciona na maioria dos frontends gerados por IA:

• Comece a gravação em Performance e recarregue a página.
• Encontre o marcador LCP na linha do tempo.
• Clique nele e anote o elemento LCP (tag, tamanho e qualquer URL de imagem).
• Use o nó destacado para pular até ele no DOM.
• Identifique a qual bloco de UI ele pertence (hero, header, card acima da dobra).

Mapeie de volta ao componente e suas dependências

Quando souber o elemento, pergunte onde ele é criado. Em apps React/Next.js, muitas vezes é um componente Hero que busca dados, carrega uma imagem e aplica estilos.

Se o elemento de LCP for uma imagem, verifique se ela é servida no tamanho certo e se começa a ser baixada cedo o suficiente. Se for texto, preste atenção às fontes e ao CSS.

Depois, liste do que o componente precisa antes de poder renderizar. Causas comuns:

• Uma imagem de hero muito grande, ou uma imagem sem dimensões
• CSS que bloqueia render ou arquivos grandes de fontes atrasando a pintura de texto
• Fetchs client-side que bloqueiam o hero (um estado de loading vira o “conteúdo”)
• JavaScript pesado na primeira visualização (hydration bloqueia a renderização)

Um padrão comum gerado por IA é construir o hero a partir de um fetch client-side a um CMS, o que faz o hero esperar por JavaScript e dados. Consertar essa dependência pode reduzir o LCP sem tocar o resto da página.

Como encontrar a origem dos deslocamentos de layout (CLS)

CLS é a pontuação de “pulo na página”. Acontece quando algo muda de tamanho depois que a página já parecia carregada. O navegador faz o layout, então um elemento tardio aparece (ou cresce) e tudo abaixo é empurrado para baixo ou para os lados.

Para capturar, use a visualização de layout shift do navegador. No Chrome DevTools, grave um trace de Performance enquanto recarrega a página e faz um pequeno scroll. Você verá eventos “Layout Shift” na linha do tempo, além de regiões destacadas mostrando o que se moveu. Clique em um evento de shift e procure os detalhes “Moved from / Moved to” e o elemento que o acionou.

Uma vez com o elemento, pergunte: o que mudou seu tamanho tardiamente?

A maioria dos bugs de CLS vem de um conjunto pequeno de padrões:

• Mídia sem dimensões (imagens, embeds de vídeo, iframes)
• Troca de fontes que altera a largura do texto e quebras de linha
• Banners tardios (consentimento de cookies, barras promocionais, widgets de chat) injetados depois da primeira pintura
• Blocos assíncronos (reviews, recomendações, seções personalizadas)
• Estados que colapsam/expandem (erros de validação, accordions) que aparecem sem espaço reservado

Escolha a correção baseada na causa. Se o conteúdo precisa aparecer, reserve espaço com dimensões explícitas, aspect-ratio ou uma caixa placeholder. Se for UI opcional (como uma barra promocional), mostre-a sem empurrar o layout ou adie até que o conteúdo principal esteja estável.

Exemplo: uma landing carrega uma imagem do hero sem dimensões, depois injeta uma barra “Ganhe 10%” após 2 segundos. O trace mostrará dois shifts: um ligado ao elemento da imagem do hero e outro ligado ao container do banner. Reservar espaço para o hero e fazer o banner sobrepor o cabeçalho geralmente resolve ambos.

Como apontar atrasos de interação (INP)

INP é o tempo entre uma ação do usuário (clique, toque, tecla) e uma resposta visível na página. Se alguém clica num botão e nada muda por um momento, essa lacuna é o que o INP captura.

A maneira mais rápida de encontrar a causa é gravar uma interação real e procurar trabalho que bloqueie a main thread.

Abra DevTools > Performance, inicie a gravação e faça a ação exata que parece lenta (abrir um menu, digitar numa caixa de busca, abrir um modal). Pare a gravação e procure uma longa lacuna logo após o evento de input, geralmente mostrada como long tasks (frequentemente 50ms+).

Quando encontrar uma long task, conecte-a ao código checando o que estava acontecendo naquela janela. Culpados comuns em UIs geradas por IA:

• Renderização pesada (toda a página rerenderiza por uma pequena mudança de estado)
• Listas grandes ou tabelas (centenas de linhas de uma vez)
• Atualizações de estado caras (clonagem profunda, ordenação, filtragem a cada pressionada de tecla)
• Scripts de terceiros (analytics, widgets de chat) executando durante interações
• Thrash de layout (JS lendo e escrevendo layout repetidamente)

Triagem rápida ajuda porque a correção varia:

• Lag na primeira interação costuma apontar para código carregado de forma lazy, carregamento de fontes ou um grande componente montando pela primeira vez.
• Lag em todas as interações geralmente significa trabalho repetido de render, estado barulhento ou handlers de eventos fazendo demais.

Exemplo: clicar “Adicionar ao carrinho” rerenderiza toda a grade de produtos porque o estado do carrinho vive no topo da árvore. O INP melhora quando você isola o estado no widget do carrinho e impede que a grade rerenderize a cada clique.

Correções práticas que reduzem CLS rápido

CLS geralmente cai rápido quando você impede que a página mude de tamanho depois que ela aparece. As vitórias mais rápidas são as chatas: reserve espaço, mantenha a tipografia estável e evite UI surpresa.

Reserve espaço para qualquer coisa que carregue depois

Se uma imagem, vídeo, slot de anúncio ou iframe chega sem uma caixa definida, o navegador estima e depois corrige, e tudo pula.

Defina dimensões explícitas sempre que puder. Use width e height em imagens, ou aspect-ratio em CSS para que o navegador saiba a forma antes do arquivo baixar. Se usar skeleton loaders, dê a eles uma altura fixa que corresponda ao conteúdo real.

Estabilize fontes para evitar reflows

Trocas tardias de fonte alteram quebras de linha e empurram botões para baixo. Mantenha a fonte fallback próxima em tamanho e espaçamento, e evite trocar pesos depois da primeira pintura. Se um título salta quando a web font carrega, escolha um fallback com métricas semelhantes e mantenha estilos iniciais consistentes.

Remova ou contenha injeções tardias de UI

Toasts, banners de cookie, widgets de chat e barras de “nova mensagem” costumam aparecer depois da página já visível. Coloque-os em um local reservado desde o início, ou exiba-os como overlays em vez de empurrar o conteúdo.

Se quiser um impacto rápido, foque em:

• Dimensões (ou aspect-ratio) para mídia acima da dobra
• Altura mínima fixa para seções hero e skeletons
• Banners e widgets renderizando em um container com espaço reservado
• Evitar inserir novo conteúdo acima da dobra após a primeira pintura

Mudanças que geralmente melhoram LCP e INP sem reescrever tudo

Quando uma UI gerada por IA parece lenta, muitas vezes é porque trabalho demais acontece antes da primeira tela ficar totalmente visível. Ajuda focar em dois objetivos: tornar a primeira visualização mais leve (LCP) e fazer toques e cliques executarem menos trabalho (INP).

Um padrão comum é um hero embrulhado em múltiplos containers, mais um carrossel, vídeo de fundo e vários scripts de terceiros que começam imediatamente. Pode parecer ok num laptop rápido, mas em um celular intermediário a main thread fica ocupada e tudo chega tarde.

Mudanças que normalmente ajudam sem alterar toda a stack:

• Reduzir o elemento de LCP. Se for uma imagem, compacte, use WebP/AVIF e sirva o tamanho certo para a tela. Se for texto dentro de um invólucro pesado, remova camadas extras e efeitos caros.
• Simplificar acima da dobra. Corte animações não críticas, sombras, efeitos de blur e widgets complexos na primeira viewport. Renderize a versão mais simples primeiro e só depois enriqueça.
• Adiar scripts não críticos. Carregue analytics, widgets de chat e ferramentas de A/B após a render inicial.
• Quebrar long tasks. Se um clique dispara um grande cálculo ou rerender, divida o trabalho para que o navegador possa responder rapidamente.
• Reduzir rerenders. Consolide estado, memoize partes caras e evite que a página inteira rerenderize por uma pequena mudança de UI.

Para INP, observe handlers de clique. Se um botão faz chamadas de rede, validação e atualizações de UI num mesmo bloco, o usuário espera. Mostre a resposta de UI primeiro (abra a gaveta ou o modal), depois faça o trabalho mais pesado.

Meça melhorias após cada mudança (sem se enganar)

É fácil perder horas mudando algo, ver um run bom e seguir em frente. Web Vitals são ruidosos. Tempo de rede, carga de CPU, extensões e caches quentes podem fazer uma mudança parecer melhor (ou pior) do que realmente é.

Trate cada ajuste como um mini-experimento: mude uma coisa, depois meça. Se agrupar várias mudanças num commit (comum em frontends gerados por IA), você não saberá o que ajudou.

Um log simples basta:

• O que mudou (uma mudança pequena)
• Onde (página/rota, componente)
• Como testou (dispositivo, throttling, cold vs warm load)
• Resultados (LCP, CLS, INP) usando a mediana de 3 execuções
• Evidência salva (screenshots do trace)

Compare medianas, não melhores execuções. Uma melhor execução costuma ser sorte.

Também fique atento a trocas. Você pode consertar CLS reservando espaço e, em seguida, piorar o LCP carregando mais CSS cedo. Ou melhorar INP dividindo um componente e introduzir uma imagem tardia que vira o novo LCP. Se uma correção melhora uma métrica e prejudica outra, decida qual dor do usuário é maior e ajuste.

Armadilhas comuns ao depurar Web Vitals em UIs geradas por IA

O trabalho de Web Vitals sai do caminho rápido quando o código parece “ok” mas se comporta diferente em produção. O maior erro é otimizar a pontuação em vez da experiência nas páginas que as pessoas realmente usam.

Armadilhas que desperdiçam tempo e criam “vitórias” falsas:

• Perseguir pontos do Lighthouse numa única execução enquanto usuários reais sofrem em login, checkout ou preços.
• Testar em modo dev e assumir que os números batem com produção.
• Esconder conteúdo, adicionar delays ou manter skeletons longos para a métrica melhorar enquanto a página fica pior.
• Deixar uma refatoração por IA tocar dezenas de arquivos de uma vez, de modo que quando LCP ou INP mudam você não sabe por quê.
• Acelerar uma página e esquecer de checar layouts compartilhados e fluxos de autenticação.

Exemplo: uma landing “conserta” o CLS fazendo o hero desaparecer e aparecer com fade após 800 ms. O CLS melhora, mas os usuários olham para uma área em branco e clicam no lugar errado quando o conteúdo aparece. É uma vitória de métrica com perda de produto.

Algumas regras ajudam:

• Meça a mesma rota, perfil de dispositivo e rede cada vez.
• Envie uma mudança por vez e confirme que navegação e login ainda funcionam.
• Trate qualquer correção que esconda conteúdo ou atrase render com suspeita até confirmar que ajuda os usuários.

Checklist rápido para uma passada de 30 minutos nos Web Vitals

Escolha uma página e um perfil de dispositivo para hoje. Testar três páginas e dois tamanhos de tela consome tempo e produz resultados confusos.

Faça uma execução e anote o que vê antes de mexer no código. Seu trabalho é identificar a maior causa única de dor para LCP, CLS e INP naquela página.

• Linha de base: registre tempo de LCP e o elemento exato de LCP (imagem, manchete, seção hero).
• CLS: capture os 1–2 maiores layout shifts e o que se moveu (hero, banner, troca de fonte, widget injetado).
• INP: registre a interação mais lenta que conseguir reproduzir e a long task logo após ela.
• Varredura rápida: verifique se a mídia do hero tem dimensões fixas, banners/toasts têm espaço reservado e scripts de terceiros não estão bloqueando a primeira render.
• Uma mudança, uma nova execução: faça uma única correção, repita o mesmo teste e registre os novos números.

Se o elemento LCP for a imagem do hero e a página pula quando um banner de cookies aparece, conserte o espaço do banner primeiro (CLS), depois trave as dimensões da imagem do hero e o comportamento de carregamento (LCP). Não misture cinco “pequenas melhorias” num único commit ou você não saberá o que ajudou.

Pare quando as melhorias ficarem pequenas, ou quando a próxima correção exigir refatoração. Se a UI foi gerada por uma ferramenta de IA e o código estiver emaranhado, planeje o próximo gargalo como um bloco de trabalho separado.

Exemplo: transformar uma landing gerada por IA saltitante em uma estável

Uma landing comum gerada por IA parece bem em screenshots, mas pula quando você a carrega: uma grande imagem do hero no topo, cards de preço abaixo e um slider de depoimentos que aparece tarde.

Num projeto assim, a história ficou clara após medir: o LCP era a imagem do hero, o CLS vinha de uma troca de fonte mais o slider mudando de altura quando carregava, e o INP era prejudicado por uma biblioteca de animação pesada rodando cedo.

A sequência que consertou sem reescrever tudo:

• Travar o tamanho da imagem do hero com dimensões explícitas ou aspect-ratio.
• Reservar espaço para o slider de depoimentos com uma altura fixa (ou min-height previsível).
• Adiar ou reduzir animações iniciais para que toques e scrolls pareçam imediatos.

Para manter a honestidade, registre as mesmas coisas antes e depois de cada mudança:

Se você reservou espaço, removeu os maiores layout shifts e adiou trabalho não essencial, mas as métricas ainda oscilam porque a árvore de componentes está emaranhada, geralmente é mais rápido reestruturar essa seção do que continuar cutucando sintomas.

Próximos passos se o frontend estiver muito bagunçado para otimizar com segurança

Se você não consegue mapear LCP, CLS ou INP de volta a um elemento e ao componente que o criou, provavelmente precisa limpar antes de afinar. Esse trabalho só compensa quando você consegue traçar uma métrica a uma causa concreta e verificar o impacto após uma pequena mudança.

Frontends gerados por IA frequentemente parecem ok na superfície, mas escondem uma bagunça por baixo: componentes duplicados, estilos inline por toda parte, rerenders surpresa e mudanças de layout acionadas por dados tardios. Nessa situação, “consertos rápidos” podem criar um novo deslocamento de layout, ou reduzir LCP enquanto pioram INP.

Um caminho mais seguro é uma triagem curta:

• Escolha uma página que importa (frequentemente a landing ou o fluxo de cadastro).
• Capture a linha de base: alguns traces de performance e uma lista dos maiores elementos de LCP e dos principais layout shifts.
• Identifique o que você realmente consegue controlar (um componente, uma rota, um sistema de layout).
• Decida: pequena refatoração primeiro, ou limpeza mais profunda antes de mexer nas métricas.

Um sinal claro para parar de mexer e refatorar: você muda um componente hero para consertar LCP, mas o header começa a pular porque o espaçamento está definido em três lugares (módulo CSS, style inline, div wrapper). Se você não consegue prever o que vai se mover, está chutando.

Se você herdou código gerado por IA e precisa que ele fique estável o suficiente para que correções de performance realmente funcionem, o FixMyMess trabalha exatamente nesse tipo de remediação: diagnosticar protótipos bagunçados gerados por ferramentas como Lovable, Bolt, v0, Cursor e Replit, depois reparar e refatorar com verificação humana. Se quiser uma segunda opinião antes de investir numa reescrita maior, a auditoria de código gratuita deles pode ajudar a apontar o que está dirigindo LCP/CLS/INP nas suas páginas-chave.

Quando a base de código voltar a ser previsível, retome o loop simples: linha de base, uma mudança, re-medir, repetir.