Corrigir LCP com um Agente de IA: De Dados de Campo à Correção de Código

Um Largest Contentful Paint lento tem quatro causas possíveis. Um agente de IA conectado a dados de campo pode identificar qual é o seu verdadeiro gargalo, rastreá-lo no Chrome e gerar a correção. Este é o fluxo de trabalho completo de diagnóstico de LCP usando o CWV Superpowers.

Última revisão por Arjen Karel em março de 2026

As quatro fases do LCP

O Google divide o LCP em quatro fases. Cada uma tem causas e correções diferentes.

TTFB é o tempo desde o início da navegação até o primeiro byte da resposta HTML. Servidores lentos, falta de CDN, ausência de cache, consultas longas ao banco de dados. Se o TTFB for o gargalo, nada mais importa até que você corrija o servidor.

Load Delay é a lacuna entre o recebimento do HTML e a solicitação do recurso LCP pelo navegador. Este é um problema de descoberta. Se a imagem LCP estiver em um background CSS, for carregada via JavaScript ou estiver enterrada atrás de uma cadeia de redirecionamentos, o navegador não poderá começar a buscá-la até descobrir que precisa dela.

Load Time é o tempo que o recurso LCP leva para ser baixado depois de solicitado. Imagens grandes, falta de compressão, CDN lenta, ausência de srcset responsivo.

Render Delay é a lacuna entre o término do download do recurso e o navegador efetivamente pintá-lo na tela. Scripts que bloqueiam a renderização, carregamento de fontes da web ou JavaScript que manipula o DOM antes que o elemento LCP se torne visível.

Encontrando o gargalo com raciocínio proporcional

Os dados públicos sobre os Core Web Vitals não são bons o suficiente para ajudar você a encontrar os problemas reais dos seus Core Web Vitals.  O Lighthouse executa um teste sintético em um Moto G Power simulado e relata um tempo de LCP. O CrUX agrega 28 dias de dados reais do Chrome em um único valor p75 por URL. Nenhum deles diz a você o que corrigir.

E a situação piora: nenhum dos dois consegue segmentar de forma significativa. O CrUX combina visualizações de página em cache, sem cache, novas visitas e recarregamentos de página em um único p75. Eles deveriam ser tratados como problemas separados. Visualizações em cache podem ter um gargalo de TTFB devido à validação de cache obsoleto. Recarregamentos de página podem ocultar um problema de descoberta de recurso em que o navegador encontra a imagem LCP tardiamente em cada visita. O p75 misturado mascara ambos.

O CrUX adicionou as subpartes do LCP em 2025, o que ajuda. Mas ainda é um p75 de 28 dias sem nenhum filtro de elemento, viewport ou qualquer outro. Você vê as proporções das fases para "todos os visitantes desta URL no último mês". Você não vê o que está acontecendo no tipo de dispositivo, país ou modelo de página específico onde o problema reside.

Os dados RUM segmentam por todas essas dimensões. O CWV Superpowers consulta esses dados segmentados e os interpreta proporcionalmente. O gargalo é a fase que consome a maior parcela do tempo total para o segmento específico que está falhando. Não uma média sem sentido ou uma simulação do Lighthouse. Dados reais!

Exemplo concreto. O LCP é de 3.800 ms em páginas de produto no celular. O detalhamento de usuários reais para primeiros visitantes em visualizações de página em cache:

• TTFB: 600ms (28,7%)
• Load Delay: 1.900ms (44,6%)
• Load Time: 800ms (19,3%)
• Render Delay: 500ms (7,4%)

O Load Delay é o gargalo óbvio. Metade do tempo total do LCP é o navegador esperando para descobrir que a imagem existe. O Lighthouse, o CrUX ou uma investigação manual teriam muita dificuldade em encontrar essa combinação exata de características do visitante que causou esse problema.

Para uma explicação completa dessa abordagem, veja o raciocínio proporcional para performance web.

Por que o navegador encontra sua imagem tarde

O Load Delay é o gargalo de LCP mais comum que vejo. Isso significa que o navegador recebeu o HTML, mas não sabia que precisava da imagem hero até muito depois.

Três causas comuns. A imagem é uma imagem de background CSS invisível para o preload scanner. A URL da imagem é construída em JavaScript. Ou a imagem está tecnicamente no HTML, mas possui um atributo de lazy loading que o navegador respeita de forma excessivamente ávida.

Abra o trace do Chrome. Você verá uma grande lacuna na cascata de rede entre a chegada do HTML e o disparo da solicitação da imagem. Essa lacuna é o seu Load Delay. Nos sites que audito, isso varia de 1.500 a 2.500 ms em dispositivos móveis. Dois segundos inteiros em que o navegador possui o HTML, mas não tem ideia de que precisa da imagem hero.

O agente vê a mesma lacuna. Ele correlaciona a cascata de rede com o detalhamento do CoreDash e diz a você exatamente por que a imagem estava atrasada.

Como é o diagnóstico

Esta é a aparência da saída:

Causa Identificada pela IA: A imagem do LCP div.hero-banner > img.product-main em /product/running-shoes-42 foi descoberta 1.980 ms tarde porque carece de um preload hint e não possui fetchpriority="high". Dados do CoreDash: o LCP é de 3.820 ms (ruim) em dispositivos móveis, p75. O Load Delay é o gargalo com 52% do total. O trace do Chrome confirma: lacuna de 1.940 ms entre o primeiro byte do HTML e a solicitação da imagem na cascata de rede.

Esse é todo o diagnóstico. O agente encontrou o arquivo, escreveu o diff. Você verifica e publica.

Correções típicas por fase

Load Delay: Adicione um preload hint no <head>. Defina fetchpriority="high" na imagem do LCP. Mova a imagem de um background CSS ou do JavaScript para o HTML, onde o preload scanner possa encontrá-la.

Load Time: Converta para WebP ou AVIF. Reduza as dimensões da imagem para corresponder ao tamanho de exibição real. Adicione um srcset responsivo para que os usuários de dispositivos móveis não baixem uma imagem do tamanho de desktop. Consulte a otimização de imagens para os Core Web Vitals.

Render Delay: Remova ou adie os scripts que bloqueiam a renderização e que são executados antes que o elemento LCP se torne visível. Verifique o font-display nas fontes da web que afetam o elemento de texto do LCP. Use 103 Early Hints para entregar o CSS mais cedo.

TTFB: Adicione uma CDN. Ative o cache do lado do servidor. Reduza o tempo de consulta ao banco de dados. Use 103 Early Hints para permitir que o navegador comece o preload dos recursos enquanto o servidor ainda está gerando a resposta.

Verificando a correção

Após a implantação, consulte os dados de campo do CoreDash para a mesma página e segmento de dispositivo. Os dados de campo são atualizados à medida que usuários reais carregam a página. Eu normalmente verifico após 24 a 48 horas de tráfego. O p75 do LCP deve cair e a distribuição da fase de gargalo deve mudar.

Esta é a diferença entre corrigir um número e corrigir a experiência. Você não espera 28 dias por uma atualização do CrUX nem executa o Lighthouse novamente esperando que a pontuação suba. Você vê a melhoria nos números de usuários reais, nos segmentos de rede e de dispositivo onde o problema estava.

Para o diagnóstico de INP (a métrica que não pode ser medida em laboratório), o mesmo fluxo de trabalho segmentado se aplica. Para uma visão mais ampla de como os agentes de IA usam dados de campo vs dados de laboratório em todos os três Core Web Vitals, consulte a depuração de Core Web Vitals com agentes de IA.