Core Web Vitals en AI: waarom snelheid telt voor citaties

Waarom Core Web Vitals ertoe doen voor AI-citaties

Wanneer AI-modellen zoals ChatGPT, Perplexity en Gemini content ophalen van het web, hebben ze een beperkt tijdsbudget per pagina. Een pagina die traag laadt of waarvan de DOM pas na seconden stabiliseert, levert minder bruikbare data op binnen dat tijdsvenster. Het gevolg is dat trage websites structureel minder worden geciteerd in AI-gegenereerde antwoorden. Core Web Vitals, de prestatiemetrieken die Google in 2021 introduceerde, zijn daarmee niet langer uitsluitend een SEO-factor. Ze zijn een directe voorwaarde geworden voor AI-zichtbaarheid.

Dit sluit nauw aan bij de bredere technische eisen die AI-modellen stellen aan websites. In ons artikel over AEO en waarom het belangrijk is bespreken we hoe technische machine-leesbaarheid een van de drie pijlers vormt van effectieve AI-optimalisatie. Core Web Vitals zijn het fundament van die technische pijler.

De drie Core Web Vitals uitgelegd

Google meet de gebruikerservaring van een webpagina aan de hand van drie kerncijfers. Elk cijfer vertelt iets anders over hoe prettig (of onprettig) het is om een pagina te bezoeken, en elk heeft een eigen impact op hoe AI-crawlers je content verwerken.

Largest Contentful Paint (LCP)

LCP meet hoe lang het duurt voordat het grootste zichtbare element op de pagina is geladen. Dit kan een hero-afbeelding zijn, een grote kop of een videoframe. Google beschouwt een LCP onder de 2,5 seconden als goed, tussen 2,5 en 4 seconden als matig, en boven de 4 seconden als slecht.

Voor AI-crawlers is LCP bijzonder relevant. Wanneer een crawler als PerplexityBot of GPTBot je pagina opvraagt, wacht deze niet eindeloos op de volledige render. Als je primaire content pas na 4 seconden beschikbaar is, mist de crawler mogelijk de belangrijkste informatie. Het resultaat: je pagina wordt wel bezocht maar niet effectief geindexeerd.

Interaction to Next Paint (INP)

INP verving First Input Delay (FID) in maart 2024 en meet hoe responsief een pagina reageert op gebruikersinteracties. Een INP onder de 200 milliseconden is goed. Hoewel AI-crawlers niet klikken of scrollen, is INP indirect relevant. Een hoge INP duidt vaak op een zware JavaScript-belasting die ook de initiele DOM-opbouw vertraagt, wat crawlers wel merken.

Cumulative Layout Shift (CLS)

CLS meet de visuele stabiliteit van een pagina: hoeveel elementen verspringen tijdens het laden. Een CLS onder de 0,1 is goed. Voor AI-crawlers die de DOM parsen, kan een hoge CLS betekenen dat content-elementen pas laat hun definitieve positie innemen. Crawlers die de pagina op een vroeg moment parsen, zien dan mogelijk een onvolledige of verminkte versie van je content.

# Ideale Core Web Vitals scores voor AI-zichtbaarheid
# Meet met Google PageSpeed Insights of Lighthouse

LCP  (Largest Contentful Paint):   < 2.5s  (goed)
INP  (Interaction to Next Paint):  < 200ms (goed)
CLS  (Cumulative Layout Shift):    < 0.1   (goed)

# Voor maximale AI-crawler compatibiliteit:
Time to First Byte (TTFB):         < 800ms
First Contentful Paint (FCP):      < 1.8s
Server-side rendered HTML:         essentieel

Hoe AI-crawlers snelheid ervaren

Het is belangrijk om te begrijpen dat AI-crawlers niet dezelfde ervaring hebben als een menselijke bezoeker met een browser. De meeste AI-crawlers vragen de ruwe HTML op zonder JavaScript uit te voeren. Dit betekent dat client-side gerenderde content voor hen onzichtbaar kan zijn, ongeacht hoe snel je JavaScript draait.

Dit raakt direct aan het probleem dat we bespreken in ons artikel over robots.txt voor AI: zelfs wanneer je AI-crawlers toestaat je site te bezoeken, moeten ze ook daadwerkelijk bruikbare content ontvangen. Een server die snel een volledig gerenderd HTML-document retourneert, scoort beter dan een server die een leeg HTML-skelet stuurt dat pas via JavaScript wordt gevuld.

• GPTBot en ClaudeBot voeren doorgaans geen JavaScript uit. Ze verwerken alleen de initiele HTML-response.
• PerplexityBot haalt pagina's real-time op en heeft een strikt tijdsbudget per request.
• Googlebot (die ook Gemini voedt) voert wel JavaScript uit, maar met een vertraging. Server-side rendering blijft voordeliger.
• Alle AI-crawlers profiteren van een lage TTFB (Time to First Byte), omdat dit de wachttijd tot de eerste bruikbare data verkort.

Concrete stappen om je Core Web Vitals te verbeteren

Het verbeteren van Core Web Vitals vergt een systematische aanpak. Hieronder staan de meest impactvolle optimalisaties, geordend op verwacht effect.

LCP verbeteren

1. Optimaliseer je server-responstijd. Gebruik caching (Redis, Varnish of een CDN) om TTFB onder de 800ms te krijgen.
2. Preload het LCP-element. Als het een afbeelding is, gebruik dan een preload-link in de head van je document.
3. Serveer afbeeldingen in moderne formaten (WebP of AVIF) en pas ze aan op het juiste formaat voor het weergavegebied.
4. Elimineer render-blokkerende CSS en JavaScript. Laad kritische CSS inline en stel niet-essentieel JavaScript uit.
5. Overweeg server-side rendering (SSR) in plaats van client-side rendering, zodat de HTML al compleet is wanneer crawlers je pagina opvragen.

<!-- Preload LCP afbeelding -->\n<link rel="preload" as="image" href="/images/hero.webp" type="image/webp" fetchpriority="high" />\n\n<!-- Kritische CSS inline laden -->\n<style>\n  .hero { width: 100%; height: auto; }\n  h1 { font-size: 2.5rem; line-height: 1.2; }\n</style>\n\n<!-- Niet-essentieel JavaScript uitstellen -->\n<script src="/js/analytics.js" defer></script>\n<script src="/js/chat-widget.js" async></script>

CLS verbeteren

• Geef altijd expliciete afmetingen op voor afbeeldingen en video's (width en height attributen).
• Reserveer ruimte voor advertenties en embeds met CSS aspect-ratio of min-height.
• Laad webfonts met font-display: swap en preload de belangrijkste font-bestanden.
• Vermijd het dynamisch injecteren van content boven bestaande elementen.

<!-- Expliciete afmetingen voorkomen layout shift -->\n<img src="/images/article-hero.webp"\n     width="1200" height="630"\n     alt="Illustratie van Core Web Vitals metrics"\n     loading="eager"\n     decoding="async" />\n\n<!-- CSS aspect-ratio voor embeds -->\n<style>\n  .video-embed {\n    aspect-ratio: 16 / 9;\n    width: 100%;\n    background: #f0f0f0;\n  }\n</style>

Server-side rendering versus client-side rendering

De keuze tussen server-side rendering (SSR) en client-side rendering (CSR) heeft enorme impact op hoe AI-crawlers je content verwerken. Bij SSR wordt de volledige HTML op de server gegenereerd en als compleet document naar de client gestuurd. Bij CSR ontvangt de client een minimaal HTML-skelet dat pas via JavaScript wordt gevuld met content.

Voor AI-crawlers die geen JavaScript uitvoeren, is het verschil dramatisch. Een SSR-pagina levert direct alle content op, terwijl een CSR-pagina effectief leeg is. Zelfs voor crawlers die wel JavaScript ondersteunen (zoals Googlebot), is SSR voordeliger omdat het de verwerkingstijd drastisch verkort.

Een website die in 1,5 seconde volledige, server-gerenderde HTML serveert, wordt door AI-crawlers tot wel 3x vaker succesvol geindexeerd dan een vergelijkbare SPA die 4 seconden JavaScript-rendering nodig heeft.

Core Web Vitals meten en monitoren

Je kunt je Core Web Vitals op verschillende manieren meten. Elk meetinstrument biedt unieke inzichten.

• Google PageSpeed Insights: combineert velddata (echte gebruikers via CrUX) met labdata (gesimuleerde Lighthouse-test). De meest complete bron voor een eerste analyse.
• Google Search Console: toont Core Web Vitals op paginaniveau voor je hele site. Ideaal om structurele problemen te identificeren.
• Lighthouse (in Chrome DevTools): geeft gedetailleerde aanbevelingen per pagina. Draai dit in een incognito-venster voor onbevooroordeelde resultaten.
• Web Vitals JavaScript Library: meet Core Web Vitals in de browsers van je echte bezoekers. Essentieel voor continue monitoring.

// Core Web Vitals meten met de web-vitals library
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,  // 'good', 'needs-improvement', of 'poor'
    delta: metric.delta,
    id: metric.id,
  });
  navigator.sendBeacon('/api/vitals', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Samenvatting: de belangrijkste punten

• Core Web Vitals (LCP, INP, CLS) beinvloeden direct hoe effectief AI-crawlers je content kunnen ophalen en verwerken.
• Een LCP boven de 4 seconden betekent dat AI-crawlers mogelijk je belangrijkste content missen vanwege hun beperkte tijdsbudget.
• Server-side rendering is essentieel voor AI-zichtbaarheid, omdat de meeste AI-crawlers geen JavaScript uitvoeren.
• Investeer in een lage TTFB (onder 800ms) en preload kritische elementen voor de snelste mogelijke contentlevering.
• Meet continu je Core Web Vitals met Google Search Console en de web-vitals library om regressies vroegtijdig te detecteren.

Veelgestelde vragen

Snelheid is geen luxe meer. Voor AI-crawlers is het een harde voorwaarde om je content uberhaupt te kunnen verwerken.