Core Web Vitals: fix het sjabloon, niet de pagina.

Core Web Vitals zijn nog altijd wat ze in de kern altijd waren: drie meetbare signalen die Google gebruikt om te bepalen hoe prettig een pagina laadt en reageert. De drempelwaarden zijn niet veranderd, LCP binnen 2,5 seconden, INP onder de 200 milliseconden, CLS onder de 0,1. Wat wel opvalt bij SEO bureau-trajecten die we bij MKB-sites en webshops langslopen, is dat bijna niemand op deze drempels struikelt door gebrek aan kennis. Het gaat meestal mis omdat een fix op een paar pagina's wordt toegepast terwijl het hele sjabloon eronder lijdt, of omdat een tool een groen vinkje laat zien dat niets zegt over wat echte bezoekers ervaren. Dat onderscheid is precies waar dit artikel om draait.

LCP, INP en CLS in gewone taal

LCP, Largest Contentful Paint, meet hoe lang het duurt voordat het grootste zichtbare element op een pagina is geladen. Meestal is dat een hero-afbeelding of een kop. Onder de 2,5 seconden is goed, tussen de 2,5 en 4 seconden moet het beter, en daarboven is het ronduit traag.

INP, Interaction to Next Paint, is de opvolger van de oude FID-meting en kijkt naar elke interactie tijdens een bezoek, niet alleen de eerste klik. Klik iemand op een filter in je webshop en duurt het reageren langer dan 200 milliseconden, dan telt dat mee. Tussen 200 en 500 milliseconden is twijfelachtig, daarboven merkt een bezoeker het gewoon als traag.

CLS, Cumulative Layout Shift, meet hoeveel de pagina rondspringt terwijl hij laadt. Een score onder de 0,1 is prima, tussen 0,1 en 0,25 begint het te irriteren, en daarboven klikt iemand per ongeluk op iets anders dan de bedoeling was. Bij Nederlandse webshops is dit vaak de meest onderschatte van de drie, en verderop leggen we uit waarom.

Lighthouse groen zegt minder dan je denkt

Een veelgemaakte vergissing is het vertrouwen op één test in PageSpeed Insights of Lighthouse en die score als eindstation behandelen. Dat is labdata, gemeten op een gesimuleerde verbinding, op één moment, op één pagina. Search Console rapporteert iets heel anders: veldata uit de Chrome User Experience Report, verzameld bij echte bezoekers, over een periode van achtentwintig dagen, en beoordeeld op het vijfenzeventigste percentiel. Met andere woorden, driekwart van je bezoekers moet de goede score halen, niet alleen de testomgeving.

Dat verschil verklaart waarom een pagina die in Lighthouse een negentig scoort, in het Core Web Vitals-rapport van Search Console alsnog als "verbetering nodig" kan verschijnen. Beide tools zijn nuttig, maar ze meten niet hetzelfde, en wie alleen naar de labscore kijkt, mist het echte beeld.

Waarom per-pagina denken de meeste schade aanricht

Wat we in de praktijk vaak zien, is dat een bureau of interne marketeer één productpagina optimaliseert, trots de voor- en na-score laat zien, en denkt dat de klus geklaard is. Ondertussen draaien de andere driehonderd productpagina's op exact hetzelfde sjabloon, met exact dezelfde te zware carrouselscript of hetzelfde niet-gecomprimeerde hero-beeld. Search Console groepeert URL's juist op sjabloon, en dat is ook de enige manier om dit schaalbaar op te lossen. Zoek naar het patroon, niet naar het losse geval.

Fix het sjabloon, niet de pagina. Eén productpagina optimaliseren terwijl driehonderd andere op hetzelfde sjabloon draaien, verandert niets aan wat Google daadwerkelijk meet.

Typische valkuilen bij Nederlandse webshops

Een paar dingen die we structureel tegenkomen bij shops die op Shopify, WooCommerce of een maatwerkplatform draaien.

• Het cookiebanner dat na het laden van de pagina alsnog inschuift en de hele lay-out omlaag duwt. Reserveer vaste ruimte voor de banner in de CSS, dan telt die verschuiving niet meer mee voor CLS.
• Een hero-afbeelding die als PNG van drie megabyte wordt ingeladen terwijl WebP of AVIF met een kwart van de bestandsgrootte hetzelfde resultaat geeft.
• Chatwidgets, reviewscripts en upsell-apps die allemaal los worden ingeladen zonder dat iemand ooit heeft gekeken welke er nog echt gebruikt worden. Elke widget kost een netwerkverzoek en rekentijd, en dat raakt direct de INP.
• Webfonts die pas laat laden waardoor tekst even onzichtbaar is of van lettertype wisselt. Gebruik font-display: swap en laad het lettertype vooraf.

Geen van deze punten vraagt om een complete herbouw. Het zijn stuk voor stuk aanpassingen die een ontwikkelaar in een middag kan doorvoeren, mits je weet waar je moet zoeken.

Wat je morgen kunt doen

Begin in Search Console bij het rapport Core Web Vitals en kijk welk sjabloon, mobiel of desktop, in de categorie "verbetering nodig" of "slecht" valt. Draai vervolgens PageSpeed Insights op een representatieve pagina van dat sjabloon en lees welk element de LCP bepaalt. Vaak is dat gewoon de eerste productfoto. Comprimeer die, serveer hem in WebP, en geef hem een preload-tag in de head van de pagina.

Loop daarna je scripts na. Open het Netwerktabblad in de developer tools, sorteer op laadtijd, en vraag jezelf bij elk los script af of een bezoeker het zou missen als het er niet was. Alles wat niet direct nodig is voor de eerste weergave, kan uitgesteld worden geladen. Voor de lay-outverschuivingen geldt hetzelfde principe, reserveer vooraf ruimte voor afbeeldingen, advertenties en embeds met een vaste hoogte en breedte in de HTML, ook als het bestand zelf nog moet laden.

Een kanttekening die nogal eens vergeten wordt: een snelle, stabiele pagina helpt niet alleen voor klassieke zoekresultaten. Crawlers van AI-zoeksystemen werken met dezelfde soort budgetten en haken sneller af bij trage of instabiele pagina's, wat weer meespeelt bij GEO. Technische basis op orde hebben blijft dus op meerdere fronten lonen.

Wil je weten hoe jouw site er in het Core Web Vitals-rapport voorstaat en wat er sjabloonbreed te winnen valt, lees dan ook onze eerdere artikelen over technische SEO op het blog. Plan een strategiegesprek als je liever met iemand meekijkt dan zelf te blijven puzzelen.

Veelgestelde vragen

Zijn Core Web Vitals nog steeds een rankingfactor?

Ja. Google noemt ze zelf nog altijd onderdeel van de bredere pagina-ervaring die meeweegt in de zoekresultaten. Ze zijn geen dominante factor zoals relevante content dat is, maar bij twee vergelijkbare pagina's kan de snellere en stabielere het verschil maken.

Wat is het verschil tussen de score in PageSpeed Insights en het rapport in Search Console?

PageSpeed Insights toont labdata van één gesimuleerde meting op dat moment. Search Console toont veldata van echte bezoekers over de afgelopen achtentwintig dagen, beoordeeld op het vijfenzeventigste percentiel. Voor je eigen inzicht is Lighthouse handig, voor wat Google daadwerkelijk beoordeelt is het Search Console-rapport leidend.

Hoe snel zie ik verbetering terug nadat ik iets heb aangepast?

Reken niet op een verandering binnen een paar dagen. Search Console werkt met een voortschrijdend gemiddelde van achtentwintig dagen veldata, dus het duurt enige tijd voordat een fix zichtbaar doorwerkt in het rapport. Gebruik PageSpeed Insights ondertussen om te controleren of de technische aanpassing zelf werkt zoals bedoeld.