KI-Agent für Core-Web-Vitals-Monitoring: Field Data über MCP

KI-Coding-Agenten können sich jetzt über MCP-Server mit Web-Performance-Daten verbinden. Sie führen Audits aus, analysieren Bottlenecks und generieren Code-Fixes in einem automatisierten Loop. Dafür gibt es drei Arten von MCP-Servern: Chrome DevTools, Lighthouse und Real User Monitoring. Die Datenquelle entscheidet, ob der Fix deinen Nutzern hilft oder nur einen synthetischen Score verbessert, den Google ignoriert.

Zuletzt geprüft von Arjen Karel im März 2026

Was KI-Agenten heute mit Core Web Vitals machen können

Das Model Context Protocol (MCP) standardisiert, wie sich KI-Tools mit externen Datenquellen verbinden. Für die Arbeit an den Core Web Vitals sind drei Arten von Servern wichtig.

Chrome DevTools MCP gibt Agenten direkte Kontrolle über die Debugging-Oberfläche von Chrome. Google hat das Ende 2025 als Public Preview veröffentlicht. Es führt Performance-Traces aus, analysiert die Aufschlüsselung der LCP-Phasen, identifiziert Render-Blocking-Ressourcen und komprimiert rohe Trace-Daten zu einer kompakten Zusammenfassung, die ein Agent parsen kann.

Lighthouse-MCP-Server lassen Agenten komplette Audits programmatisch ausführen. Auf GitHub gibt es mehrere Implementierungen. Praktisch für Bulk-Audits über viele Seiten. Die Ergebnisse sind Lab Data: synthetische Tests auf einem simulierten Gerät mit einer simulierten Netzwerkverbindung.

RUM-MCP-Server verbinden Agenten mit Real-User-Monitoring-Daten deiner echten Besucher. CoreDash ist derzeit die einzige kommerzielle RUM-Plattform mit integriertem MCP-Server und liefert Live-Field-Data an jeden MCP-kompatiblen Coding-Agenten.

Alle drei ermöglichen denselben Workflow: einen Loop aus Messen, Fixen und Nachmessen. Der Agent identifiziert einen Bottleneck, generiert einen Code-Fix, wendet ihn an und testet erneut. Welche Daten der Agent dafür nutzt, entscheidet darüber, ob der Fix echten Nutzern wirklich hilft.

Das Problem mit reinen Lighthouse-Agenten

Google nutzt keine Lighthouse-Scores für Rankings. Google nutzt CrUX-Field-Data von echten Chrome-Nutzern über ein rollierendes Fenster von 28 Tagen. Ein Agent, der Lighthouse ausführt, Änderungen vornimmt und Lighthouse erneut startet, hat einen Loop abgeschlossen, der für deine Sichtbarkeit in der Suche nichts bringt.

Die Kluft zwischen Lab und Field ist real. Der Web Almanac 2025 zeigt, dass 52 % der mobilen Websites mindestens einen Core Web Vital in den Field Data verfehlen. Viele dieser Seiten schneiden in Lighthouse gut ab.

Der INP ist der größte blinde Fleck. Der INP misst, wie schnell deine Seite über die gesamte Nutzersitzung hinweg auf echte Klicks, Taps und Tastendrücke reagiert. Im Lab gibt es dafür kein Äquivalent. Lighthouse nutzt die Total Blocking Time als Proxy, aber die TBT misst das Blockieren des Threads während des Ladens. Der INP misst die Antwortzeit bei echten Interaktionen zu unvorhersehbaren Zeitpunkten. Wenn ein Agent deine TBT „fixt“, garantiert das noch lange nicht, dass sich dein echter INP verbessert hat.

Eine Studie über 33.596 von Agenten erstellte Pull-Requests (Alam et al., Januar 2026) ergab, dass KI-generierte Fix-PRs eine Merge-Rate von insgesamt 65 % haben. Mehr als ein Drittel wird von menschlichen Reviewern abgelehnt. Performance-Fixes erfordern Kontext, den Lab Data allein nicht liefern kann.

Was Field Data liefert, was Lab Data nicht kann

Real User Monitoring erfasst Performance-Daten von jedem Besucher auf jedem Gerät. Wenn sich ein Agent mit RUM statt mit Lighthouse verbindet, ändern sich drei Dinge.

Er weiß, welche Seiten für deine Zielgruppe tatsächlich langsam sind. Nicht, welche Seiten in einem synthetischen Test auf einem simulierten Moto G Power über 4G schlecht abschneiden. Deine Nutzer sitzen vielleicht mit iPhones in Deutschland an einem Glasfaseranschluss. Oder an günstigen Android-Geräten in Indonesien in einem überlasteten Mobilfunknetz. Field Data spiegelt wider, was sie tatsächlich erleben.

CoreDash liefert dem Agenten eine Attribution auf Elementebene. Das konkrete Element, das den langsamen LCP verursacht hat. Die JavaScript-Datei hinter dem langsamen INP (über Daten der Long Animation Frames). Der DOM-Knoten, der sich verschoben hat. Der Agent verfolgt den Pfad von der Metrik bis zum exakten Code – ganz ohne Raten.

Und er kann verifizieren, dass der Fix funktioniert hat. Nach dem Deployen einer Änderung fragt der Agent Field Data ab, um zu bestätigen, dass echte Nutzer tatsächlich eine Verbesserung sehen. Diesen Schritt überspringen die meisten KI-Workflows komplett. Dabei ist es der einzige Schritt, der für deine Rankings zählt.

Der vollständige Workflow lautet also: Problem in den Field Data finden, Ursache in Chrome aufspüren, Code fixen, mit Field Data verifizieren. Der Agent übernimmt die Analyse. Du entscheidest, was live geht.

So geht es weiter

CWV Superpowers ist ein kostenloser Claude-Code-Skill, der diesen gesamten Workflow automatisiert. Das Setup dauert zwei Minuten. Er verbindet sich mit den Field Data von CoreDash, identifiziert deinen größten Bottleneck, spürt die Ursache in Chrome auf und generiert den Fix.

Für einzelne Metriken: Der LCP-Diagnose-Guide zeigt Schritt für Schritt, wie der Agent einen langsamen Largest Contentful Paint über seine vier Phasen bis zur exakten Code-Änderung zurückverfolgt. Der INP-Diagnose-Guide behandelt die Metrik, mit der KI-Agenten die größten Probleme haben – weil sie sich nicht im Lab simulieren lässt.

Das Konzept hinter der Diagnose ist Proportional Reasoning: Der Agent identifiziert als Bottleneck die Phase, die den größten Anteil der Gesamtzeit ausmacht – nicht die Phase, die einen absoluten Schwellenwert überschreitet. Das ändert grundlegend, welche Fixes wirklich etwas bringen.