Core Web Vitals verbeteren: van meting naar oplossing

Zo gebruik je deze gids

Wil je weten of je een probleem hebt? Begin bij de drie meetwaarden en de meettools. Heb je al een rapport, ga dan naar LCP, INP of CLS. Onderaan staat een werkelijke labmeting van Pico Yellow, inclusief wat die niet bewijst.

Waarom Core Web Vitals aandacht verdienen

Een bezoeker wil kunnen lezen, een menu openen en een formulier gebruiken zonder op de interface te wachten. Dat maakt prestaties een productvraag, niet alleen een SEO-taak. Een snellere download helpt weinig als een essentiële knop daarna niet meer werkt.

Google gebruikt Core Web Vitals in zijn rankingsystemen, maar goede scores garanderen geen toppositie. Relevantie en de overige gebruikerservaring blijven belangrijk. Er bestaat geen vaste omrekening van milliseconden naar meer omzet of hogere posities. Beoordeel zakelijke effecten apart, met de meetperiode en andere wijzigingen erbij. Zie Googles uitleg over pagina-ervaring en de relatie tussen Core Web Vitals en Zoeken.

LCP, INP en CLS: wat meet je precies?

De aanbevolen grenzen worden beoordeeld op het 75e percentiel van bezoeken, uitgesplitst naar mobiel en desktop. Dat betekent niet dat iedere bezoeker dezelfde ervaring heeft. Voor ons volledige acceptatieblad moeten alle drie de veldmetingen beschikbaar zijn; een ontbrekende waarde krijgt het label onbekend. De basis staat in de Web Vitals-documentatie.

De drie meetwaarden en hun goede grens

Meetwaarde	Goede grens	Vraag voor onderzoek
LCP	≤ 2,5 seconden	Wanneer verschijnt de grootste relevante zichtbare inhoud?
INP	≤ 200 milliseconden	Hoe snel volgt visuele feedback na bediening?
CLS	≤ 0,1, zonder tijdseenheid	Hoeveel onverwachte verschuiving ervaart de bezoeker?

LCP is niet de tijd tot álles geladen is. De kandidaat kan tijdens het laden veranderen van een tekstblok naar een grotere afbeelding. Niet elk element telt mee; een complete SVG wordt bijvoorbeeld niet zonder meer als LCP-afbeelding behandeld. Gebruik de werkelijk aangewezen kandidaat in je opname, niet de aanname dat het altijd de hero is. Zie de definitie van LCP.

INP kijkt naar klikken, tikken en toetsenbordinteracties tijdens een bezoek. Meestal bepaalt de langzaamste interactie de bezoekwaarde; bij veel interacties worden uitschieters beperkt. Pas daarna wordt over bezoeken het 75e percentiel bepaald. INP is dus niet het 75e percentiel van alle klikken binnen één bezoek. Scrollen op zichzelf telt niet mee. De meting stopt bij de volgende visuele feedback, niet noodzakelijk bij de uiteindelijke serverrespons. Zie de definitie van INP.

CLS gebruikt de grootste groep onverwachte verschuivingen binnen een sessievenster, niet simpelweg de som over een onbeperkt bezoek. Verschuivingen kort na bepaalde gebruikersinvoer kunnen buiten de berekening vallen. Een nul tijdens een korte laadsessie bewijst daarom niet dat later nooit iets verspringt. Zie de berekening van CLS.

LCP verbeteren: onderzoek waar de tijd zit

Verdeel de laadroute in antwoord van de server, wachten op het relevante bestand, downloaden en wachten op weergave. Bij een afbeelding kan extra compressie weinig opleveren als de browser vooral wacht voordat hij deze mag tonen. De LCP-optimalisatiehandleiding beschrijft deze vier onderdelen.

• Serverantwoord: onderzoek redirects, cachegedrag, backendwerk en de verbinding. Cache geen persoonlijke antwoorden alsof ze openbare pagina's zijn.
• Ontdekking: maak de belangrijke afbeelding vindbaar in de eerste HTML. Laad een LCP-afbeelding niet uitgesteld. Gebruik hoge laadprioriteit gericht, niet voor alle afbeeldingen.
• Overdracht: kies een passende uitsnede, kwaliteit en responsieve afmetingen. Vergelijk het echte resultaat van AVIF of WebP; een vast besparingspercentage geldt niet voor elk bestand.
• Weergave: zoek naar blokkerende stijlen, lettertypen, lange browsertaken of code die inhoud verborgen houdt.

Onderstaand fictief HTML-voorbeeld reserveert beeldruimte en laat de browser een passende variant kiezen. Bestanden, alternatieve tekst en sizes moeten aansluiten op de eigen afbeelding en layout; kopieer het niet ongewijzigd als universele reparatie.

<img
  src="/beelden/product-960.webp"
  srcset="/beelden/product-480.webp 480w,
          /beelden/product-960.webp 960w"
  sizes="(max-width: 600px) 100vw, 600px"
  width="960" height="640"
  alt="Detail van de sluiting van een rugzak"
  loading="eager" fetchpriority="high">

Meer over de keuze tussen beeldkwaliteit, afmetingen en formaat lees je in onze gids voor afbeeldingsoptimalisatie. Controleer na een wijziging opnieuw welk element LCP is geworden.

INP verbeteren: test een echte handeling

Reproduceer bijvoorbeeld het openen van een menu, filteren van een productlijst of versturen van een formulier. Bekijk vervolgens de invoervertraging, uitvoering van de gebeurteniscode en tijd tot de volgende weergave. Alleen de eerste paginalading bekijken is onvoldoende. Laat directe feedback niet wachten op niet-essentiële verwerking. Dit volgt de aanpak in Googles INP-optimalisatiegids.

Verminder onnodig werk en splits lange taken waar dat functioneel veilig kan. Een functie opdelen in kleinere functies maakt er nog geen afzonderlijke browsertaken van. Een API zoals scheduler.yield kan uitvoering over taken verdelen, maar ondersteuning en een fallback moeten gecontroleerd worden. Zie de uitleg over lange taken.

requestIdleCallback is geen synoniem of automatisch vervangen voorganger van scheduler.yield: het plant laaggeprioriteerd werk in rustige momenten. Verplicht werk kan zonder timeout lang blijven wachten. Gebruik zo'n mechanisme niet blind voor de kritieke afhandeling van een bestelling. Zie de API-documentatie.

Leg voor een ontwikkelaar vast: welke handeling, welk apparaat, welke pagina, welke opname en welk resultaat verwacht wordt. “JavaScript verkleinen” is te breed als ticket. “Voorkom dat het mobiel filtermenu wacht op een niet-benodigde berekening” geeft een toetsbare taak, mits de opname die oorzaak ondersteunt.

CLS beperken: reserveer ruimte en test na het laden

Controleer afbeeldingen, embeds, advertenties en laat verschijnende onderdelen. Reserveer de juiste beeldverhouding of afmetingen voordat ze laden. Test ook doorklikken, scrollen en inhoud die later wordt opgehaald. Het element dat verspringt is niet altijd de veroorzaker: een nieuw blok erboven kan de verschuiving veroorzaken. Zie CLS onderzoeken en optimaliseren.

Lettertypen vragen een afweging. font-display: optional kan betekenen dat een laat beschikbaar merklettertype niet gebruikt wordt; swap toont snel tekst maar kan bij andere letterafmetingen verschuiven. Stem fallback-afmetingen af, beperk benodigde varianten en preload alleen wat echt kritisch is. Zelf hosten is niet automatisch sneller. Geen van deze keuzes voorkomt alle mogelijke layoutverschuivingen. Zie best practices voor lettertypen.

Van signaal naar controleerbare opdracht

Onderstaande matrix is een eigen diagnosevoorbeeld, geen lijst van al gemeten problemen bij klanten. De tweede kolom bepaalt welk bewijs ontbreekt voordat een wijziging gekozen wordt.

Voorbeeldwerkblad: signaal, controle en besluit

Signaal	Eerst controleren	Mogelijke opdracht
Hoofdinhoud verschijnt laat	LCP-element en verdeling van de laadtijd	Pak de aangetoonde wachttijd aan; niet standaard meer compressie
Menu reageert traag	Opname van openen tijdens en na laden	Verplaats of verminder werk dat de reactie blokkeert
Tekst springt na scrollen	Welk nieuw onderdeel schuift bestaande inhoud weg?	Reserveer ruimte en herhaal dezelfde gebruikersroute
Lab groen, bezoekersdata onvoldoende	URL of origin, apparaat, periode en gebruikte handelingen	Onderzoek het verschil; verklaar velddata niet ongeldig

Noteer daarnaast een eigenaar, de terugdraaimethode en functionele acceptatie. Een optimalisatie is niet geslaagd als het formulier stopt met verzenden, toetsenbordbediening verdwijnt of de cookiekeuze wordt genegeerd.

Scripts van derden: functie en gevolgen meenemen

Inventariseer welke chat-, advertentie-, analyse- en videofuncties werkelijk gebruikt worden. Test in een afgeschermde omgeving of het weglaten van een onderdeel een probleem verandert. Verwijder productiemeting of noodzakelijke functionaliteit niet uitsluitend om een score te verhogen.

Voor niet-kritieke embeds kan een licht startbeeld met een afspeelknop nuttig zijn: de volledige speler laadt pas na interactie. Dat vraagt ook duidelijke bediening, passende toestemming en een bruikbare foutafhandeling. Het facade-patroon voor embeds blijft een techniek; de gelijknamige afzonderlijke Lighthouse-audit is sinds versie 13 verwijderd. Een klik op een placeholder is geen automatische privacygoedkeuring.

Waarom mobiel en desktop verschillen

Een smaller scherm kan een andere LCP-kandidaat hebben. Ook netwerk, rekenkracht, content en bediening verschillen. Noteer daarom per test de toolversie, viewport, vertraginginstellingen, URL en datum. “Mobiel” zonder testcondities is geen reproduceerbare benchmark.

Lighthouse gebruikt verschillende scorecurves voor mobiel en desktop. De totaalscore is gewogen en kan tussen runs veranderen. Een score boven 90 is groen, maar zegt niet dat alle afzonderlijke bezoekersmetingen goed zijn. Vergelijk geen tests uit verschillende configuraties alsof uitsluitend de website is veranderd. Zie de Lighthouse-scoreberekening.

Meettools: lab, veld en ontbrekende gegevens

PageSpeed Insights combineert Lighthouse met CrUX-bezoekersgegevens, als die beschikbaar zijn. Controleer of de veldgegevens bij de specifieke URL of de hele origin horen. De laatste 28 dagen worden dagelijks bijgewerkt: een verandering kan geleidelijk zichtbaar worden, niet pas verplicht na vier weken. Een ontbrekende INP heeft binnen PSI een specifieke beoordelingsuitzondering; dat maakt de ontbrekende INP-waarde zelf niet gemeten of goed. Zie de PSI-documentatie.

CrUX is geen volledige telling van alle bezoekers. Er gelden voorwaarden voor openbaar bereik, voldoende gebruik en deelnemende Chrome-gebruikers. Safari-gebruik wordt niet ineens zichtbaar in deze dataset. Ontbrekende gegevens zijn geen bewijs van een snelle of slechte pagina. De criteria staan in de CrUX-methodologie.

Gebruik Search Console voor groepen pagina's en ontwikkeling door de tijd. Gebruik een browseropname voor de oorzaak van een concrete handeling. Eigen bezoekersmeting kan meer context geven, maar vraagt een passend gegevens- en privacyontwerp. Zie ook onze Search Console-handleiding. TBT uit een gewone Lighthouse-laadtest is geen gemeten INP.

WordPress en andere platformen

Het platform bepaalt wie een wijziging kan uitvoeren en hoe je test. Controleer bij WordPress de combinatie van thema, plugins, hosting en cache. Bij een gesloten platform ben je deels afhankelijk van beschikbare instellingen. In een Next.js-project beoordeel je onder meer server-HTML, benodigde clientcode en beeldlevering. Geen van deze platformkeuzes levert vanzelf goede Core Web Vitals op.

Deze website gebruikt Next.js met statische generatie en hervalidatie; de eerdere beschrijving als Vite-SPA is niet meer actueel. Voor specifieke uitvoering kun je technische SEO inzetten. Spreek af wie ontwikkelt, wie toestemming voor de release geeft en wie na publicatie de belangrijkste gebruikersroutes controleert.

Eigen meetvoorbeeld: ook een minder goede uitkomst tonen

Op 12 september 2026 om 12:46 Nederlandse tijd is één mobiele Lighthouse-test uitgevoerd op onze openbare GA4-gids. Lighthouse 13.4.1 gebruikte gesimuleerde netwerkvertraging, viermaal CPU-vertraging en een viewport van 412 × 823. De productiecommit is vóór en na de meting gecontroleerd. Dit is een momentopname, geen klantcase of voor-na-experiment.

Werkelijke labmeting op 12 september 2026, één run

Onderdeel	Uitkomst	Beperking
Lighthouse performance	75/100	Geen representatieve score voor de hele website
LCP	6,216 seconden	In deze labtest te traag; oorzaak en herhaalbaarheid onderzoeken
CLS	0	Alleen deze navigatie, geen bewijs voor latere interacties
TBT	50 milliseconden	Geen INP-bezoekersmeting
Toegankelijkheid en SEO	Beide 100/100	Alleen de automatische controles van deze tool

De juiste conclusie is niet “alles is snel”, ook al zijn twee categorieën 100. Deze run geeft juist aanleiding om de LCP-opbouw verder te onderzoeken. Er is geen gemeten stijging in aanvragen of rankings aan toegeschreven. De meetinstellingen, precieze waarden, productieversie en beperkingen staan in de openbare meetexport. Core Web Vitals-velddata is in dit voorbeeld niet vastgesteld.

Van nulmeting naar hertest

1. Kies de scope. Selecteer belangrijke templates en handelingen, bijvoorbeeld artikel lezen, productfilter gebruiken en een aanvraag versturen.
2. Leg de uitgangssituatie vast. Bewaar URL, datum, configuratie, beschikbare veldgegevens en meerdere vergelijkbare labruns. Noteer ook ontbrekende informatie.
3. Maak een klein ticket. Beschrijf waarneming, vermoedelijke oorzaak, bewijs, eigenaar, verwachte controle en terugdraaimogelijkheid.
4. Test zonder functies te verliezen. Controleer op preview dezelfde route met muis, aanraking en toetsenbord. Neem formulieren en toestemmingskeuzes mee.
5. Controleer de juiste release. Hertest na publicatie en volg veldgegevens door de tijd. Rapporteer gemeten verandering en resterende onzekerheid afzonderlijk.

Hulp nodig bij het kiezen van de eerste technische opdracht? Plan een adviesgesprek. Een openbare SEO-scan is geen volledige performanceprofilering, toegangscontrole of implementatieproject. De scope en offerte worden op de website en beschikbare gegevens afgestemd.

Veelgestelde vragen

Zijn Core Web Vitals hetzelfde als een PageSpeed-score?

Nee. Core Web Vitals zijn afzonderlijke bezoekersgerichte meetwaarden. De Lighthouse-performancecategorie is een gewogen labscore. Ook met een groene totaalscore kan een afzonderlijk probleem of ontbrekende veldmeting blijven bestaan.

Waarom staat er geen INP in mijn gewone Lighthouse-test?

Een standaard navigatietest voert geen representatief bezoekersgedrag uit. TBT helpt blokkering tijdens laden onderzoeken, maar is geen vervanging voor INP. Test relevante handelingen en gebruik beschikbare veldgegevens.

Wat betekent het 75e percentiel?

Voor de betreffende meetwaarde ligt 75 procent van de waargenomen bezoeken op of onder die waarde. Het is niet het gemiddelde en ook niet de langzaamste klik van alle bezoekers samen.

Moet ik vier weken wachten voordat een verbetering zichtbaar wordt?

Niet per definitie. In een voortschrijdende periode van 28 dagen veranderen de gegevens geleidelijk. Labtests kunnen een wijziging direct onderzoeken, maar voorspellen niet wanneer rankings veranderen.

Moet elke afbeelding hoge laadprioriteit krijgen?

Nee. Bepaal welk beeld belangrijk is voor de eerste weergave. Onnodig veel hoge prioriteiten concurreren met elkaar. Afbeeldingen lager op de pagina kunnen juist uitgesteld laden.

Lost een snellere host alle problemen op?

Nee. Een sneller serverantwoord lost niet automatisch zwaar browserwerk of verschuivende inhoud op. Baseer de keuze op het knelpunt en controleer functionele gevolgen en kosten.

Kan een ontbrekende veldmeting als geslaagd tellen?

Niet in een volledig opleverrapport. Noteer welke data ontbreekt en waarop de conclusie wel gebaseerd is. Een tool kan een eigen uitzonderingsregel gebruiken; dat maakt de ontbrekende meetwaarde niet bekend.

Belooft Pico Yellow een vaste score of hogere omzet?

Nee. We kunnen scope, werkzaamheden, controles en rapportage afspreken. Uitkomsten hangen ook af van de website, bezoekers en externe onderdelen. Een offerte op maat is geen ranking- of omzetgarantie.

Bronnen en controleerbaarheid

De productdocumentatie is geraadpleegd op 12 september 2026. De diagnosematrix is een eigen werkvoorbeeld; alleen de uitdrukkelijk gedateerde Pico Yellow-meting bevat echte testresultaten. Eerdere algemene klantpercentages en ongedateerde scoreclaims zijn niet als bewijs overgenomen. Bewaar bij je eigen onderzoek dezelfde scheiding tussen feit, hypothese, ingreep en resultaat.