Agente de IA para monitoramento do Core Web Vitals: field data via MCP

Agentes de código com IA agora podem se conectar a dados de performance web via 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 esse trabalho: Chrome DevTools, Lighthouse e Real User Monitoring. A fonte de dados determina se a correção ajuda os usuários ou só 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 o Core Web Vitals hoje

O Model Context Protocol (MCP) padroniza como ferramentas de IA se conectam a fontes externas de dados. No trabalho com o Core Web Vitals, três tipos de servidores importam.

O 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 fim de 2025. Ele executa traces de performance, analisa a divisão de fases do LCP, identifica recursos render blocking e comprime dados brutos de trace em um resumo compacto que o agente consegue analisar.

Servidores MCP do Lighthouse permitem que agentes executem auditorias completas de forma programática. Existem várias implementações no GitHub. Útil para auditorias em lote em muitas páginas. Os resultados são lab data: testes sintéticos em um dispositivo simulado com uma conexão de rede simulada.

Servidores MCP de RUM conectam agentes a dados de Real User Monitoring de visitantes reais. O CoreDash é atualmente a única plataforma comercial de RUM com servidor MCP integrado, expondo field data em tempo real para qualquer agente de código compatível com MCP.

O fluxo de trabalho que os três viabilizam é um ciclo de medir, corrigir e medir de novo. O agente identifica um gargalo, gera uma correção no código, aplica e testa novamente. O tipo de dado que o agente usa determina se a correção realmente ajuda usuários reais.

O problema dos agentes que só usam o Lighthouse

O Google não usa pontuações do Lighthouse para ranqueamento. O Google usa field data do CrUX de usuários reais do Chrome em uma janela móvel de 28 dias. Um agente que roda o Lighthouse, faz alterações e roda o Lighthouse de novo conclui um ciclo que não significa nada para a visibilidade na busca.

A diferença entre lab e field é real. O Web Almanac de 2025 mostra que 52% dos sites no celular falham em pelo menos um Core Web Vital em field data. Muitos desses sites pontuam bem no Lighthouse.

O INP é o maior ponto cego. O INP mede a rapidez com que o site responde a cliques, toques e teclas reais ao longo de toda a sessão do usuário. Não existe equivalente em lab. 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 TBT não dá nenhuma garantia de que o INP real melhorou.

Um estudo com 33.596 pull requests criados por agentes (Alam et al., janeiro de 2026) mostrou que PRs de correção gerados por IA têm uma taxa geral de merge de 65%. Mais de um terço é rejeitado por revisores humanos. Correções de performance exigem um contexto que lab data sozinho não consegue fornecer.

O que o field data entrega e o lab data não consegue

O Real User Monitoring coleta dados de performance de cada visitante em cada dispositivo. Quando um agente se conecta ao RUM em vez do Lighthouse, três coisas mudam.

Ele sabe quais páginas estão realmente lentas para o público. Não quais páginas pontuam mal em um teste sintético em um Moto G Power simulado no 4G. Os usuários podem estar em iPhones na Alemanha com conexão de fibra. Ou em celulares Android de entrada na Indonésia em uma rede móvel congestionada. O field data reflete o que eles realmente vivenciam.

O CoreDash dá ao agente atribuição no nível do elemento. O elemento específico que causou o LCP lento. O arquivo JavaScript por trás do INP lento (por meio de dados de Long Animation Frames). O nó do DOM que se deslocou. O agente rastreia da métrica até o código exato sem adivinhação.

E ele consegue verificar se a correção funcionou. Após o deploy de uma alteração, o agente consulta o field data para confirmar que usuários reais viram melhorias. Essa é a etapa que a maioria dos fluxos de trabalho de IA ignora por completo. É a única etapa que importa para o ranqueamento.

O fluxo de trabalho completo passa a ser: encontrar o problema em field data, rastrear a causa no Chrome, corrigir o código e verificar com field data. O agente faz a investigação. Você decide o que vai para produção.

Próximos passos

O CWV Superpowers é uma skill gratuita do Claude Code que automatiza todo esse fluxo de trabalho. A configuração leva dois minutos. Ela se conecta ao field data do CoreDash, identifica o pior gargalo, rastreia a causa raiz no Chrome e gera a correção.

Para métricas específicas: o guia de diagnóstico do LCP mostra como o agente rastreia um Largest Contentful Paint lento pelas quatro fases até a alteração exata no código. O guia de diagnóstico do INP aborda a métrica com a qual os agentes de IA mais têm 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 como gargalo a fase que consome a maior fatia do tempo total, não a fase que ultrapassa um limite absoluto. Isso muda quais correções realmente fazem a diferença.