Core Web Vitals: welke metingen vragen om een ingreep?

Je opent PageSpeed Insights, ziet een matige score en krijgt een lange lijst adviezen. Afbeeldingen verkleinen, scripts uitstellen, ongebruikte code verwijderen. Waar begin je? Bij het probleem dat mensen op je website daadwerkelijk tegenkomen. De adviezen zijn aanwijzingen om dat probleem te onderzoeken; ze zijn nog geen werkplanning.

Core Web Vitals helpen om drie onderdelen van de gebruikservaring te beoordelen: laden, reageren en visuele stabiliteit. Gebruik ze om een gerichte verbetering te kiezen. Een technisch rapport wordt pas bruikbaar als je weet welke pagina, welke handeling en welke bezoekers achter de meting zitten.

De huidige Core Web Vitals zijn LCP, INP en CLS. INP heeft de oudere FID-meting vervangen. Dat is een belangrijke wijziging ten opzichte van veel artikelen uit 2021: alleen de eerste interactie bekijken is onvoldoende om de responsiviteit van een bezoek te beoordelen. De definities en grenswaarden staan in het overzicht van Web Vitals.

Deze beoordeling gebruikt het 75e percentiel: de waarde waar driekwart van de gemeten bezoeken op of onder uitkomt. Het is dus geen gemiddelde en ook geen belofte dat iedere bezoeker dezelfde ervaring heeft. Kijk mobiel en desktop afzonderlijk na. Een goede desktopuitkomst zegt weinig over iemand met een minder krachtige telefoon.

PageSpeed Insights toont veldgegevens en een laboratoriumtest. Veldgegevens beschrijven ervaringen van echte Chrome-gebruikers. De Lighthouse-test onderaan onderzoekt de pagina onder ingestelde omstandigheden. Dat zijn twee verschillende vragen: wat ervaren bezoekers, en wat kan deze test over een mogelijke oorzaak laten zien?

Controleer bovenaan of de veldgegevens over deze URL of over de gehele oorsprong gaan. Die oorsprong is de combinatie van protocol en host, bijvoorbeeld https://voorbeeld.nl. Bij onvoldoende gegevens voor een afzonderlijke pagina kan een breder beeld worden getoond. Noteer ook het apparaat en de meetperiode. Google beschrijft deze onderdelen van PageSpeed Insights.

Maak daarna een klein meetblad. Schrijf de onderzochte URL, het paginatype, apparaat, datum, veldwaarden en waargenomen handeling op. Zet een opvallende laboratoriumuitkomst ernaast. Zo voorkom je dat een collega volgende week een andere pagina op desktop meet en denkt dat het mobiele probleem is verdwenen.

Een groene laboratoriumtest en slechte veldgegevens spreken elkaar niet noodzakelijk tegen. Echte bezoekers gebruiken verschillende apparaten, verbindingen en paginastaten. Een test die alleen de pagina opent, ziet bovendien niet alles wat na het openen gebeurt. Denk aan een filter, ingeladen aanbevelingen of een winkelmand die wordt bijgewerkt. web.dev licht de verschillen tussen lab- en veldgegevens toe.

Ontbrekende gegevens betekenen niet dat de website slaagt. Ze betekenen ook niet dat er bewezen een probleem is. Maak de onzekerheid zichtbaar. Eigen bezoekersmetingen kunnen helpen, mits zorgvuldig ingericht met passende privacykeuzes en voldoende context om een getal te begrijpen.

Een grote foto is een mogelijke oorzaak, maar niet de enige. Misschien reageert de server laat. Misschien ontdekt de browser de afbeelding pas nadat JavaScript is uitgevoerd. Of het bestand is al binnen, maar de pagina kan het nog niet tonen. Alleen de foto extra comprimeren lost die andere vertragingen niet op.

Vraag de ontwikkelaar om het LCP-element en de verdeling van de wachttijd te laten zien: serverreactie, wachten op de bron, downloaden en tonen. Dat maakt de voorgestelde ingreep controleerbaar. De LCP-handleiding van web.dev werkt deze verdeling uit.

Voor een belangrijke productfoto is een bruikbare opdracht bijvoorbeeld: toon dezelfde foto eerder, in een passende resolutie, zonder materiaal of details onduidelijk te maken. Controleer vervolgens zowel de meting als het beeld op een echte telefoon. Een technisch snellere pagina waarop een klant het product niet kan beoordelen, is geen geslaagde verbetering.

Een pagina kan vlot verschijnen en daarna stroef reageren. Open daarom niet alleen de homepage. Kies een productvariant, gebruik een filter, open de mobiele navigatie en vul een formulier in. Noteer bij welke handeling de interface hapert en wat er op dat moment verandert.

Een ontwikkelaar kan vervolgens onderzoeken of werk op de hoofdthread de reactie vertraagt, of een eventhandler te veel doet, of het tekenen van de nieuwe toestand kostbaar is. Werk opsplitsen en overbodige verwerking verminderen kunnen helpen. De INP-handleiding beschrijft hoe de vertraging voor, tijdens en na verwerking wordt onderzocht.

Maak onderscheid tussen reactie en afronding. Een bestelknop kan direct tonen dat de aanvraag wordt verwerkt, terwijl een serverantwoord langer duurt. Dat vraagt nog steeds een duidelijke wachttoestand en foutafhandeling. Een goede INP is geen bewijs dat het bestellen zelf foutloos of snel wordt afgerond.

Bekijk of tekst, afbeeldingen of knoppen verspringen tijdens laden en tijdens gebruik. Een beeld zonder gereserveerde afmetingen, laat verschijnende content en webfonts kunnen de indeling beïnvloeden. web.dev beschrijft veelvoorkomende CLS-oorzaken, waaronder verschuivingen die pas na de eerste laadfase optreden.

Observeer een concrete taak. Staat de knop waarop iemand wil tikken nog op dezelfde plaats als de productfoto klaar is? Schuift een melding het formulier onverwacht naar beneden? Leg de situatie vast met een korte opname en beschrijf de voorwaarden om haar te herhalen. Dat is voor herstel veel bruikbaarder dan alleen “de pagina springt”.

De oplossing moet ruimte organiseren, niet informatie verbergen. Afmetingen reserveren voor media, meldingen op een vaste plek tonen of de laadvolgorde aanpassen kan de inhoud behouden en de beweging beperken. Controleer ook lange teksten en foutmeldingen; de oplossing moet ook met langere inhoud goed werken.

Gebruik voor prioriteit drie vragen: hoeveel relevante bezoekers komen dit tegen, hoe ernstig belemmert het hun taak, en hoe zeker zijn we van de oorzaak? Een gedeeld mobiel producttemplate kan urgenter zijn dan een incidenteel slechte test van een weinig bezochte pagina. Daarvoor heb je je eigen gebruiksgegevens nodig; een algemene score beslist dit niet.

• Waarneming: welke pagina en handeling geven een probleem, en onder welke omstandigheden?
• Ingreep: welk deel van laden, verwerken of indeling verandert?
• Acceptatie: welke herhaalbare test laat zien dat de ingreep werkt, en welke functionaliteit moet behouden blijven?
• Nacontrole: wie bekijkt na publicatie de nieuwe veldgegevens en eventuele regressies?

Vergelijk voor en na onder dezelfde testvoorwaarden. Houd de releasedatum bij. Een rollende veldmeting bevat na publicatie nog bezoeken van voor de wijziging; verwacht dus geen onmiddellijke volledige omslag in het rapport. Controleer intussen of de oplossing op andere pagina's geen nieuw probleem heeft veroorzaakt.

Google gebruikt Core Web Vitals in zijn rankingsystemen, maar goede waarden garanderen geen hoge positie. Relevantie en de overige pagina-ervaring blijven belangrijk. Dat staat ook in Googles toelichting op Core Web Vitals en zoekresultaten.

Stop daarom niet bij groen. Controleer of iemand de taak begrijpt, formulieren kan bedienen en de juiste informatie vindt. Andersom hoef je geen complete website te herbouwen vanwege één oranje meting. Leg eerst het concrete probleem en de omvang vast.

Bij technische SEO plaatsen we performance naast bereikbaarheid, indexering en technische samenhang. Neem voor een bespreking één relevante URL, het juiste rapport en een reproduceerbare handeling mee. Daarmee ontstaat een gerichte opdracht in plaats van “maak alles honderd”. Bespreek je vraagstuk.

Fotografie: Mikhail Nilov / Pexels.