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

Uma Largest Contentful Paint lenta 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 da LCP usando CWV Superpowers.

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

As quatro fases da LCP

O Google divide a LCP em quatro fases. Cada uma tem causas diferentes 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 é o intervalo entre o recebimento do HTML e a solicitação do recurso da LCP pelo navegador. Este é o problema de descoberta. Se a imagem da LCP estiver em um background CSS, for carregada via JavaScript ou estiver oculta 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 da LCP leva para ser baixado depois de solicitado. Imagens grandes, falta de compactação, CDN lenta, ausência de srcset responsivo.

Render Delay é o intervalo entre a conclusão do download do recurso e a renderização efetiva dele na tela pelo navegador. Scripts de bloqueio de renderização (render-blocking), carregamento de fontes da web ou JavaScript que manipula o DOM antes que o elemento da LCP se torne visível.

Encontrando o gargalo com raciocínio proporcional

Os dados públicos sobre as Core Web Vitals não são bons o suficiente para ajudar você a encontrar os problemas reais das suas 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 de p75 por URL. Nenhum deles diz a você o que corrigir.

E piora: nenhum deles consegue segmentar de forma significativa. O CrUX combina pageviews com cache, pageviews sem cache, novas visitas e recarregamentos de página em um único p75. Eles deveriam ser tratados como problemas separados. Pageviews com cache podem ter um gargalo de TTFB devido à validação de cache obsoleto. Recarregamentos de página podem ocultar um problema de descoberta de recursos em que o navegador encontra a imagem da LCP tarde em cada visita. O p75 misturado mascara ambos.

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

Dados de RUM segmentam por todas essas dimensões. O CWV Superpowers consulta esses dados segmentados e os interpreta de maneira proporcional. 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 prático. A LCP é de 3.800 ms nas páginas de produtos em dispositivos móveis. A distribuição de usuários reais para os primeiros visitantes em pageviews com cache:

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

O Load Delay é o gargalo óbvio. Metade do tempo total da 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 dos visitantes que causou esse problema.

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

Por que o navegador encontra a sua imagem tarde

O Load Delay é o gargalo da LCP mais comum que eu vejo. Isso significa que o navegador recebeu o HTML, mas não sabia que precisava da imagem principal (hero image) até muito mais tarde.

Três causas comuns. A imagem é uma imagem de background CSS invisível para o scanner de pré-carregamento. 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 com muito rigor.

Abra o trace do Chrome. Você verá uma grande lacuna no waterfall 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 faz ideia de que precisa da imagem principal.

O agente vê a mesma lacuna. Ele cruza o waterfall com a distribuição do CoreDash e diz a você exatamente por que a imagem chegou atrasada.

Como é o diagnóstico

Esta é a aparência da saída:

Causa Identificada pela IA: A imagem da LCP div.hero-banner > img.product-main em /product/running-shoes-42 foi descoberta com 1.980 ms de atraso porque não possui uma dica de pré-carregamento (preload hint) e não tem fetchpriority="high". Dados do CoreDash: A 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: 1.940 ms de lacuna entre o primeiro byte do HTML e a solicitação da imagem no waterfall de rede.

Esse é o diagnóstico completo. O agente encontrou o arquivo, escreveu o diff. Você verifica e faz o deploy.

Correções típicas por fase

Load Delay: Adicione uma dica de pré-carregamento no <head>. Defina fetchpriority="high" na imagem da LCP. Mova a imagem de background CSS ou JavaScript para o HTML, onde o scanner de pré-carregamento possa encontrá-la.

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

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

TTFB: Adicione uma CDN. Ative o cache do lado do servidor (server-side caching). Reduza o tempo de consulta ao banco de dados. Use 103 Early Hints para permitir que o navegador comece a pré-carregar os recursos enquanto o servidor ainda está gerando a resposta.

Verificando a correção

Após o deploy, 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 geralmente verifico após 24 a 48 horas de tráfego. O p75 da LCP deve cair, e a distribuição das fases do 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 ou executa novamente o Lighthouse e torce para a pontuação aumentar. Você vê a melhoria nos números de usuários reais, nos segmentos de dispositivo e de rede onde o problema estava.

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