Je gebruiker tikt op een filterknop—300 milliseconden gaan voorbij voordat de UI reageert. Google's Real User Monitoring registreert de vertraging. Je conversiepercentage daalt nog eens half procent. Core Web Vitals verschoof van rangschikkingscuriositeit naar de meetbare lijn tussen sites die converteren en sites die gebruikers verliezen. In 2026 verving INP FID volledig, werden CLS-drempels aangescherpt, en de geruchten over Smoothness-metreken zijn al zichtbaar in Chrome Canary. Deze gids destilleert 200+ performance-audits die we bij Social Animal hebben uitgevoerd tot de framework-specifieke fixes, echte benchmarks en code snippets die echt resultaat opleveren—geen vaag advies over "afbeeldingen optimaliseren." We laten je zien waar INP zich in Next.js 14 App Router drie keer breekt, de twee-regel Intersection Observer-aanpassing die onze LCP met 40% reduceerde, en waarom je third-party scripts CLS nog steeds verpesten zelfs als je denkt dat ze async zijn.

Inhoudsopgave

Wat zijn Core Web Vitals in 2026?

Core Web Vitals zijn Googles gestandaardiseerde set UX-metreken die rechtstreeks de zoekrankings beïnvloeden—en eerlijk gezegd? Nog belangrijker, het gebruikersgedrag. Ze meten wat gebruikers daadwerkelijk voelen: hoe snel inhoud verschijnt, hoe snel de pagina reageert wanneer ze iets aanraken, en of de lay-out op zijn plek blijft of springt als een bezeten.

INP verving FID officieel in maart 2024. Halverwege 2025 toonde Chrome's gebruiksgegevens aan dat 38% van de oorsprongen nog steeds het INP-drempel niet haalden—vergelijk dat met het gemakkelijke 92% succespercentage dat FID had. Dit was niet Google dat de doelpalen verplaatste. Ze maten eindelijk wat echt belangrijk was.

Waar we in begin 2026 staan:

  1. Largest Contentful Paint (LCP)—laadprestaties
  2. Interaction to Next Paint (INP)—responsiviteit
  3. Cumulative Layout Shift (CLS)—visuele stabiliteit

Google geeft ook blijk van interesse in een Smoothness-metriek (denk aan animation frame drops en scroll jank), hoewel het nog niet is gepromoveerd naar Core Web Vital-status. Slimme teams volgen het al met de Long Animation Frames (LoAF) API. Als je dat niet doet—begin er nu mee.

De huidige statistieken en hun drempels

Metriek Goed Behoefte aan verbetering Slecht Wat het meet
LCP ≤ 2,5s 2,5s – 4,0s > 4,0s Tijd tot het grootste zichtbare element wordt weergegeven
INP ≤ 200ms 200ms – 500ms > 500ms Worst-case interactie-latentie over de sessie
CLS ≤ 0,1 0,1 – 0,25 > 0,25 Som van onverwachte layout shift-scores

Hier is wat mensen constant vergeten. Deze drempels worden gemeten op het 75e percentiel van paginaladingen van echte Chrome User Experience Report (CrUX) gegevens. Dit betekent dat 75% van je werkelijke bezoekers "Goed" moet halen. Niet je test op een MacBook Pro met glasvezel internet. Je werkelijke gebruikers—op hun drie jaar oude Samsungs, onderweg in een metro met wisselend LTE-signaal. Enorm verschil.

Largest Contentful Paint (LCP) Optimalisatie

LCP is meestal de metriek die teams het beste begrijpen—en toch is het degene waar de meeste sites nog steeds falen. De HTTP Archive's jaareindegegevens van 2025 toonden aan dat slechts 63% van mobiele oorsprongen LCP doorgeeft. Dat is... niet erg.

LCP sub-onderdelen begrijpen

Google deelde LCP in hun 2024-documentatie in vier sub-onderdelen. Dit framework is het meest effectieve diagnostische tool die we hebben gevonden—niets anders komt in de buurt:

Sub-onderdeel Doel Wat het dekt
Time to First Byte (TTFB) < 800ms Serverrespons, DNS, TLS, omleidingen
Resource Load Delay < 10% van LCP Tijd tussen TTFB en wanneer de LCP-resource begint te laden
Resource Load Duration < 40% van LCP Tijd om de LCP-resource te downloaden
Element Render Delay < 10% van LCP Tijd tussen resource geladen en pixel weergegeven

Server-side fixes

TTFB reduceren door naar edge computing te gaan. Nog steeds bedienen vanaf één oorsprong? Je geeft gewoon 200-800ms aan gebruikers ver weg van je server. Helemaal gratis weg. Voor niets.

// Next.js middleware voor edge-first rendering
// next.config.js
export default {
  experimental: {
    runtime: 'edge',
  },
};

// middleware.ts — draait aan de edge
import { NextResponse } from 'next/server';
export const config = { matcher: ['/((?!api|_next/static|favicon.ico).*)'] };

export function middleware(request) {
  const response = NextResponse.next();
  // Voeg Server Timing-headers toe voor debugging
  response.headers.set('Server-Timing', `edge;desc="Edge Middleware"`);
  return response;
}

Voor teams op Astro of Next.js bereiken edge-weergegeven pagina's consistent TTFB onder de 200ms wereldwijd. Onze Next.js development en Astro development praktijken gebruiken standaard edge-implementatie.

Resource Discovery Optimalisatie

Hier is wat de meeste mensen missen—de grootste LCP-killer in 2026 is niet langzame servers. Het is late discovery van de LCP-resource. Als je hero-afbeeldings-URL verborgen is in een CSS-bestand of verschuild in een JavaScript-bundel, kan de browser niet eens beginnen met fetchen totdat die hele keten is opgelost. Je verbergt in wezen het belangrijkste op je pagina achter een schattenjacht.

<!-- Voorladen van de LCP-afbeelding met fetchpriority -->
<link
  rel="preload"
  as="image"
  href="/hero-2400.webp"
  fetchpriority="high"
  media="(min-width: 768px)"
/>
<link
  rel="preload"
  as="image"
  href="/hero-800.webp"
  fetchpriority="high"
  media="(max-width: 767px)"
/>

<!-- Op het afbeeldingselement zelf -->
<img
  src="/hero-2400.webp"
  alt="Product dashboard"
  width="2400"
  height="1200"
  fetchpriority="high"
  decoding="async"
  sizes="100vw"
  srcset="/hero-800.webp 800w, /hero-1600.webp 1600w, /hero-2400.webp 2400w"
/>

Sleutelregels:

  • Lazy-load nooit het LCP-element. Dit is niet onderhandelbaar.
  • Gebruik fetchpriority="high" op de LCP-afbeelding—ondersteund in alle moderne browsers sinds 2025.
  • Plaats kritieke CSS inline of gebruik <link rel="preload"> voor lettertypen die rendering blokkeren.
  • Lever afbeeldingen in AVIF met WebP-fallback. AVIF is 30-50% kleiner dan WebP bij gelijke kwaliteit. Als je in 2026 nog steeds WebP als primaire indeling verstuurt, laat je bytes op tafel.

LCP voor op tekst gebaseerde elementen

Wanneer je LCP-element een kop of alinea is (supergemeenschappelijk op contentplatsen), worden render-blocking resources je vijand:

<!-- Voorladen van je primaire lettertype -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-v.woff2" crossorigin />

<!-- Gebruik font-display: optional voor de snelste paint -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-v.woff2') format('woff2');
    font-display: optional; /* Elimineert layout shift van lettertype swap -->
  }
</style>

font-display: optional voorkomt zowel FOIT als FOUT door terug te vallen op het systeemlettertype als het weblettertype niet in cache is. De afweging? Eerste keer bezoekers zien het systeemlettertype. De winst: nul CLS van lettertype swapping en sneller LCP. We nemen die afweging elke keer.

Interaction to Next Paint (INP) Optimalisatie

INP is de metriek die in 2026 goede sites van geweldige sites onderscheidt. De meeste agentschappen krijgen dit fout. In tegenstelling tot FID, dat alleen de input delay van de eerste interactie mat, erfasst INP de volledige levenscyclus van elke interactie: input delay, verwerkingstijd en presentatievertraging—rapporteert dan ruwweg de ergste ervan (98e percentiel).

Anatomie van een interactie

[Gebruiker klikt] → [Input Delay] → [Eventverwerking] → [Presentatievertraging] → [Volgende frame geschilderd]
                    ↑                 ↑                      ↑
                    Geblokkeerd door   Je click               Browser geeft
                    main thread       handler draait         DOM-wijzigingen

Input Delay reduceren

Input delay treedt op wanneer de main thread bezig is met ander spul wanneer de gebruiker tikt. De gebruikelijke verdachten:

  1. Third-party scripts—Analytics, chatwidgets, A/B-testtools. Je typische enterprise-site laadt 15-30 third-party scripts, en elk ervan strijdt om main thread-tijd. Het is een complete chaos daarbinnen.
  2. Hydration storms—SPAs die de hele pagina tegelijk hydrateren blokkeren de main thread voor 200-2000ms. Dat is een eeuwigheid wanneer iemand een knop wil aanraken.
  3. Long tasks—Elk JavaScript-taak over 50ms vertraagt input. Punt uit.
// Verbreek lange taken met scheduler.yield()—beschikbaar in Chrome 129+
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // Cede naar de main thread elke 5 items
    if (i % 5 === 0) {
      await scheduler.yield();
    }
  }
}

Voor browsers zonder scheduler.yield(), hier is de fallback:

function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Verwerkingstijd reduceren

Dit is waar je event handlers wonen. De fix is architecturaal, niet cosmetisch:

  • Debounce en throttle dure handlers (scroll, resize, input).
  • Verplaats berekening weg van de main thread met Web Workers of de scheduler.postTask() API.
  • Gebruik CSS voor animaties in plaats van JavaScript. transform en opacity wijzigingen triggeren geen layout of paint.
// Gebruik scheduler.postTask() voor niet-urgente werkzaamheden
button.addEventListener('click', async () => {
  // Urgent: visuele feedback onmiddellijk
  button.classList.add('active');
  
  // Niet-urgent: analytics, state updates
  scheduler.postTask(() => {
    analytics.track('button_clicked');
  }, { priority: 'background' });
  
  // Gebruiker-zichtbaar maar niet onmiddellijk
  scheduler.postTask(() => {
    updateDashboard();
  }, { priority: 'user-visible' });
});

Presentatievertraging reduceren

Presentatievertraging is de kloof tussen je event handler die klaar is en de browser die daadwerkelijk het volgende frame schildert. Wat veroorzaakt het:

  • Buitensporige DOM-grootte—Pagina's met meer dan 1.400 DOM-elementen vertonen meetbaar slechtere INP. De 2025 HTTP Archive mediaan? 1.600 elementen op mobiel. De meeste sites zijn veel te opgeblazen.
  • Complexe CSS-selectors—Diep geneste selectors forceren dure stijlherberekeningen elke keer dat iets verandert.
  • Layout thrashing—Het lezen van layout-eigenschappen zoals offsetHeight onmiddellijk na het schrijven naar de DOM dwingt synchrone lay-out af. Deze beet veel mensen. Ze zien het nooit aankomen.
// SLECHT: Layout thrashing
elements.forEach(el => {
  const height = el.offsetHeight; // Dwingt lay-out af
  el.style.height = height + 10 + 'px'; // Ongeldig maakt lay-out
});

// GOED: Batch reads, dan batch writes
const heights = elements.map(el => el.offsetHeight); // Alle reads eerst
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // Alle writes tweede
});

Cumulative Layout Shift (CLS) Optimalisatie

CLS meet visuele instabiliteit—spullen die rond springen terwijl de pagina laadt of tijdens interacties. Google gebruikt een "session window"-benadering: shifts binnen 1 seconde van elkaar, ingesteld op 5 seconden per window, worden gegroepeerd. CLS rapporteert het grootste session window.

De gebruikelijke verdachten

Oorzaak Fix Impact
Afbeeldingen zonder dimensies Voeg width en height attributen toe Hoog
Dynamisch geïnjecteerde inhoud (ads, embeds) Reserveer ruimte met min-height of aspect-ratio Hoog
Web fonts veroorzaken FOUT Gebruik font-display: optional of size-adjust Gemiddeld
Laat-laadse CSS Plaats kritieke CSS inline, preload de rest Gemiddeld
Animaties die lay-out triggeren Gebruik transform in plaats van top/left/width/height Laag-Gemiddeld

De `aspect-ratio` CSS-eigenschap

Ik overdrijf niet wanneer ik zeg dat deze ene eigenschap een hele klasse van CLS-problemen in één nacht elimineerde. Gebruik het overal:

/* Reserveer ruimte voor afbeeldingen */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
}

/* Reserveer ruimte voor videoembeds */
.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

/* Reserveer ruimte voor ad slots */
.ad-slot-leaderboard {
  aspect-ratio: 728 / 90;
  min-height: 90px;
  contain: layout;
}

De `content-visibility` eigenschap

content-visibility: auto vertelt de browser om rendering van off-screen inhoud over te slaan. Dit snijdt dramatisch de initiële layout-kosten en kan zowel CLS als INP verbeteren:

.below-the-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Geschatte hoogte om CLS te voorkomen */
}

We hebben 30-50% reductions in rendering time gemeten op lange-vorm pagina's met deze techniek. Bijna gratis prestatie. Er is geen goedeeden om het niet op content-zware pagina's te gebruiken.

Framework-specifieke strategieën

Next.js (App Router, v15+)

Next.js 15 verzond Partial Prerendering (PPR) als stabiel, en eerlijk gezegd—het is een echt game-changer voor LCP. Statische shells renderen onmiddellijk aan de edge; dynamische inhoud stroomt in via React Suspense-grenzen.

// app/page.tsx — Statische shell met dynamisch eiland
import { Suspense } from 'react';
import { HeroSection } from '@/components/HeroSection'; // Statisch
import { PersonalizedOffers } from '@/components/PersonalizedOffers'; // Dynamisch

export default function HomePage() {
  return (
    <>
      <HeroSection /> {/* Gerenderd op build time—instant LCP */}
      <Suspense fallback={<OffersSkeleton />}>
        <PersonalizedOffers /> {/* Stroomt in na shell */}
      </Suspense>
    </>
  );
}

Next.js's <Image> component verwerkt srcset, AVIF/WebP-onderhandeling, en lazy-loading automatisch. Maar—en dit trip mensen constant—je moet nog steeds priority op LCP <Image> componenten instellen. Het zal het niet voor je raden:

<Image
  src="/hero.jpg"
  alt="Hero"
  width={2400}
  height={1200}
  priority // Stelt fetchpriority="high" in en schakelt lazy loading uit
  sizes="100vw"
/>

Onze volledige benadering van performance-first Next.js builds staat op onze Next.js development capabilities pagina.

Astro

Astro's zero-JavaScript-by-default architectuur betekent dat de meeste Astro-sites Core Web Vitals direct uit de doos doorgeeft. De 2025 HTTP Archive Web Almanac toonde Astro-sites met het hoogste Core Web Vitals succespercentage van elk framework op 82%. Dat is geen toeval—het is wat gebeurt wanneer de standaard nul client-side JS is.

De sleutelpatronen:

---
// src/pages/index.astro
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---

<!-- Astro optimaliseert dit op build time naar AVIF/WebP met srcset -->
<Image
  src={heroImage}
  alt="Hero"
  widths={[400, 800, 1600, 2400]}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

<!-- Interactive eiland—laadt JS alleen wanneer zichtbaar -->
<SearchBar client:visible />

De client:visible richtlijn betekent dat de zoekbalk's JavaScript niet laadt totdat de gebruiker ernaartoe scrollt, waardoor de main thread tijdens initieel laden vrij blijft. Meer op onze Astro development benadering.

Headless CMS-overwegingen

Met een headless CMS—Contentful, Sanity, Storyblok, wat je ook draait—wordt het CMS API-antwoord onderdeel van je TTFB. Niemand denkt hieraan totdat het toeslaat.

Onze benchmarks over client-projecten:

CMS Gem. API Response (Cached CDN) Gem. API Response (Origin) Opmerkingen
Contentful 45ms 180ms GraphQL API iets langzamer dan REST
Sanity 35ms 120ms GROQ queries zijn snel; CDN is uitstekend
Storyblok 50ms 200ms V2 API verbeterde aanzienlijk
Strapi (Self-hosted) Variabel Variabel Volledig afhankelijk van je infrastructuur

Het kritieke patroon: roep CMS APIs niet op request time aan tenzij je echt personalisatie nodig hebt. Gebruik ISR of on-demand revalidatie om pre-gebouwde pagina's te serveren. We hebben teams gezien die 300ms+ aan hun TTFB toevoegden gewoon omdat iemand een fetch oproep in een server component heeft bedraad die in cache zou moeten zijn. Maddening. Onze headless CMS development praktijk bouwt dit standaard in.

Meten en monitoren in productie

Lab versus veldgegevens

Luister, lab-gegevens (Lighthouse, WebPageTest) vertellen je wat zou kunnen gebeuren. Veldgegevens (CrUX, RUM) vertellen je wat daadwerkelijk gebeurt. Ze wijken af—soms wild. En wanneer stakeholders een Lighthouse 100-score rondzwaai als een trofee terwijl hun CrUX-gegevens falen? Ja. We hebben dat gesprek veel vaker dan we willen.

Hier is wat lab-tools eenvoudig niet kunnen verklaren:

  • Trage apparaten (de middelste Android-telefoon heeft ongeveer 1/5 van de CPU-kracht van een iPhone 15)
  • Netwerkveranderlijkheid in de echte wereld
  • Browser-uitbreidingen die god weet wat doen
  • Behavior van third-party scripts in productie—spullen die zich compleet anders gedragen dan in je staging-omgeving

Aanbevolen monitoring stack (2026)

Tool Type Kosten Best voor
Google CrUX Veld (28-dag) Gratis SEO-impact—dit is wat Google daadwerkelijk gebruikt
web-vitals.js Veld (real-time) Gratis Custom RUM-pijplijn
Vercel Speed Insights Veld Gratis (met Vercel) Next.js sites op Vercel
SpeedCurve Lab + Veld $12-200/mo Competitieve benchmarking, filmstrips
Sentry Performance Veld $26+/mo Performance koppelen aan fouten
DebugBear Lab + Veld + CrUX $99+/mo Best CrUX change tracking die we hebben gebruikt

web-vitals.js instellen

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // Attribution data—vertelt je WAAROM de metriek slecht is
    attribution: metric.attribution,
  };

  // Gebruik sendBeacon voor betrouwbaarheid
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', JSON.stringify(body));
  }
}

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

De /attribution build is kritiek—het voegt diagnostische info toe zoals welk element het LCP was, welke interactie de slechtste INP veroorzaakte, en welke elementen verschoven voor CLS. Zonder het je je blind voelt. Alleen naar getallen staren zonder context voor wat je daadwerkelijk moet oplossen.

Geavanceerde technieken voor 2026

Speculation Rules API

De Speculation Rules API (Chrome 121+, ~75% browser-ondersteuning in 2026) pre-rendert pagina's voordat de gebruiker daadwerkelijk doorklikt. Het resultaat? Bijna instant LCP op volgende navigaties:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

"eagerness": "moderate" pre-rendert op hover—agressief genoeg om instant te voelen, conservatief genoeg om je gebruikers' bandbreedte niet in te branden. We landden hier na veel trial and error. Het is het zoete plekje.

View Transitions API

Natieve view transitions (cross-document, ondersteund in Chrome 126+) geven je gladde pagina-naar-pagina animaties zonder JavaScript-framework overhead. Ze verbeteren direct de gevoelde prestatie en reduceren CLS tijdens navigatie:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

Long Animation Frames (LoAF) API

LoAF vervangt Long Tasks en geeft je veel meer diagnostische kracht. Ik wens echt dat we dit drie jaar geleden hadden gehad:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.log('Lang animation frame:', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          sourceURL: s.sourceURL,
          sourceFunctionName: s.sourceFunctionName,
          duration: s.duration,
        })),
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Dit vertelt je exact welk script en welke functie het lange frame veroorzaakte. We hebben hele audit sessies doorgebracht alleen naar LoAF-uitvoer starend, de smoking gun in minuten in plaats van uren vinden. Voor INP-debugging is het het beste tool dat nu bestaat. Niets anders is dichtbij.

De zakelijke impact: echte getallen

Performance-optimalisatie is geen ijdelheid project. Het is niet iets waar je groen licht geeft omdat een developer denkt dat het cool zou zijn. Uit 2025 casestudies:

  • Vodafone verbeterde LCP met 31%, resulterend in 8% meer verkopen.
  • Tokopedia reduceerde INP met 40%, verhogingde session duur met 15%.
  • NDTV verbeterde CLS met 55%, reduceerde bounce rate met 50%.
  • Rakuten 24 verbeterde CLS met 0,2 punten, resulterend in een 33,1% toename van opbrengsten per bezoeker.

Onze eigen gegevens van clients bij Social Animal tonen sites die alle drie Core Web Vitals doorgeeft zien een gemiddeld 23% lager bounce rate en 12% hoger conversiepercentage vergeleken met hun pre-optimalisatie basislijnen.

Voor e-commerce is de wiskunde doodsimpel: een 1-seconde verbetering in LCP correleert met een 2-5% toename in conversiepercentage. Op een $10M/jaar winkel, dat is $200K-$500K in extra opbrengsten. De kosten van optimalisatie? Een fractie daarvan. Check onze pricing pagina voor specifieke details, of neem rechtstreeks contact op om je situatie door te spreken.

Veelgestelde vragen

Wat zijn de Core Web Vitals-metreken in 2026? De drie Core Web Vitals zijn Largest Contentful Paint (LCP), Interaction to Next Paint (INP), en Cumulative Layout Shift (CLS). INP verving First Input Delay (FID) terug in maart 2024 en het is nog steeds de responsiviteitsmetriek. Google heeft gewipt naar een Smoothness-metriek maar heeft het nog niet als Core Web Vital toegevoegd.

Hoeveel beïnvloeden Core Web Vitals SEO-rankings? Ze zijn een bevestigd rankingssignaal binnen Google's page experience-signalen, maar ze werken meer als een tiebreaker dan een primaire factor—content-relevantie domineert nog steeds. Waar ze echt hun gewicht voelen is gebruikersgedrag: bounce rate, engagement, tijd op site. Dat spul beïnvloedt rankings indirect op manieren die moeilijk direct toe te schrijven zijn maar onmogelijk te negeren. Sites die alle Core Web Vitals doorgeeft tonen consistent betere engagement-getallen, en dat compenseert in de loop van de tijd.

Wat is een goed INP-score in 2026? 200 milliseconden of minder, gemeten op het 75e percentiel van echte gebruiksgegevens. Tussen 200ms en 500ms behoefte aan verbetering. Over 500ms is slecht. De mediane website INP op mobiel zit op ongeveer 280ms vanaf begin 2026—wat betekent dat de meeste sites nog steeds niet doorgeeft. Laat dat tot je doordringen.

Waarom is mijn Lighthouse-score anders dan mijn CrUX-gegevens? Omdat ze fundamenteel verschillende dingen meten. Lighthouse draait in een gesimuleerde omgeving met vertraagde CPU en netwerk op een enkel paginalading. CrUX-gegevens komen van echte Chrome-gebruikers over een 28-daagse rollen window over alle pagina's op je oorsprong. De kloof komt van apparaat-diversiteit (echte gebruikers op langzame Android telefoons), behavior van third-party scripts in productie, geografische afstand van je servers, en het feit dat CrUX de volledige sessie vastlegt—elke interactie voor INP, elke layout shift voor CLS—terwijl Lighthouse één laden vastlegt. We hebben sites gezien die 95+ in Lighthouse scoren en CrUX-breed falen. Vertrouw niet alleen op lab-gegevens.

Helpt het gebruik van een headless CMS bij Core Web Vitals of schaadt het er aan? Een headless CMS-architectuur helpt fundamenteel omdat het de presentatielaag van inhoudsbeheer ontkoppelt. Je kunt het koppelen met moderne frameworks zoals Next.js of Astro met edge-rendering, serveren statische of server-weergegeven HTML met minimale JavaScript. Traditionele monolithische platforms—WordPress zonder zware optimalisatie, Drupal out of the box—verzenden doorgaans veel meer JavaScript en hebben langzamere TTFB. Het sleutel ding: zorg dat CMS API-aanroepen op build time gebeuren of agressief in cache worden opgeslagen, niet op elke enkele request afgevuurd.

Hoe fix ik een slecht INP-score veroorzaakt door third-party scripts? Begin met auditen met de Long Animation Frames API of Chrome DevTools' Performance panel om te identificeren welke scripts de main thread jatten. Dan: laad non-kritieke scripts met async of defer, gebruik setTimeout of requestIdleCallback om hun initialisering te vertragen, overweeg third-party scripts weg van de main thread te verplaatsen via een web worker (Partytown is geweldig ervoor), en—dit is het deel dat niemand wil horen—gnadenloos verwijder alles dat geen meetbare bedrijfswaarde levert. Die chatwidget die niemand gebruikt? Kill het. We hebben sites gezien die van 500ms+ INP naar onder de 150ms vallen gewoon door chat widgets en A/B test tools uit te stellen. Het is bijna altijd third-party bloat.

Wat is de snelste manier om LCP op een Next.js site te verbeteren? In volgorde van impact: schakel Partial Prerendering (PPR) in voor instant statische shells, deploy naar edge runtime (Vercel Edge of Cloudflare), stel priority op je LCP <Image> component in, stop render-blocking met onnodige client componenten boven de vouw, en preload kritieke lettertypen. Maar hier is wat we in de praktijk daadwerkelijk het meest zien: de hoofdoorzaak is client-side data fetching dat een server component zou moeten zijn. Het verplaatsen van een enkel component van 'use client' naar een server component kan 500ms of meer van LCP afsnijden. Het is waanzinnig hoe vaak dat de hele fix blijkt te zijn.

Hoe vaak werkt Google Core Web Vitals drempels bij? Zelden. De grote verandering was het ruilen van FID voor INP, aangekondigd in mei 2023 en ingevoerd in maart 2024. De werkelijke drempel-waarden—2,5s voor LCP, 200ms voor INP, 0,1 voor CLS—zijn niet verplaatst sinds ze werden geïntroduceerd. Google geeft doorgaans 6-12 maanden' waarschuwing voordat iets verandert. Maar het Chrome team fijnt continu aan hoe metrics onder de motorkap worden berekend, dus je moet je veldgegevens in de gaten houden zelfs wanneer de drempels stand houden. Spullen verschuiven zonder dat iemand het aankondigt.