AI en Core Web Vitals: Hoe AI-agenten web performance debuggen (2026)

AI-codingagenten zoals Claude Code, Cursor en GitHub Copilot kunnen nu via MCP-servers verbinding maken met live web performance-data. Hierdoor kunnen ze Core Web Vitals meten, problemen diagnosticeren en code-oplossingen genereren in een geautomatiseerde loop. Tot voor kort konden agenten alleen met lab data werken. Ze optimaliseerden voor Lighthouse-scores die niets te maken hebben met je Google-rankings. Dat veranderde toen Real User Monitoring-data toegankelijk werd via MCP. Een agent die verbonden is met field data, kan een trage metric traceren van echte gebruikerssessies tot aan de exacte regel code die het probleem veroorzaakt. Je beoordeelt nog steeds elke fix. Maar het onderzoek dat vroeger uren in beslag nam, kost nu slechts minuten.

Laatst beoordeeld door Arjen Karel in maart 2026

Wat AI-agenten vandaag de dag kunnen met Core Web Vitals

Het Model Context Protocol (MCP), in november 2024 geïntroduceerd door Anthropic en in december 2025 gedoneerd aan de Agentic AI Foundation van de Linux Foundation, standaardiseert hoe AI-tools verbinding maken met externe databronnen. Zie het als een universele stekker tussen je AI-codingagent en je performance tooling. Het ecosysteem is gegroeid naar meer dan 10.000 gepubliceerde MCP-servers met 97 miljoen maandelijkse SDK-downloads (bron: Pento, "A Year of MCP" review).

Voor werk aan Core Web Vitals zijn drie soorten MCP-servers van belang:

Google's Chrome DevTools MCP Server is de grootste ontwikkeling. Vrijgegeven in public preview eind 2025, geeft het AI-agenten directe controle over het debug-oppervlak van Chrome. De server kan performance traces uitvoeren, LCP-breakdowns analyseren (TTFB, Resource Load Delay, Resource Load Duration, Element Render Delay), render-blocking resources identificeren en netwerkafhankelijkheidsbomen meten. Een noemenswaardig technisch detail: het comprimeert ongeveer 30MB aan ruwe performance trace-data tot zo'n 4KB aan tekst die een AI-agent daadwerkelijk kan verwerken.

Lighthouse MCP servers laten agenten programmatisch volledige performance-audits uitvoeren. Er bestaan meerdere implementaties op GitHub, die tools aanbieden zoals run_audit, get_core_web_vitals, compare_mobile_desktop en find_unused_javascript. Nuttig voor bulk-auditing. Onthoud echter: dit zijn lab scores. Ze vertellen je wat er traag zou kunnen zijn. Niet wat er daadwerkelijk traag is voor je gebruikers.

RUM MCP servers verbinden agenten met Real User Monitoring-data. CoreDash is momenteel het enige commerciële RUM-platform met een ingebouwde MCP-server, die live field data blootstelt aan AI-agenten. Dit is het puzzelstuk dat alles verandert. Hierover hieronder meer.

De workflow die deze tools mogelijk maken is een measure, fix, re-measure loop. Een agent voert een Lighthouse-audit of performance trace uit, identificeert de grootste bottleneck, genereert een code-fix, past deze toe en test opnieuw. In een gedocumenteerde casus verlaagde deze geautomatiseerde loop de LCP met meer dan 50% in één enkele sessie. Dat klinkt indrukwekkend. En dat is het ook. Voor lab data.

Wat er misgaat zonder field data

Voordat je je Core Web Vitals overdraagt aan een AI-agent die op Lighthouse draait, is dit wat je moet weten.

AI-agenten zijn zelfverzekerd, niet altijd correct. Een agent zal je LCP "fixen" en je vertellen dat de performance is verbeterd. Het optimaliseerde voor een synthetische Lighthouse-run op een gesimuleerd apparaat met een gesimuleerd netwerk. Je daadwerkelijke doelgroep bevindt zich misschien in Duitsland op iPhones met glasvezelverbindingen. De agent weet dit niet. Het controleert het niet. Het vertelt je alleen dat het getal is gedaald.

Ze breken dingen waar je ze niet om hebt gevraagd aan te raken. Performance-optimalisatie zit vol compromissen. Het uitstellen (deferring) van een script verbetert INP, maar kan een kritieke above-the-fold interactie breken. Lazy loading bespaart bandbreedte maar vertraagt de LCP als het op de verkeerde afbeelding wordt toegepast. Een AI-agent begrijpt je bedrijfslogica niet. Het weet niet dat het A/B-testing script omzetexperimenten uitvoert. Het weet niet dat de chat-widget die je stakeholders eisen, onaanraakbaar is.

De data ondersteunt dit. Een studie van 33.596 door agenten geschreven pull requests (Ehsani et al., januari 2026) toonde aan dat performance- en bugfix-PR's de laagste merge-succespercentages hebben met 55 tot 64 procent, vergeleken met 84 procent voor documentatie-PR's. Meer dan een derde van de door AI gegenereerde performance-fixes wordt afgewezen door menselijke reviewers. Dat is wat er gebeurt wanneer een agent optimaliseert zonder het volledige plaatje te begrijpen.

Deze problemen zijn reëel. Maar het zijn geen problemen met AI-agenten. Het zijn problemen met blinde AI-agenten. Een agent die geen field data heeft, is aan het gokken. Geef het echte data van echte gebruikers en de situatie verandert compleet.

Lab data creëert een vals gevoel van veiligheid

Dit sluit direct aan bij het onderscheid tussen field data en lab data dat zo belangrijk is voor alles wat met Core Web Vitals te maken heeft.

De meeste AI-agent workflows draaien tegenwoordig op Lighthouse-data. De agent auditeert een pagina, ziet een score, maakt wijzigingen, auditeert opnieuw, en ziet een betere score. Loop voltooid. Maar Google gebruikt geen Lighthouse-scores voor rankings. Google gebruikt CrUX field data van echte Chrome-gebruikers over een voortschrijdende periode van 28 dagen.

Een agent die Lighthouse draait, wijzigingen aanbrengt en Lighthouse opnieuw draait, heeft een loop voltooid die vrijwel niets betekent voor je zoekrankings. De HTTP Archive Web Almanac 2025 laat zien dat 52 procent van de mobiele websites faalt op minstens één Core Web Vital in field data. Veel van die sites hebben prima Lighthouse-scores.

INP is vooral problematisch in lab-omgevingen. INP meet de responsiviteit over volledige sessies van echte gebruikers met onvoorspelbare interactiepatronen. Er is geen lab-equivalent. Lighthouse gebruikt Total Blocking Time als een proxy, maar de correlatie is op z'n best zwak. Een agent die je TBT "fixt", biedt geen garantie dat je daadwerkelijke INP is verbeterd.

De Chrome DevTools MCP-server overbrugt deze kloof deels. Het kan CrUX-data ophalen naast lab traces wanneer het draait met de --performance-crux flag (standaard ingeschakeld). Dat vertelt de agent dat een metric traag is in de field data. Maar CrUX wordt geaggregeerd over 28 dagen, dekt alleen Chrome-gebruikers die hebben ingestemd met gebruiksstatistieken, en vereist grofweg 300 of meer maandelijkse pageviews per URL om überhaupt data te hebben. CrUX vertelt je dat er iets traag is. Het vertelt je niet waarom.

Hoe RUM-data alles verandert

Real User Monitoring (RUM) verzamelt performance-data van elke echte bezoeker op elk echt apparaat. Wanneer je een AI-agent verbindt met RUM-data in plaats van lab data, stopt de agent met gokken en begint het te werken met dezelfde realiteit die je gebruikers ervaren.

CoreDash wordt geleverd met een ingebouwde MCP-server die live, per-sessie field data blootstelt aan elke MCP-compatibele codingagent. De server stelt twee tools beschikbaar: get_metrics (huidige momentopname van elke Core Web Vital, gefilterd op 25+ dimensies waaronder het LCP-element, INP-interactiedoelwit, apparaattype, land, URL-pad) en get_timeseries (trends door de tijd heen met automatische regressiedetectie). Wanneer de agent verbinding maakt, leert de server de agent alles via het protocol zelf. Er zijn geen aangepaste prompts nodig.

Maar de echte verschuiving zit hem niet in het stellen van vragen over je data. Het is wat er gebeurt wanneer je de CoreDash MCP verbindt met een codingagent zoals Claude Code. De agent volgt de attributieketen helemaal vanaf een field data-symptoom tot aan een specifiek bestand in je repository. Het stopt niet bij vertellen wat er traag is. Het opent de code en stelt de fix voor.

Hier is hoe dat er in de praktijk uitziet.

LCP: field data naar code fix. CoreDash field data toont dat de p75 LCP 4.2s is op mobiele productpagina's. De lcpel-attributie wijst naar div.hero-image > img. De agent opent je template, ziet dat de afbeelding wordt geladen via JavaScript zonder fetchpriority-attribuut en met loading="lazy" op de hero-afbeelding. Dit is een klassiek slow by mistake patroon. De agent voegt fetchpriority="high" toe, verwijdert het lazy attribuut en voegt een preload link toe. Je beoordeelt de diff, merged het en doet een deploy. CoreDash bevestigt de volgende dag dat de LCP is gedaald naar 2.1s.

INP: field data naar code fix. CoreDash toont dat de p75 INP 380ms is op de checkout-pagina. De inpel-attributie wijst naar de filter-dropdown. LoAF-data in de sessie toont dat filterPanel.js de main thread 280ms blokkeert bij een interactie. De agent opent dat bestand, identificeert een synchrone DOM-update binnen de event handler, en stelt yielding to the main thread voor met scheduler.yield() of het debouncen van het zware werk. Je beoordeelt, merged en doet een deploy. CoreDash bevestigt dat de INP is gedaald naar 140ms.

Er is in die hele loops nergens een Lighthouse-score aan te pas gekomen. De agent traceerde vanaf de pijn van de echte gebruiker naar de exacte regel code, stelde een specifieke wijziging voor, en jij verifieerde na de deploy dat het werkte bij echte gebruikers.

Een agent verbonden met lab data gokt wat zou kunnen helpen. Een agent verbonden met field data inclusief attributie, weet wat er daadwerkelijk mis is en waar in je code het gefixt moet worden. Dat is geen incrementele verbetering. Dat is een fundamenteel andere workflow.

Dat gezegd hebbende, heeft elke fix nog steeds jouw review nodig. Een AI-agent kan je vertellen dat een specifiek third-party script zorgt voor 200ms input delay op je checkout-pagina. Of je dat script kunt verwijderen, uitstellen of vervangen, is een zakelijke beslissing die de agent niet voor jou kan maken. De agent begrijpt je verdienmodel, je stakeholder-afspraken of je release-proces niet. Wat het wél doet, is de uren aan handmatig onderzoek elimineren tussen "iets is traag" en "dit is exact wat je moet veranderen."

Hoe je kunt beginnen

Elke grote AI-codingtool ondersteunt nu MCP: Claude Code, Cursor, GitHub Copilot in VS Code (agent mode sinds VS Code 1.99, maart 2025), Gemini CLI, Windsurf, Cline en JetBrains IDE's. De setup kost nog geen twee minuten per server.

De snelste manier om aan de slag te gaan is met Claude Code en alle drie de servers. Eén commando per server:

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
claude mcp add lighthouse -- npx @danielsogl/lighthouse-mcp@latest
claude mcp add coredash --transport http https://app.coredash.app/api/mcp --header "Authorization: Bearer cdk_YOUR_API_KEY"

Typ /mcp in Claude Code. Je zou ze nu alle drie als verbonden moeten zien staan. Dat is alles.

Voor de CoreDash API-sleutel: ga naar je CoreDash-dashboard, Project Settings, het tabblad API Keys (MCP). Genereer een sleutel en kopieer deze direct. Deze wordt één keer getoond en alleen opgeslagen als een SHA-256 hash. Elke sleutel is gescoped op een enkel project. Alleen lezen. Geen schrijfpad.

Voor Cursor, VS Code of andere clients ziet de gecombineerde config er zo uit. Maak .cursor/mcp.json (Cursor) of .mcp.json (Claude Code op projectniveau) aan in de root van je project:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    },
    "lighthouse": {
      "command": "npx",
      "args": ["@danielsogl/lighthouse-mcp@latest"]
    },
    "coredash": {
      "url": "https://app.coredash.app/api/mcp",
      "headers": {
        "Authorization": "Bearer cdk_YOUR_API_KEY"
      }
    }
  }
}

Belangrijk: VS Code gebruikt een ander config-formaat. De top-level sleutel is "servers" (niet "mcpServers") en lokale servers hebben een "type": "stdio"-veld nodig, terwijl externe servers (zoals CoreDash) "type": "http" nodig hebben. Bekijk de VS Code MCP-documentatie voor het exacte formaat. Voor gedetailleerde setup-instructies per client, zie de CoreDash MCP server setup guide.

Tip: Addy Osmani (Google Chrome-team) publiceerde web-quality-skills, een verzameling van agent skills die coderen voor meer dan 150 Lighthouse-audits en Core Web Vitals-optimalisatiepatronen. Installeer met npx add-skill addyosmani/web-quality-skills. Dit is geen MCP-server. Het leert je agent waar hij op moet letten en hoe hij het kan repareren. Combineer het met de Chrome DevTools MCP voor de beste resultaten: de skills bieden de optimalisatiekennis, de MCP-server levert de data.

De Volledige Workflow: Field naar Fix naar Field

Hier is hoe een echte debug-sessie eruitziet als alle drie de servers draaien. Elke server dekt een ander deel van de loop af: CoreDash vertelt je wat er mis is, Chrome DevTools vertelt je waarom, en CoreDash bevestigt dat de fix heeft gewerkt.

Stap 1: Vind het probleem in de field data.

Which pages have the worst LCP this week? Break it down by device type.

CoreDash geeft als resultaat dat /product-pagina's een p75 LCP van 4,2 seconden hebben op mobiel, waarbij 38% van de paginaweergaven als 'poor' wordt beoordeeld. Het LCP-element (vanuit de lcpel dimensie) is div.hero-image > img. Nu ken je het echte probleem op het exacte element. Niet wat een Lighthouse-simulatie denkt dat het probleem zou kunnen zijn.

Stap 2: Begrijp het waarom.

Emulate a mid-range Android device on a Fast 3G connection,
then run a performance trace on https://example.com/product/123 with page reload.
Analyze the LCP breakdown.

Chrome DevTools MCP draait een throttled trace en geeft de LCP-onderdelen terug: TTFB 380ms, Resource Load Delay 1.200ms, Resource Load Duration 890ms, Element Render Delay 340ms. De bottleneck is duidelijk: de hero-afbeelding is niet vindbaar in de initiële HTML (geladen via JavaScript), waardoor de browser niet kan beginnen met het ophalen ervan totdat het script wordt uitgevoerd.

Stap 3: Fix de code.

Analyze the LCP Discovery insight for this page.
Then fix the issue in my codebase.

De agent roept performance_analyze_insight aan voor LCPDiscovery en rapporteert dat de afbeelding op drie checks faalt: geen fetchpriority="high", lazy loading wordt toegepast, en het request is niet vindbaar in het initiële document. Met Claude Code opent de agent het template-bestand, voegt de preload link toe, stelt fetchpriority="high" in op de hero-afbeelding, en verwijdert loading="lazy". Jij beoordeelt de diff.

Stap 4: Valideer lokaal.

Run another performance trace on http://localhost:3000/product/123
with the same throttling. Compare the LCP to the previous trace.

De LCP is lokaal gedaald van 2.8s naar 1.4s. Mooi. Maar dit is nog steeds lab data op een enkele machine. Ship de fix naar productie.

Stap 5: Verifieer bij echte gebruikers. Dit is de stap die de meeste AI-workflows volledig overslaan. Het is de enige stap die er daadwerkelijk toe doet voor je rankings.

Compare LCP on /product pages between last week and this week.
Mobile only. Use hourly granularity for the last 48 hours.

CoreDash laat zien dat de p75 LCP voor echte gebruikers is gedaald van 4.2s naar 2.1s op mobiel. Poor page loads gingen van 38% naar 9%. De trend is geclassificeerd als "improving" met een reductie van 50%. De fix werkte voor daadwerkelijke gebruikers, niet alleen in je lokale Chrome-installatie.

Field data vertelde je wat er mis was. Lab data vertelde je waarom. De agent schreef de fix. Field data bevestigde dat het werkte. Geen enkele stap in die keten vereiste dat je een dashboard moest openen, door segmenten moest klikken of handmatig een performance trace moest ontleden. De agent deed het voorwerk. Jij nam de beslissingen.

Waar dit naartoe gaat

Google heeft een officiële Chrome DevTools MCP-server gebouwd. Addy Osmani heeft agent skills gepubliceerd voor web quality-optimalisatie. MCP is gedoneerd aan een werkgroep van de Linux Foundation, mede opgericht door Anthropic, OpenAI, Amazon, Google en Microsoft.

AI-agenten zullen steeds beter worden in web performance-werk. Cross-browser ondersteuning voor Core Web Vitals is gearriveerd: Firefox voegde INP-ondersteuning toe in versie 144 (oktober 2025) en Safari introduceerde LCP en INP in versie 26.2 (december 2025). LCP en INP zijn nu Baseline Newly Available in alle grote browsers. Meer browsers die meten betekent meer field data, wat betekent dat er meer signaal is voor agenten om mee te werken.

Maar de tools zijn slechts zo goed als de data die je ze voert. Een agent die op Lighthouse draait, doet wat elke developer in 30 minuten kan doen. Een agent verbonden met je echte gebruikersdata, met attributie tot op het element en het script, doet iets wat voorheen uren aan handmatig onderzoek kostte. Dat is de verschuiving. Niet "AI fixt je Core Web Vitals." Het is "AI traceert het probleem in enkele minuten van echte gebruikers naar code." Jij beslist nog steeds wat er gemerged wordt. Jij begrijpt nog steeds de compromissen. Maar de tijd tussen "iets is traag" en "hier is de pull request" is zojuist een stuk korter geworden.

De developers die het meest zullen profiteren van deze tools, zijn degenen die Core Web Vitals al goed genoeg begrijpen om in te schatten of een door AI gegenereerde fix correct is. Als je niet begrijpt waarom het uitstellen (deferring) van een script INP kan breken, dan zal een agent die scripts voor je uitstelt voor problemen gaan zorgen. Deze tools maken goede developers sneller. Ze vervangen niet de kennis die nodig is om dit werk goed te doen.