Yousource

Kennisbank · Core Web Vitals

Core Web Vitals in WordPress: eerst begrijpen, dan verbeteren

Alle kennisartikelen

Gebruik echte gebruikersdata om te bepalen welk probleem bezoekers ervaren en labmetingen om de oorzaak te onderzoeken. LCP gaat over het grootste zichtbare inhoudselement, INP over respons op interacties en CLS over onverwachte verschuivingen. Een Lighthouse-score is geen indexeringsbewijs.

Drie meetwaarden, drie verschillende vragen

Core Web Vitals beschrijven laden, reageren en visuele stabiliteit. Volgens web.dev zijn de grenzen voor ‘goed’ een LCP van maximaal 2,5 seconden, INP van maximaal 200 milliseconden en CLS van maximaal 0,1. Beoordeel het 75e percentiel, afzonderlijk voor mobiel en desktop. Dat gaat over de ervaring van de meeste bezoekers, niet over je snelste test.

LCP meet wanneer het grootste relevante inhoudselement zichtbaar wordt. Dat kan een afbeelding of een tekstblok zijn. INP kijkt naar de vertraging rond klikken, tikken en toetsenbordinteracties gedurende het bezoek. CLS telt onverwachte layoutverschuivingen. Geen van deze waarden vertelt op zichzelf of je aanbod begrijpelijk is of een betaling slaagt.

Onze volgorde is daarom: bepaal de getroffen paginagroep, herken het betrokken element of de interactie, formuleer een oorzaak en test één gerichte wijziging. Deze gids is een meet- en diagnosehandleiding. Voor een bredere verzameling concrete optimalisaties verwijzen we naar de bestaande vijftien WordPress-snelheidstips, niet naar een tweede lijst met dezelfde ingrepen.

De huidige aanbevolen grenzen uit web.dev

Metriek
LCP
Goed
≤ 2,5 seconden
Vraag voor de diagnose
Welk groot element verschijnt laat, en waarom?
Metriek
INP
Goed
≤ 200 milliseconden
Vraag voor de diagnose
Welke interactie wacht op scripts of rendering?
Metriek
CLS
Goed
≤ 0,1
Vraag voor de diagnose
Welke inhoud verplaatst al zichtbare elementen?

Velddata en labdata zijn geen concurrerende waarheden

Velddata komt van echte bezoeken met verschillende apparaten, netwerken, sessies en interacties. De openbare Chrome User Experience Report-data in PageSpeed Insights gebruikt een voortschrijdend venster; controleer welk bereik en welke periode het rapport toont. Bij onvoldoende gegevens kan URL-data ontbreken of kan de tool gegevens voor de hele origin tonen. Dat is niet hetzelfde als een gemeten goede pagina.

Een labtest is een herhaalbare opname onder vaste omstandigheden. Je kunt ermee aanwijzen welke afbeelding laat start of welk script veel werk vraagt. De test simuleert echter niet iedere bezoeker, ingelogde sessie of winkelhandeling. Een slechte veldwaarde naast een goede labtest kan wijzen op andere apparaten, langere bezoeken of interacties die de test niet uitvoert.

INP vraagt echte interacties. Total Blocking Time in Lighthouse kan een aanwijzing zijn voor zwaar JavaScript, maar is geen INP-vervanger. Test daarom ook een mobiel menu, filter, akkoordknop of variantkeuze met een performance-opname. Zonder klikken kun je een traag interactiepad missen, zelfs wanneer het eerste paginaladen goed lijkt.

Lees PageSpeed Insights en Search Console op het juiste niveau

PageSpeed Insights combineert beschikbare veldgegevens met een labtest van de ingevoerde pagina. Search Console groepeert vergelijkbare URL's in het Core Web Vitals-rapport. Een voorbeeld-URL vertegenwoordigt dus een groep, niet noodzakelijk een volledig onderzocht individueel probleem. Zoek het gedeelde template, de gedeelde assets of de gemeenschappelijke interactie voordat je alle pagina's los gaat aanpassen.

Sla datum, URL, apparaatcategorie, URL- of originbereik en de meetwaarden op. Gebruik dezelfde condities voor een vergelijking. Na een wijziging kan de labtest meteen verschillen, terwijl verzamelde velddata nog oude bezoeken bevat. Een validatieperiode of vertraagd rapport is geen bewijs dat de wijziging faalde; evenmin mag je op basis van één gunstige test concluderen dat alle bezoekers geholpen zijn.

Weinig verkeer kan betekenen dat er geen bruikbare openbare velddata is. Gebruik dan eigen zorgvuldig ingerichte gebruikersmetingen en praktische tests, zonder afwezigheid als voldoende te classificeren. De indexeringsrapporten van Search Console beantwoorden bovendien een andere vraag dan Web Vitals: of Google URL's indexeert, niet hoe snel gebruikers ze ervaren.

Van slechte waarde naar een toetsbare oorzaak

Begin niet automatisch met een cacheplugin. Splits LCP op in wachten op de server, ontdekken en ophalen van het element, en het uiteindelijke renderen. Bij INP kijk je naar invoervertraging, verwerking en de volgende zichtbare update. Bij CLS zoek je de elementen die bewegen en de inhoud die daarvoor ruimte opeist.

Diagnostische beslismatrix voor WordPress

Signaal
LCP: eerste response laat
Waarschijnlijke onderzoekslijn
TTFB, serverwerk en cachegedrag
Controle vóór ingrijpen
Vergelijk gecachet, ongecachet en ingelogd
Signaal
LCP: afbeelding begint laat
Waarschijnlijke onderzoekslijn
Ontdekking, prioriteit en lazy loading
Controle vóór ingrijpen
Identificeer het echte LCP-element in de opname
Signaal
INP: filter of menu reageert laat
Waarschijnlijke onderzoekslijn
Long tasks, handlers en grote DOM-updates
Controle vóór ingrijpen
Neem dezelfde interactie op een mobiel apparaat op
Signaal
CLS: inhoud schuift na laden
Waarschijnlijke onderzoekslijn
Beeldmaten, fonts, banners en widgets
Controle vóór ingrijpen
Bekijk layoutshift-regio's en reserveer passende ruimte

Prioriteer op bereik én risico

Een gedeeld template kan tientallen URL's raken. Geef een herhaalbaar probleem op belangrijke product- of aanvraagpagina's eerder aandacht dan een geïsoleerde decoratieve animatie. Controleer bij WordPress welke laag verantwoordelijk is: thema, page builder, uitbreiding, hosting of externe widget. Kies de kleinste wijziging die de vastgestelde oorzaak aanpakt.

Bij een laat ontdekt hoofdbeeld onderzoek je de laadprioriteit en passende afbeeldingsvariant; bij hoog serverwerk kijk je naar queries en cachegrenzen. Voor scripts geldt: verwijderen of later laden is alleen verantwoord als de functionaliteit behouden blijft. Toestemming, navigatie, checkout en toegankelijkheid mogen niet worden opgeofferd voor een aantrekkelijk rapportcijfer.

Reserveer ruimte voor beelden en embeds zonder onnodige lege schermen te maken. Test wat er gebeurt met lange producttitels, andere lettertypen en een open foutmelding. Een layout die alleen met voorbeeldtekst stabiel is, lost CLS in het echte gebruik niet op. Betrek iemand die de primaire taak uitvoert bij de controle, niet alleen de persoon die het rapport leest.

Wanneer is een optimalisatie voldoende gecontroleerd?

Noteer de oorspronkelijke hypothese en meet na de wijziging hetzelfde pad opnieuw. Test ook zonder gevulde cache en met een bestaande gebruikerssessie. Controleer formulieren, zoeken, filters en bestellen waar aanwezig. Een fout in het aanvraagpad is een regressie, zelfs wanneer LCP verbeterde.

Volg daarna velddata over voldoende nieuwe bezoeken en blijf onderscheid maken tussen URL- en groepsniveau. Rapporteer wat daadwerkelijk is gemeten en wat nog onzeker is. Goede Core Web Vitals zijn nuttig voor gebruikservaring, maar garanderen geen positie, verkeer, conversiestijging of indexering. Relevante inhoud en technische bereikbaarheid blijven afzonderlijke aandachtspunten.

  • De betrokken URL-groep en meetperiode zijn vastgelegd.
  • Het element of de interactie is in een opname geïdentificeerd.
  • De wijziging is onder vergelijkbare condities gemeten.
  • De primaire gebruikerspaden werken nog en de velddata wordt gevolgd.

Documentatie bij deze gids

Hulp bij de uitvoering? Bekijk de passende dienst en bespreek daar je situatie.

Bespreek een gerichte WordPress-diagnose