Agente AI per il monitoraggio dei Core Web Vitals: field data via MCP

Gli agenti AI di coding possono ora collegarsi ai dati di web performance tramite server MCP. Eseguono audit, individuano i colli di bottiglia e generano fix al codice in un loop automatizzato. Per questo lavoro esistono tre tipi di server MCP: Chrome DevTools, Lighthouse e Real User Monitoring. La sorgente dei dati determina se il fix aiuta gli utenti o migliora solo un punteggio sintetico che Google ignora.

Ultima revisione a cura di Arjen Karel a marzo 2026

Cosa possono fare oggi gli agenti AI con i Core Web Vitals

Il Model Context Protocol (MCP) standardizza il modo in cui gli strumenti AI si collegano a sorgenti dati esterne. Per lavorare sui Core Web Vitals, contano tre tipi di server.

Chrome DevTools MCP dà agli agenti il controllo diretto sull'interfaccia di debug di Chrome. Google lo ha rilasciato in public preview a fine 2025. Esegue trace di performance, analizza la suddivisione in fasi del LCP, identifica le risorse render blocking e comprime i dati grezzi dei trace in un riassunto compatto che un agente può analizzare.

I server MCP per Lighthouse permettono agli agenti di eseguire audit completi in modo programmatico. Su GitHub esistono diverse implementazioni. Utili per audit massivi su molte pagine. I risultati sono lab data: test sintetici su un dispositivo simulato con una connessione di rete simulata.

I server MCP per RUM collegano gli agenti ai dati di Real User Monitoring dei visitatori reali. CoreDash è al momento l'unica piattaforma RUM commerciale con un server MCP integrato, in grado di esporre field data in tempo reale a qualsiasi agente di coding compatibile con MCP.

Il workflow abilitato da tutti e tre è un loop misura-correggi-rimisura. L'agente individua un collo di bottiglia, genera un fix al codice, lo applica e ripete il test. Il tipo di dati usato dall'agente determina se il fix aiuta davvero gli utenti reali.

Il problema degli agenti basati solo su Lighthouse

Google non usa i punteggi di Lighthouse per il ranking. Google usa i field data di CrUX raccolti da utenti reali di Chrome su una finestra mobile di 28 giorni. Un agente che esegue Lighthouse, applica modifiche e riesegue Lighthouse completa un loop che non conta nulla per la visibilità nella ricerca.

Il divario tra lab e field è reale. Il Web Almanac 2025 mostra che il 52% dei siti web mobile non supera almeno un Core Web Vital nei field data. Molti di questi siti ottengono buoni punteggi su Lighthouse.

L'INP è il punto cieco più grande. L'INP misura la velocità di risposta del sito a click, tap e pressioni dei tasti reali durante intere sessioni utente. Non esiste un equivalente in lab. Lighthouse usa il Total Blocking Time come proxy, ma il TBT misura il blocco del thread durante il caricamento della pagina. L'INP misura il tempo di risposta durante interazioni reali che avvengono in momenti imprevedibili. Un agente che "corregge" il TBT non dà alcuna garanzia che l'INP reale sia migliorato.

Uno studio su 33.596 pull request create da agenti (Alam et al., gennaio 2026) ha rilevato che le PR di fix generate dall'AI hanno un merge rate complessivo del 65%. I revisori umani ne respingono oltre un terzo. I fix di performance richiedono un contesto che i lab data da soli non possono fornire.

Cosa danno i field data che i lab data non possono dare

Il Real User Monitoring raccoglie dati di performance da ogni visitatore su ogni dispositivo. Quando un agente si collega al RUM invece che a Lighthouse, cambiano tre cose.

Sa quali pagine sono davvero lente per gli utenti. Non quali pagine ottengono un punteggio basso in un test sintetico su un Moto G Power simulato in 4G. Gli utenti potrebbero navigare con un iPhone su fibra in Germania. O con un Android economico in Indonesia su una rete mobile congestionata. I field data riflettono quello che sperimentano davvero.

CoreDash dà all'agente un'attribuzione a livello di singolo elemento. L'elemento specifico che ha causato il LCP lento. Il file JavaScript responsabile dell'INP lento (tramite i dati di Long Animation Frames). Il nodo DOM che si è spostato. L'agente risale dalla metrica al codice esatto, senza tirare a indovinare.

E può verificare che il fix abbia funzionato. Dopo il deploy di una modifica, l'agente interroga i field data per confermare il miglioramento per gli utenti reali. È il passaggio che la maggior parte dei workflow AI salta del tutto. È l'unico passaggio che conta per il ranking.

Il workflow completo diventa: individua il problema nei field data, risali alla causa in Chrome, correggi il codice, verifica con i field data. L'agente svolge l'indagine. Tu decidi cosa mandare in produzione.

I prossimi passi

CWV Superpowers è una skill gratuita per Claude Code che automatizza l'intero workflow. Il setup richiede due minuti. Si collega ai field data di CoreDash, individua il collo di bottiglia peggiore, risale alla causa principale in Chrome e genera il fix.

Per le singole metriche: la guida alla diagnosi del LCP spiega come l'agente esamina le quattro fasi di un Largest Contentful Paint lento fino all'esatta modifica del codice. La guida alla diagnosi dell'INP tratta la metrica più ostica per gli agenti AI, perché non può essere simulata in lab.

Il concetto alla base della diagnosi è il ragionamento proporzionale: l'agente individua il collo di bottiglia nella fase che consuma la quota maggiore del tempo totale, non in quella che supera una soglia assoluta. Questo cambia quali fix fanno davvero la differenza.