Hoe voer je in 2026 een Core Web Vitals-audit uit (en wat er veranderd is sinds INP FID heeft vervangen)

TL;DR: De Core Web Vitals in 2026 zijn LCP, INP en CLS. FID is met pensioen en INP nam op 12 maart 2024 zijn plek in. Het ranking-gewicht is kleiner dan veel SEO’s beweren (Google zegt zelf dat relevantie belangrijker is dan page experience), maar de UX-impact is echt en de audit blijft renderen. Dit is de auditgids die ik aan klanten geef: drie metrische drempels, tooling in twee rondes (lab + field), een fix-lijst gerangschikt op rendement en een kwartaalritme dat de engineers niet op het verkeerde werk opbrandt.

Ik voer elk kwartaal site-audits uit voor een portfolio van mid-market sites bij mindnow en seojuice.io. Elke keer vraagt iemand of er weer een sprint op Core Web Vitals nodig is. Het eerlijke antwoord is meestal nee. Het protocol wijzigde in 2024, het ranking-gewicht is klein en veel wat je over CWV leest overschat de zoekverkeers-uplift. De audit blijft relevant, omdat trage pagina’s nog steeds conversie lekken en INP echt een andere metric is dan FID. Dit artikel is het audit-playbook. Het is geen technisch “hoe-optimaliseer-ik-INP”-stuk; het web.dev-team schrijft die beter dan ik. Dit is de interpretatielaag erbovenop.

Wat is er veranderd in Core Web Vitals tussen 2024 en 2026

De hoofdaanpassing: First Input Delay (FID) werd gedeactiveerd en Interaction to Next Paint (INP) werd op 12 maart 2024 een officiële Core Web Vital. Het Chrome-team kondigde het direct aan:

"INP will officially become a Core Web Vital and replace FID on March 12 of this year." Jeremy Wagner and Rick Viscomi, web.dev blog, March 2024

Als je audittemplate nog FID ophaalt, meet je een gedepricatieerde metric. Search Console verwijderde FID diezelfde dag. PageSpeed Insights toont nu INP. De Web Vitals-JavaScriptbibliotheek v4 zette FID buitenspel. Labtools die FID nog rapporteren zijn nuttig voor triage, niet voor ranking-beslissingen.

Waarom de wissel. FID mat alleen de eerste interactie op een pagina, en dan enkel de input-delay daarvan. Een site kon één snelle eerste klik hebben en daarna bij elke tik bevriezen. De metric was ook manipuleerbaar: niets uitstellen op de landing en alles laden bij de tweede interactie. INP dicht beide gaten door alle interacties te bemonsteren en de volledige vertraging tot aan de volgende paint te tellen:

"INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers, and finally up until the browser has painted the next frame." Jeremy Wagner and Barry Pollard, web.dev, Interaction to Next Paint

Het praktische effect op audits: de meeste sites die groen stonden op FID zijn geel of rood op INP. De verschuiving is mechanisch, geen teken dat je site slechter werd. Plan voor de nieuwe baseline voordat je stakeholders vertelt dat de score is teruggelopen.

Twee kleinere veranderingen vielen ook binnen 2024-2026. CrUX, de field-datasource achter het CWV-rapport in Search Console, vergrootte zijn bemonsteringsdiepte, zodat de 75e-percentiel-drempels op meer sessies zijn gebaseerd. LCP kreeg een sub-diagnostiek (TTFB, resource load delay, element render delay) in PageSpeed Insights, de nuttigste diagnostic toevoeging in jaren.

De drie huidige metrics en hun auditdrempels

Drie metrics, één drempeltabel, toegepast op het 75e percentiel van echte gebruikers voor mobiel en desktop afzonderlijk. De canonical-pagina op web.dev is expliciet over de rol:

"Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools." Philip Walton, web.dev, Web Vitals

De 75e-percentiel-cut is wat de meeste operators missen. Niet elke paginasessie hoeft onder de drempel te zitten; drie kwart wel. Het traagste staartje van devices, netwerken en pagina’s mag in het gele gebied zitten en de URL krijgt toch een Good-rating in CrUX.

Audit-stap per metric. LCP: haal de LCP-subdelen uit PageSpeed Insights. Is TTFB boven 800 ms, dan ligt de fix bij server of CDN, niet bij de front-end. Als element render delay domineert, preload de afbeelding of gebruik critical CSS. INP: open de pagina op een mid-range Android-toestel, klik op alle elementen en bekijk in het Performance-paneel long tasks boven 50 ms. De traagste interactie telt. CLS: scroll de pagina op een trage verbinding. Zie je layout-shifts tijdens font-swap of beeld-load boven de vouw, reserveer dan ruimte (aspect-ratio CSS) of gebruik font-display: swap met een metrische fallback.

Eén audit-antipatroon om te laten vallen: optimaliseer niet de Lighthouse-Performance-score als proxy voor CWV. Die score is een gewogen labcomposiet met onder meer Speed Index en Total Blocking Time, geen van beide Core Web Vitals. Een site kan 95 scoren in Lighthouse en toch CWV falen op field-data, omdat Lighthouse één deviceprofiel simuleert terwijl CWV elke echte bezoeker meet.

Hoe Google CWV écht gebruikt in ranking

Lees Google’s eigen page-experience-documentatie. De samenvattende zin is hard:

"Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Google Search Central, Page Experience documentation

Die zin staat verstopt in de FAQ onder “How important is page experience to ranking success?” en is het belangrijkste dat Google publiekelijk over CWV-gewicht heeft geschreven. Relevantie en autoriteit domineren. Page experience is één van vele signalen die de ranking bijstuurt als relevantie min of meer gelijk is.

Datzelfde document nuanceert meteen: Google bevestigt dat “Core Web Vitals are used by our ranking systems,” maar voegt toe: “There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.” (Beide citaten uit dezelfde page-experience-documentatie.)

Alle drie zinnen samen: CWV zit in het systeem maar weegt licht. Er is geen enkele page-experience-score die je ranking omgooit; het is een cluster dat Google helpt bij gelijkspel. Eerlijk naar stakeholders: CWV verbeteren op een pagina met zwakke content en zwakke backlinks redt haar niet. CWV verbeteren op een pagina met sterke content en backlinks die nu op positie 4 of 5 staat, kan binnen enkele maanden bijdragen aan positie 2 of 3. De rekensom loopt eerst via relevantie.

Voor het bredere ranking-plaatje behandelt ons stuk over ranking-signal confidence en audit de rest van het systeem. CWV is één paneel op een groter dashboard. Behandel het zo.

Waar AI-zoekmachines écht naar kijken

Helemaal ander protocol. Google AI Mode, ChatGPT Browse, Perplexity en Claude’s webtool zijn retrieval-en-samenvattingssystemen. Ze halen je pagina op, parseren relevante content en citeren of parafraseren die. Pagespeed in CWV-zin zit niet in hun selectiecriteria; hun retrieval is server-side en het fetch-budget is ruim vergeleken met een echte gebruiker.

Wat telt: server-responsiviteit (een TTFB van 30 seconden time-out de crawler), HTTPS, content die zonder JavaScript rendert (of die de fetcher kan uitvoeren), gestructureerde data en semantische HTML. Dat overlapt met CWV op het TTFB-punt, maar verder is het een andere audit. INP optimaliseren voor ChatGPT Browse is verspilde moeite; de agent interacteert niet met je pagina.

Praktisch voor de 2026-audit: houd één TTFB-doel (onder 800 ms) dat alle audits bedient. Ontkoppel INP- en CLS-werk van AI-search-werk; ze hebben andere prioriteiten. Verschuift je trafficmix naar AI-verwijzingen, besteed de engineeringuren dan aan renderbaarheid en structured data, niet aan 50 ms van een interactie afschaven.

Tools om Core Web Vitals te meten in 2026

Het toollandschap is sinds 2022 geconsolideerd. Zes tools dekken de lab-plus-field-workflow die de meeste operators nodig hebben.

Twee-pass-workflow. Start met PageSpeed Insights voor één URL om lab en field naast elkaar te zien. Het labcijfer toont wat technisch haalbaar is op een schoon deviceprofiel; het fieldcijfer laat zien wat echte gebruikers ervaren. Bij afwijking telt field voor ranking, en het gat is de diagnose. Lab groen + field rood betekent dat je gebruikers trager hardware of netwerken hebben dan je dev-machines.

Voor herhaalbare klant-rapporten en trendtracking draait de SEOJuice Lighthouse Score Checker een echte paginasc an en geeft een deelbare URL plus historische trenddata; intern gebruiken wij dit om klantprogressie te volgen zonder elke auditcyclus handmatig Lighthouse te herstarten. De bredere interpretatie van de Lighthouse-score (wat is een voldoende, hoe stapelen de categorieën) staat in onze Lighthouse SEO-score-breakdown.

Wil je zien hoe CWV-metrics daadwerkelijk correleren met zoekverkeer over een populatie van pagina’s, dan toont onze CWV Impact-calculator de geaggregeerde correlaties van meer dan 164.000 geaudite pagina’s. De headline-bevinding matcht Google’s eigen framing: de correlaties zijn echt maar matig, en ze variëren per metric. CLS toont de zwakste correlatie; LCP en INP zijn sterker maar nog altijd lager dan veel CWV-marketingclaimt.

Veelvoorkomende fixes gerangschikt op rendement

Engineeringuren zijn eindig. Rangschik fixes op impact op je slechtste metric, niet op wat het makkelijkst te shippen is. Hieronder de prioriteitenlijst die ik gebruik na zeven jaar CWV-audits.

Tier 1, server-responstijd. Staat TTFB boven 800 ms, dan wordt elke front-end-fix gemeten tegen een vertraagde startlijn. Zet een CDN voor je origin. Cache waar mogelijk de HTML-respons. Haal database-queries van het critical render-pad. Een TTFB-verbetering van 400 ms schuift LCP vaak 600 ms naar voren omdat downstream-resourceloads meebewegen.

Tier 1, imagestrategie. Het LCP-element is meestal een afbeelding. Preload met high-priority hint. Serve responsieve formaten via srcset. Gebruik AVIF of WebP met JPEG-fallback. Lazy-load alle andere beelden met het native loading="lazy"-attribuut. Lazy-load nooit het LCP-beeld zelf; dat is de meest voorkomende own-goal in CWV-audits.

Tier 2, JavaScript-hygiëne. Defer niet-kritische scripts. Split je bundles. Audit third-party tags; de meeste sites hebben 4-6 tag-manager-scripts die hun main-thread-tijd al jaren niet verdienen. INP-regressies herleiden bijna altijd naar een script dat een long task plant tijdens interactie. Code-split zware interactieve componenten, vooral search, filter of carrousel.

Tier 2, fontladen. Gebruik font-display: swap met een metrisch-gelijk systeemfont, zodat de swap geen layout-shift veroorzaakt. Preload het primaire fontbestand. Laad je drie webfonts? Schrap er twee.

Tier 3, cleanup-pass-items. Zet expliciete width en height op elke afbeelding en embed. Reserveer ruimte voor advertenties met min-height. Verplaats CLS-gevoelige componenten (notificaties, banners, cookie-banners) onder de vouw of render ze met translate-transforms die de layout niet beïnvloeden.

Wat je niet moet doen. Jaag geen Lighthouse-Performance-score van 100 na. Blokkeer geen release op een CLS-regressie van 0,01. Laat een CWV-stakeholder niet om een derde audit vragen voordat ronde twee fixes live is. De metric is noisy en het rapport heeft vertraging.

Wat AI Overviews fout doen over CWV

Drie patronen keren terug in AI-Overview-antwoorden op zoekopdrachten als “core web vitals 2026”.

De eerste is het FID-spook. AI Overviews noemen FID vaak nog steeds een Core Web Vital. Trainingsdata dateert van vóór maart 2024 en de deprecatie krijgt weinig gewicht. Fact-check altijd met web.dev of Google Search Central, niet met de AI-samenvatting.

De tweede is ranking-inflatie. Veel AI-samenvattingen reduceren Google’s genuanceerde taal tot “Core Web Vitals zijn een key ranking-factor.” Die frase komt uit marketingposts die het model heeft onthouden; de echte Google-docs zeggen dat relevantie boven page experience gaat. Compressie vlakt nuance af.

De derde is de AI-search-zelflus. AI Overviews adviseren CWV-optimalisatie voor AI-zoekmachines. Zoals hierboven: AI-zoekmachines meten je INP niet. Pagespeed in CWV-zin is irrelev ant voor retrieval. De trainingsset conflueert “snelle site = goede SEO” zonder het zoekoppervlak te onderscheiden.

Netto voor operators: behandel AI-Overviews over CWV als vertrekpunt, niet als bron van waarheid. Verifieer met first-party Google-documentatie en web.dev voordat je handelt.

Het kwartaalritme voor audits

Vier checkpoints per jaar van negentig minuten. Dat is het ritme dat de meeste mid-market sites nodig hebben. Vaker is overhead; minder en regressies landen onopgemerkt.

Haal het Search Console-rapport Core Web Vitals op. Noteer URL-groepen die sinds vorig kwartaal van status wisselden. Run voor elke groep PageSpeed Insights op een representatieve URL en pak de sub-diagnostiek.

Voer een labscan uit op je tien belangrijkste landingspagina’s. Vergelijk met vorig kwartaal. Als een pagina meer dan 200 ms op LCP of 50 ms op INP terugviel, vlag voor engineering-review.

Sample field-data uit je eigen RUM (Web Vitals-library v4). CrUX-data loopt 28 dagen achter; je eigen data is real-time. Vergelijk de vorm van de distributie, niet alleen gemiddelden.

Triëer de fix-lijst tegen de prioriteitsniveaus hierboven. Ship elk kwartaal één tier-1-item, ook als het ongemakkelijk is. Tier-3-cleanup gaat mee met normale releases. Voor sites die al een kwartaal-SEO-audit draaien, automatiseert ons site-auditproduct de labscan zodat de manuele tijd naar interpretatie gaat.

Wat deze audit NIET oplost

Core Web Vitals zijn een UX- en licht ranking-signaal. Ze zijn geen content-kwaliteits-, backlink- of brand-trust-signaal. Staat je pagina op pagina 2 voor een competitieve query, dan brengt een CLS-fix je niet naar pagina 1. Relevantie en autoriteit moeten eerst.

CWV lost conversie ook niet op zoals sommigen denken. 200 ms snellere LCP correleert met betere conversie, maar de elasticiteit verschilt per site. Ecommerce-checkout reageert sterk; longform-content zwak. Meet je eigen lift voordat je de engineering-case bouwt.

En CWV lost de AI-search-audit niet op. Ander protocol, andere fetcher, andere prioriteiten. Verschuift je verkeer naar AI-verwijzingen, dan is de page-experience-audit het verkeerde instrument.

FAQ

Is FID nog een Core Web Vital? Nee. FID werd op 12 maart 2024 gedeactiveerd en uit het programma gehaald. Interaction to Next Paint (INP) nam de plek in. Search Console verwijderde FID diezelfde dag. Update je audittemplate als die FID nog meet.

Wat is de INP-drempel? 200 ms of minder is Goed. 200-500 ms is Verbetering nodig. Boven 500 ms is Slecht. De drempel geldt op het 75e percentiel van echte gebruikersinteracties, mobiel en desktop apart.

Hoeveel invloed hebben Core Web Vitals op Google-ranking? Minder dan veel SEO-content claimt. Google’s page-experience-docs zeggen expliciet dat Search “altijd het meest relevante content wil tonen, zelfs als de page experience subpar is.” CWV is één van vele signalen en relevantie en autoriteit leiden. Zie het als tiebreaker, niet als primaire hefboom.

Gebruiken AI-zoekmachines zoals ChatGPT of Google AI Mode Core Web Vitals? Nee, niet op die manier. Hun fetchers halen pagina’s server-side op en parseren content voor samenvatting. Pagespeed in CWV-zin is irrelevant. Serverbeschikbaarheid (TTFB), renderbaarheid zonder JS en structured data zijn prioriteit; INP en CLS niet.

Wat is de meest voorkomende Core Web Vitals-auditfout? De Lighthouse-Performance-score optimaliseren als proxy voor CWV. Die score is een labcomposiet met metrics buiten CWV (Speed Index, Total Blocking Time). Een pagina kan 95 scoren in Lighthouse en toch CWV falen op field-data omdat Lighthouse één device simuleert en CWV elke echte bezoeker meet.

Hoe vaak moet ik Core Web Vitals auditen? Kwartaal is genoeg voor de meeste mid-market sites. Vaker is overhead; CrUX loopt 28 dagen achter en je fix-cyclus is zelden sneller. Gebruik continue RUM-monitoring (Web Vitals v4) voor realtime alerts tussen audits.