Agente de IA e Core Web Vitals: Por Que Dados de Campo Mudam Tudo
Três tipos de servidores MCP conectam agentes de IA aos dados de Core Web Vitals. Apenas um fornece os dados que o Google realmente usa para ranqueamento.
Agentes de codificação com IA agora podem se conectar a dados de performance web através de servidores MCP. Eles executam auditorias, rastreiam gargalos e geram correções de código em um ciclo automatizado. Existem três tipos de servidores MCP para este trabalho: Chrome DevTools, Lighthouse e Real User Monitoring. A fonte de dados determina se a correção ajuda seus usuários ou apenas melhora uma pontuação sintética que o Google ignora.
Última revisão por Arjen Karel em março de 2026
O que agentes de IA podem fazer com Core Web Vitals hoje
O Model Context Protocol (MCP) padroniza como ferramentas de IA se conectam a fontes de dados externas. Para o trabalho de Core Web Vitals, três tipos de servidores são importantes.
Chrome DevTools MCP dá aos agentes controle direto sobre a superfície de depuração do Chrome. O Google lançou isso em preview público no final de 2025. Ele executa rastreamentos de performance, analisa as quebras de fase do LCP, identifica recursos que bloqueiam a renderização e comprime dados brutos de rastreamento em um resumo compacto que um agente pode processar.
Servidores MCP do Lighthouse permitem que os agentes executem auditorias completas de forma programática. Existem várias implementações no GitHub. Úteis para auditorias em massa em muitas páginas. Os resultados são dados de laboratório: testes sintéticos em um dispositivo simulado com uma conexão de rede simulada.
Servidores MCP de RUM conectam agentes aos dados de Real User Monitoring dos seus visitantes reais. O CoreDash é atualmente a única plataforma comercial de RUM com um servidor MCP integrado, expondo dados de campo em tempo real para qualquer agente de codificação compatível com MCP.
O fluxo de trabalho que os três possibilitam é um ciclo de medir-corrigir-remedir. O agente identifica um gargalo, gera uma correção de código, aplica e testa novamente. O tipo de dados que o agente usa determina se a correção realmente ajuda os usuários reais.
O problema com agentes que usam apenas o Lighthouse
O Google não usa as pontuações do Lighthouse para ranqueamento. O Google usa dados de campo do CrUX de usuários reais do Chrome durante uma janela móvel de 28 dias. Um agente que executa o Lighthouse, faz alterações e executa o Lighthouse novamente completou um ciclo que não significa nada para sua visibilidade em buscas.
A lacuna entre o laboratório e o campo é real. O Web Almanac de 2025 mostra que 52% dos sites mobile falham em pelo menos um Core Web Vital nos dados de campo. Muitos desses sites têm boas pontuações no Lighthouse.
O INP é o maior ponto cego. O INP mede quão rápido seu site responde a cliques, toques e pressões de teclas reais durante sessões inteiras de usuários. Não há equivalente de laboratório. O Lighthouse usa o Total Blocking Time como proxy, mas o TBT mede o bloqueio da thread durante o carregamento da página. O INP mede o tempo de resposta durante interações reais que acontecem em momentos imprevisíveis. Um agente que "corrige" o seu TBT não tem garantia de que o seu INP real melhorou.
Um estudo de 33.596 pull requests criados por agentes (Alam et al., janeiro de 2026) descobriu que PRs de correção gerados por IA têm uma taxa de merge geral de 65%. Mais de um terço são rejeitados por revisores humanos. Correções de performance exigem contexto que os dados de laboratório sozinhos não podem fornecer.
O que os dados de campo te dão que os dados de laboratório não conseguem
O Real User Monitoring coleta dados de performance de cada visitante em cada dispositivo. Quando um agente se conecta a RUM em vez de Lighthouse, três coisas mudam.
Ele sabe quais páginas estão realmente lentas para o seu público. Não quais páginas pontuaram mal em um teste sintético em um Moto G Power simulado via 4G. Seus usuários podem estar em iPhones na Alemanha com fibra ótica. Ou em Androids de baixo custo na Indonésia em uma rede móvel congestionada. Os dados de campo refletem o que eles realmente experimentam.
O CoreDash dá ao agente a atribuição em nível de elemento. O elemento específico que causou o LCP lento. O arquivo JavaScript por trás do INP lento (através de dados de Long Animation Frames). O nó do DOM que mudou de posição. O agente rastreia desde a métrica até o código exato sem adivinhação.
E ele pode verificar se a correção funcionou. Após fazer o deploy de uma alteração, o agente consulta os dados de campo para confirmar se os usuários reais viram melhoria. Este é o passo que a maioria dos fluxos de trabalho de IA pula completamente. É o único passo que importa para o seu ranqueamento.
O fluxo de trabalho completo se torna: encontrar o problema nos dados de campo, rastrear a causa no Chrome, corrigir o código, verificar com dados de campo. O agente faz a investigação. Você decide o que é publicado.
Para onde ir a partir daqui
CWV Superpowers é uma skill gratuita do Claude Code que automatiza todo esse fluxo de trabalho. A configuração leva dois minutos. Ela se conecta aos dados de campo do CoreDash, identifica o seu pior gargalo, rastreia a causa raiz no Chrome e gera a correção.
Para métricas específicas: o guia de diagnóstico de LCP detalha como o agente rastreia um Largest Contentful Paint lento através de suas quatro fases até a alteração exata do código. O guia de diagnóstico de INP cobre a métrica com a qual os agentes de IA têm mais dificuldade, porque ela não pode ser simulada em laboratório.
O conceito por trás do diagnóstico é o raciocínio proporcional: o agente identifica o gargalo como a fase que consome a maior parcela do tempo total, não a fase que excede um limite absoluto. Isso muda quais correções realmente fazem diferença.
A performance cai no momento que você para de olhar.
Monto o monitoramento, os budgets e o processo. É isso que separa um fix de uma solução.
Vamos conversar
