Wat zijn Core Web Vitals?

Core Web Vitals zijn een set specifieke, meetbare statistieken die Google gebruikt om de echte gebruikerservaring van een webpagina te beoordelen. Ze richten zich op drie fundamentele aspecten van hoe een pagina aanvoelt voor bezoekers: hoe snel de hoofdinhoud verschijnt, hoe snel de pagina reageert op interactie en hoe stabiel de layout is tijdens het laden. Google gebruikt Core Web Vitals sinds juni 2021 als officieel rangschikkingssignaal in zoekresultaten, wat betekent dat deze statistieken direct van invloed zijn op waar uw WordPress-site in de zoekresultaten verschijnt.

De drie Core Web Vitals uitgelegd

Elke Core Web Vital meet een andere dimensie van de gebruikerservaring en elk heeft een specifieke drempel die "goed", "moet worden verbeterd" en "slechte" prestaties definieert.

Largest Contentful Paint (LCP)

LCP meet hoe lang het duurt voordat het grootste zichtbare inhoudselement volledig op het scherm wordt gerenderd. Dit is meestal een hero-afbeelding, een groot tekstblok of een videoposter. De klok start wanneer de gebruiker voor het eerst naar de pagina navigeert en stopt wanneer dat grootste element klaar is met tekenen.

• Goed: 2,5 seconden of minder
• Moet worden verbeterd: tussen 2,5 en 4,0 seconden
• Slecht: meer dan 4,0 seconden

LCP is de statistiek die de waargenomen laadsnelheid het meest direct weerspiegelt. Een pagina kan een snelle Time to First Byte (TTFB) hebben, maar toch een slechte LCP hebben als het grootste element lang nodig heeft om te renderen vanwege grote afbeeldingen, render-blokkerende bronnen of trage serverresponsen voor kritieke assets.

Interaction to Next Paint (INP)

INP heeft First Input Delay (FID) vervangen als Core Web Vital in maart 2024. Terwijl FID alleen de vertraging van de allereerste interactie mat, meet INP de responsiviteit van alle interacties gedurende de levensduur van de pagina. Het volgt kliks, taps en toetsenbordinvoer en registreert de tijd vanaf de interactie tot wanneer de browser het scherm daadwerkelijk bijwerkt. De uiteindelijke INP-waarde is meestal de slechtst waargenomen interactie (met enkele uitschieteraanpassingen).

• Goed: 200 milliseconden of minder
• Moet worden verbeterd: tussen 200 en 500 milliseconden
• Slecht: meer dan 500 milliseconden

INP is een moeilijker te optimaliseren statistiek dan FID, omdat het elke interactie dekt, niet alleen de eerste. Een pagina kan snel reageren op de eerste klik, maar later traag worden wanneer er zware JavaScript draait.

Cumulative Layout Shift (CLS)

CLS meet hoeveel de zichtbare inhoud onverwacht verschuift terwijl de pagina wordt geladen en tijdens de sessie van de gebruiker. Telkens wanneer een element van positie verandert zonder dat de gebruiker dit initieert (bijvoorbeeld door op een knop te klikken), draagt die verschuiving bij aan de CLS-score. De score wordt berekend door de impactfractie (hoeveel van de viewport wordt beïnvloed) te vermenigvuldigen met de afstandsfractie (hoe ver het element is verplaatst).

• Goed: 0,1 of minder
• Moet worden verbeterd: tussen 0,1 en 0,25
• Slecht: meer dan 0,25

CLS is bijzonder frustrerend voor gebruikers. Stel u voor dat u op een knop probeert te klikken, maar net voordat uw klik landt, laadt er een advertentie boven en duwt deze de knop naar beneden. U klikt uiteindelijk op de advertentie. Dat is precies het soort ervaring dat CLS meet.

Hoe Google Core Web Vitals gebruikt als rangschikkingssignaal

Core Web Vitals maken deel uit van Google's bredere "page experience"-rangschikkingssignalen, die ook mobiele vriendelijkheid, HTTPS en de afwezigheid van opdringerige interstitials omvatten. Google evalueert Core Web Vitals met behulp van echte gebruikersgegevens uit het Chrome User Experience Report (CrUX). Dit betekent dat Google echte veldgegevens gebruikt van echte Chrome-gebruikers die uw site bezoeken, geen labgegevens van een enkele test. De rangschikkingsimpact geldt zowel voor mobiele als desktop-zoekresultaten. Hoewel inhoudsrelevantie de sterkste rangschikkingsfactor blijft, kunnen Core Web Vitals de doorslag geven tussen pagina's met vergelijkbare inhoudskwaliteit.

Core Web Vitals meten

Er zijn verschillende tools voor het meten van Core Web Vitals, en ze vallen in twee categorieën: veldgegevens (echte gebruikersmetingen) en labgegevens (gesimuleerde tests).

• PageSpeed Insights: Google's tool die zowel veldgegevens (van CrUX) als labgegevens (van Lighthouse) toont. De sectie veldgegevens toont de werkelijke Core Web Vitals-scores op basis van echte gebruikers van de afgelopen 28 dagen. Dit is de belangrijkste sectie omdat het weergeeft wat Google gebruikt voor rangschikking.
• Google Search Console: het Core Web Vitals-rapport groepeert uw URL's per status (goed, moet worden verbeterd, slecht) op basis van echte gebruikersgegevens. Het helpt u patronen op uw site te identificeren in plaats van individuele pagina's te controleren.
• Chrome User Experience Report (CrUX): de ruwe dataset die PageSpeed Insights en Search Console voedt. U kunt deze rechtstreeks bevragen via de CrUX API of BigQuery voor aangepaste analyse.
• Lighthouse: een lab-testtool ingebouwd in Chrome DevTools. Het simuleert paginaladingen op een vertraagde verbinding en rapporteert LCP en CLS (INP vereist echte gebruikersinteractie en kan niet betrouwbaar in labomstandigheden worden gemeten). Handig voor debuggen, maar weerspiegelt niet de echte gebruikerservaring.
• Web Vitals Chrome-extensie: een browserextensie die realtime Core Web Vitals-scores toont terwijl u browst, waardoor het gemakkelijk is om problemen op te sporen tijdens ontwikkeling en testen.

Echte gebruikersgegevens versus labgegevens

Dit onderscheid is belangrijker dan veel site-eigenaren beseffen. Labgegevens (van Lighthouse of vergelijkbare tools) simuleren een paginalading onder gecontroleerde omstandigheden: een specifiek apparaat, netwerksnelheid en locatie. Het is handig voor debuggen en het identificeren van technische problemen, maar het weerspiegelt niet wat werkelijke bezoekers ervaren. Echte gebruikersgegevens (veldgegevens) komen van echte Chrome-gebruikers die uw site bezoeken. Het legt het volledige bereik van apparaten, netwerksnelheden en geografische locaties vast die uw bezoekers gebruiken. Het rangschikkingsalgoritme van Google gebruikt veldgegevens, geen labgegevens. Een pagina kan in Lighthouse 95 scoren, maar in het veld nog steeds slechte Core Web Vitals hebben, omdat echte gebruikers op tragere apparaten een andere ervaring hebben.

Veelvoorkomende WordPress-problemen voor LCP

WordPress-sites worstelen vaak met LCP vanwege verschillende veelvoorkomende problemen:

• Grote, niet-geoptimaliseerde hero-afbeeldingen: een hero-afbeelding van 3 MB heeft veel langer nodig om te downloaden en te renderen dan een correct gecomprimeerde WebP-versie van 200 KB. Comprimeer altijd afbeeldingen, gebruik moderne formaten (WebP of AVIF) en lever afbeeldingen van geschikte grootte voor het scherm van de bezoeker.
• Render-blokkerende CSS en JavaScript: wanneer de browser CSS- of JavaScript-bestanden in de <head> tegenkomt, moet hij deze downloaden en parseren voordat hij inhoud kan renderen. Te veel of te grote stylesheets vertragen LCP aanzienlijk. Inline kritieke CSS en stel niet-essentiële stylesheets uit om dit op te lossen.
• Trage serverresponstijd (TTFB): als uw hostingserver 2 seconden nodig heeft om alleen al de HTML te genereren, kan uw LCP onmogelijk onder de 2,5 seconden zijn. Upgrade hosting, schakel server-side caching in en gebruik een CDN om de TTFB te verminderen.
• Te veel plug-ins: elke plug-in voegt mogelijk CSS en JavaScript toe aan elke pagina. Sites met 30+ actieve plug-ins hebben vaak tientallen render-blokkerende bronnen die strijden om bandbreedte.
• Ontbrekend fetchpriority-attribuut: het LCP-element moet fetchpriority="high" hebben om de browser te signaleren dat hij dit eerst moet downloaden. Zonder dit kan de browser andere bronnen prioriteren boven de belangrijkste.

Veelvoorkomende WordPress-problemen voor INP

INP-problemen in WordPress zijn meestal terug te voeren op JavaScript-uitvoering:

• Zware JavaScript van plug-ins: sliders, popups, analyseertools, chatwidgets en social-sharing-plug-ins voegen allemaal JavaScript toe dat op de hoofdthread draait. Wanneer een gebruiker op iets klikt, moet de browser mogelijk eerst andere scripts uitvoeren voordat hij kan reageren.
• Scripts van derden: Google Analytics, Facebook Pixel, advertentiescripts en livechattools voeren vaak lange taken uit die de hoofdthread blokkeren. Deze scripts laden met async of defer helpt, maar ze verbruiken nog steeds verwerkingstijd.
• Buitensporige DOM-grootte: pagina's met duizenden DOM-elementen (vaak bij paginabouwers zoals Elementor of Divi) hebben langer nodig voor de browser om bij te werken wanneer interacties plaatsvinden. Een klik die een CSS-klasse wijzigt, kan dure stijlherberekeningen activeren over duizenden elementen.
• Lange hoofdthread-taken: elke JavaScript-taak die langer dan 50 milliseconden draait, wordt beschouwd als een "lange taak" die de responsiviteit blokkeert. Het opbreken van grote taken in kleinere stukken met behulp van requestAnimationFrame- of setTimeout-patronen kan helpen.

Veelvoorkomende WordPress-problemen voor CLS

Layoutverschuivingen op WordPress-sites worden meestal veroorzaakt door:

• Afbeeldingen zonder breedte- en hoogte-attributen: wanneer een afbeelding wordt geladen zonder expliciete afmetingen, weet de browser niet hoeveel ruimte hij moet reserveren. De inhoud eronder verschuift wanneer de afbeelding eindelijk rendert. Stel altijd width- en height-attributen in op afbeeldingen (WordPress doet dit automatisch voor afbeeldingen die via de mediabibliotheek zijn toegevoegd).
• Webfontladen: aangepaste fonts die laden na de initiële render kunnen tekst laten herfloweren wanneer het font wordt vervangen. Gebruik font-display: swap in combinatie met font-preloading om dit effect te minimaliseren, of overweeg font-display: optional voor niet-kritieke fonts.
• Advertentie-injecties: advertenties die dynamisch laden, duwen inhoud rond. Reserveer ruimte voor advertentieslots met containers van vaste grootte, zelfs voordat de advertentie laadt.
• Dynamisch geïnjecteerde inhoud: cookieconsentbanners, nieuwsbriefpopups en notificatiebalken die verschijnen nadat de pagina is geladen, kunnen inhoud verschuiven als ze in de documentstroom worden ingevoegd in plaats van bovenop te worden gelegd.
• Embeds en iframes zonder afmetingen: YouTube-video's, tweets en andere ingesloten inhoud zonder expliciete afmetingen veroorzaken verschuivingen wanneer ze laden.

Core Web Vitals verbeteren voor WordPress

Hier is een praktische aanpak om elke statistiek op een WordPress-site te verbeteren:

• Voor LCP: optimaliseer en comprimeer afbeeldingen (gebruik WebP/AVIF), gebruik een CDN, schakel server-side caching in, inline kritieke CSS, stel niet-essentiële JavaScript uit en voeg fetchpriority="high" toe aan de LCP-afbeelding. Verwijder ongebruikte plug-ins die render-blokkerende bronnen toevoegen.
• Voor INP: controleer en verwijder onnodige JavaScript, stel scripts van derden uit, verminder de DOM-grootte (overweeg lichtere paginabouwers of native WordPress-blokken) en breek lange JavaScript-taken op in kleinere stukken. Gebruik het tabblad Performance in Chrome DevTools om te identificeren welke scripts de hoofdthread blokkeren.
• Voor CLS: stel expliciete afmetingen in op alle afbeeldingen, video's en iframes. Preload fonts en gebruik font-display: swap. Reserveer ruimte voor advertenties en dynamische inhoud. Vermijd het invoegen van inhoud boven bestaande inhoud na het laden van de pagina.

Wat InspectWP controleert

InspectWP analyseert meerdere factoren die direct van invloed zijn op Core Web Vitals-scores. Het controleert HTTP-compressie (die LCP beïnvloedt), HTTP/2-gebruik (waardoor parallel laden van bronnen mogelijk is), het aantal JavaScript- en CSS-bestanden (wat render-blokkering kan veroorzaken en zowel LCP als INP kan beïnvloeden), beeldoptimalisatiemogelijkheden, HTML-documentgrootte en andere prestatiegerelateerde indicatoren. Dit geeft u een duidelijk beeld van wat er moet worden verbeterd om betere Core Web Vitals-scores te behalen.