Corrigir LCP com um Agente de IA: Dados de Campo para Correção de Código
O fluxo de trabalho completo de diagnóstico de LCP usando CWV Superpowers: desde a identificação da fase do gargalo em dados de campo até a alteração de código específica.
Um Largest Contentful Paint lento tem quatro causas possíveis. Um agente de IA conectado a dados de campo pode identificar qual é o seu gargalo real, rastreá-lo no Chrome e gerar a correção. Este é o fluxo de trabalho completo de diagnóstico de LCP usando 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 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, sem 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 é o problema de descoberta. Se a imagem do LCP estiver em um background CSS, carregada via JavaScript ou 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 é quanto tempo o recurso LCP leva para baixar depois de solicitado. Imagens grandes, falta de compressão, CDN lenta, sem srcset responsivo.
Render Delay é a lacuna entre o término do download do recurso e o navegador efetivamente pintá-lo na tela. Render-blocking scripts, carregamento de web font ou JavaScript que manipula o DOM antes que o elemento LCP se torne visível.
Encontrando o gargalo com raciocínio proporcional
O Lighthouse diz a você "O LCP é de 3,8 segundos." Esse é o total. Ele não diz qual fase corrigir.
O CWV Superpowers obtém o detalhamento das fases dos dados de campo do CoreDash e o interpreta proporcionalmente. O gargalo é a fase que consome a maior parcela do tempo total. Não a fase que excede algum limite absoluto.
Exemplo concreto. O LCP é de 3.800ms nas páginas de produtos mobile. O detalhamento de usuários reais:
- TTFB: 600ms (16%)
- Load Delay: 1.900ms (50%)
- Load Time: 800ms (21%)
- Render Delay: 500ms (13%)
Load Delay é o gargalo. Metade do tempo total do LCP é o navegador esperando para descobrir que a imagem existe. Uma auditoria do Lighthouse diria apenas "3,8 segundos" e sugeriria comprimir imagens. A compressão de imagem corrige o Load Time, que é 21% do problema. A verdadeira correção está nos 50%.
Para uma explicação completa desta 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 eu vejo. Isso significa que o navegador recebeu o HTML, mas não sabia que precisava da imagem hero até muito mais tarde.
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 tem um atributo de lazy loading que o navegador respeita muito ansiosamente.
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, é de 1.500 a 2.500ms em mobile. Dois segundos inteiros em que o navegador tem o HTML, mas não tem ideia de que precisa da imagem hero.
O agente vê a mesma lacuna. Ele corresponde o waterfall ao detalhamento do CoreDash e diz a você exatamente por que a imagem estava atrasada.
Como é o diagnóstico
É assim que a saída se parece:
Causa raiz: A imagem do LCP div.hero-banner > img.product-main em /product/running-shoes-42 é descoberta com 1.980ms de atraso porque não possui um preload hint e não tem fetchpriority="high". Dados do CoreDash: O LCP é de 3.820ms (poor) em mobile, p75. Load Delay é o gargalo em 52% do total. O trace do Chrome confirma: lacuna de 1.940ms entre o primeiro byte do HTML e a solicitação da imagem no waterfall de rede.
Esse é todo o diagnóstico. O agente encontrou o arquivo, escreveu o diff. Você o verifica e faz o deploy.
Correções típicas por fase
Load Delay: Adicione um preload hint no <head>. Defina fetchpriority="high" na imagem do LCP. Mova a imagem do 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 mobile não baixem uma imagem do tamanho de um desktop. Veja a otimização de imagens para o Core Web Vitals.
Render Delay: Remova ou adie render-blocking scripts que são executados antes que o elemento LCP se torne visível. Verifique o font-display em web fonts 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 no lado do servidor. Reduza o tempo de consulta ao banco de dados. Use 103 Early Hints para permitir que o navegador comece a fazer o preload de 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. Normalmente, verifico após 24 a 48 horas de tráfego. O p75 do LCP deve cair e a distribuição da fase do gargalo deve mudar.
Este é o passo que separa as correções orientadas por dados de campo das suposições do Lighthouse. Você não espera que a correção tenha funcionado. Você vê isso em números reais de usuários.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
