Agente de IA para monitorização das Core Web Vitals: field data via MCP

Os agentes de programação com IA já se podem ligar a dados de web performance através de servidores MCP. Executam auditorias, localizam estrangulamentos e geram fixes de código num 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 o fix ajuda os utilizadores ou se apenas melhora uma pontuação sintética que a Google ignora.

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

O que os agentes de IA podem fazer hoje com as Core Web Vitals

O Model Context Protocol (MCP) uniformiza a forma como as ferramentas de IA se ligam a fontes de dados externas. Para trabalhar com as Core Web Vitals, há três tipos de servidores que importam.

O Chrome DevTools MCP dá aos agentes controlo direto sobre a área de debugging do Chrome. A Google lançou-o em public preview no final de 2025. Executa traces de performance, analisa a decomposição das fases do LCP, identifica recursos render-blocking e comprime os dados brutos de trace num resumo compacto que um agente consegue processar.

Os servidores MCP do Lighthouse permitem aos agentes executar auditorias completas de forma programática. Existem várias implementações no GitHub. Úteis para auditorias em massa a muitas páginas. Os resultados são lab data: testes sintéticos num dispositivo simulado com uma ligação de rede simulada.

Os servidores MCP de RUM ligam os agentes a dados de Real User Monitoring dos visitantes reais. O CoreDash é atualmente a única plataforma comercial de RUM com um servidor MCP integrado, que expõe field data em tempo real a qualquer agente de programação compatível com MCP.

O workflow que os três viabilizam é um ciclo de medir, corrigir e voltar a medir. O agente identifica um estrangulamento, gera um fix de código, aplica-o e volta a testar. O tipo de dados que o agente usa determina se o fix ajuda de facto os utilizadores reais.

O problema dos agentes que só usam o Lighthouse

A Google não usa pontuações do Lighthouse para os rankings. A Google usa field data do CrUX de utilizadores reais do Chrome ao longo de uma janela móvel de 28 dias. Um agente que executa o Lighthouse, faz alterações e volta a executar o Lighthouse completou um ciclo que não serve de nada para a visibilidade nas pesquisas.

A diferença entre lab e field é real. O Web Almanac de 2025 mostra que 52% dos websites móveis falham pelo menos uma Core Web Vital em field data. Muitos desses sites obtêm boas pontuações no Lighthouse.

O INP é o maior ponto cego. O INP mede a rapidez de resposta do site a cliques, toques e pressões de teclas reais ao longo de sessões inteiras de utilizadores. Não há 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 tem qualquer garantia de que o INP real tenha melhorado.

Um estudo sobre 33 596 pull requests criados por agentes (Alam et al., janeiro de 2026) concluiu que os PRs de fix gerados por IA têm uma taxa de merge global de 65%. Mais de um terço é rejeitado por revisores humanos. Os fixes de performance exigem um contexto que os lab data sozinhos não conseguem fornecer.

O que os field data oferecem que os lab data não conseguem

O Real User Monitoring recolhe dados de performance de todos os visitantes em todos os dispositivos. Quando um agente se liga ao RUM em vez do Lighthouse, mudam três coisas.

Sabe que páginas estão realmente lentas para o público. E não quais as páginas com má pontuação num teste sintético num Moto G Power simulado em 4G. Os utilizadores podem estar com iPhones na Alemanha ligados por fibra. Ou com Androids económicos na Indonésia numa rede móvel congestionada. Os field data refletem o que os utilizadores experienciam na realidade.

O CoreDash dá ao agente atribuição ao nível do elemento. O elemento específico que causou o LCP lento. O ficheiro JavaScript por trás do INP lento (através de dados de Long Animation Frames). O nó do DOM que se deslocou. O agente faz o rastreio desde a métrica até ao código exato, sem adivinhações.

E consegue verificar se o fix funcionou. Depois do deploy de uma alteração, o agente consulta os field data para confirmar se os utilizadores reais registaram melhorias. Este é o passo que a maioria dos workflows de IA ignora por completo. É o único passo que realmente importa para os rankings.

O workflow completo passa a ser: encontrar o problema nos field data, rastrear a causa no Chrome, corrigir o código e verificar com os field data. O agente faz a investigação. A decisão do que entra em produção é sua.

Próximos passos

O CWV Superpowers é uma skill gratuita para o Claude Code que automatiza todo este workflow. A configuração demora dois minutos. Liga-se aos field data do CoreDash, identifica o principal estrangulamento, rastreia a causa-raiz no Chrome e gera o fix.

Para métricas específicas: o guia de diagnóstico do LCP explica detalhadamente como o agente rastreia um Largest Contentful Paint lento ao longo das quatro fases até à alteração de código exata. O guia de diagnóstico do INP aborda a métrica com que os agentes de IA têm mais dificuldades, dado que não pode ser simulada em laboratório.

O conceito por trás do diagnóstico é o raciocínio proporcional: o agente identifica como estrangulamento a fase que consome a maior parcela do tempo total, e não a fase que ultrapassa um limiar absoluto. Isso muda quais os fixes que realmente fazem a diferença.