Kennisbank · Core Web Vitals
Core Web Vitals in WordPress: eerst begrijpen, dan verbeteren
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?
| Metriek | Goed | Vraag voor de diagnose |
|---|---|---|
| LCP | ≤ 2,5 seconden | Welk groot element verschijnt laat, en waarom? |
| INP | ≤ 200 milliseconden | Welke interactie wacht op scripts of rendering? |
| CLS | ≤ 0,1 | 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
| Signaal | Waarschijnlijke onderzoekslijn | Controle vóór ingrijpen |
|---|---|---|
| LCP: eerste response laat | TTFB, serverwerk en cachegedrag | Vergelijk gecachet, ongecachet en ingelogd |
| LCP: afbeelding begint laat | Ontdekking, prioriteit en lazy loading | Identificeer het echte LCP-element in de opname |
| INP: filter of menu reageert laat | Long tasks, handlers en grote DOM-updates | Neem dezelfde interactie op een mobiel apparaat op |
| CLS: inhoud schuift na laden | Beeldmaten, fonts, banners en widgets | 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