Core Web Vitals uitgelegd voor webdesigners

LCP. INP. CLS.

Als je die termen voor het eerst ziet, denk je: dit ga ik googelen als het relevant wordt. Dan wordt het relevant. En dan google je het toch, midden in een klantgesprek, terwijl je doet alsof je iets typt.

Ik heb drie jaar lang websites geoptimaliseerd zonder echt te begrijpen wat die balkjes bovenaan een PageSpeed-rapport betekenden. Ze waren groen, dus het was goed. Ze waren rood, dus het was slecht. Meer had ik niet nodig, dacht ik.

Totdat ik begreep wat er precies wordt gemeten, en opeens zag ik op elke website die ik opende waar het misging. In dit artikel leg ik je uit wat de drie Core Web Vitals meten, waarom ze in Googles ranking zitten en wat je concreet doet als ze op rood staan.

Waarom Google dit is gaan bijhouden

Jarenlang kon je hoog ranken met uitstekende content op een website die laadde als een overbeladen veerboot op een warme augustusmiddag. Toen veranderde er iets.

In 2021 maakte Google Core Web Vitals officieel onderdeel van het rankingalgoritme. Niet als suggestie. Als factor. Pagina’s die slecht scoren ranken lager dan vergelijkbare pagina’s die goed scoren, ook als de content beter is.

Het effect is niet dramatisch. Geen pagina die van positie 3 naar positie 34 valt over één nacht. Maar cumulatief, over weken en maanden, begint een concurrent die wél op groen staat rustig het zoekverkeer naar zich toe te trekken. Terwijl jij staat te puzzelen waarom je bereik daalt.

Jij als webdesigner bent de enige in de kamer die dit kan oplossen. Je klant weet niet eens dat het bestaat.

LCP: hoe snel ziet de bezoeker iets

LCP staat voor Largest Contentful Paint. Vertaald naar normaal Nederlands: hoe lang duurt het voor het grootste zichtbare element op de pagina geladen is?

Dat is bijna altijd de hero-afbeelding of de hoofdkop van een artikel. Niet de hele pagina, alleen het grootste stuk dat je ziet zonder te scrollen. Google wil LCP onder de 2,5 seconden. Tussen 2,5 en 4 seconden is oranje. Boven de 4 seconden staat het op rood.

Ik optimaliseerde onlangs een site waarbij de LCP op mobiel 8,8 seconden was. Dat is langer dan het duurt om een kop koffie in te schenken, te bedenken dat je eigenlijk thee wil, en dan toch voor koffie te kiezen. Na optimalisatie stond de LCP op 1,8 seconden. Dat verschil merk je.

De oorzaken die ik het vaakst zie:

• De hero-afbeelding is niet geoptimaliseerd
• Diezelfde afbeelding heeft lazy loading aan, terwijl dat voor afbeeldingen boven de vouw juist niet mag
• De server reageert traag (hoge Time to First Byte)
• Er is geen caching ingesteld

De snelste fix: optimaliseer de hero-afbeelding, converteer naar WebP, zet lazy loading er op die afbeelding juist af. Voeg fetchpriority="high" toe aan het img-element. Dat vertelt de browser: dit element gaat voor. Alles andere wacht.

INP: je pagina laadt, maar doet hij ook iets als je erop klikt?

INP staat voor Interaction to Next Paint. Het meet hoe snel een pagina reageert als je ergens op klikt, typt of tikt. Niet alleen de eerste keer, maar elke keer.

Dat laatste is nieuw. INP heeft FID vervangen, de meting die alleen de allereerste interactie bijhield. FID was een beetje als een sollicitatiegesprek waarbij je alleen de eerste vraag beantwoordt en daarna compleet zwijgt. Representatief is anders.

Google wil INP onder de 200 milliseconden. Boven de 500 ms staat het op rood. De oorzaak is bijna altijd JavaScript: te veel scripts, te zware plugins, een slider die de main thread volledig bezet houdt terwijl een bezoeker al drie keer op dezelfde knop heeft geklikt.

Ik opende onlangs Query Monitor op een site en telde 43 actieve plugins. Zeventien hadden in de afgelopen 90 dagen geen enkele activiteit gehad. Dat is geen WordPress-beheer, dat is digitaal hoarding. Verwijder wat je niet gebruikt. Het helpt echt.

CLS: de pagina die wegspringt net als je wil klikken

CLS staat voor Cumulative Layout Shift. Het meet hoeveel de pagina visueel verschuift terwijl hij laadt.

Je kent het. Je beweegt je vinger naar een knop, de pagina springt drie centimeter omhoog omdat er net een advertentie of afbeelding laadt, en je klikt op de verkeerde plek. Je hebt nu gratis een pagina geopend die je helemaal niet wilde, en je ergernis is niet meer gratis. Dat is CLS.

Google wil CLS onder de 0,1. Dat klinkt als een willekeurig getal. Het is de grens tussen acceptabel en bezoekers die afhaken.

De oorzaken zijn bijna altijd dezelfde. Afbeeldingen zonder vaste breedte en hoogte in de HTML: als de browser niet van tevoren weet hoeveel ruimte een afbeelding inneemt, schuift de rest van de pagina mee zodra die afbeelding laadt. Embeds zoals YouTube of Google Maps die hun grootte pas kenbaar maken nadat ze zijn geladen. Webfonts die later inladen en andere letters verdringen.

De fix: voeg altijd width en height attributen toe aan img-elementen. Vijf minuten werk, lost 80% van de gevallen op. Begin daarmee.

Hier vind je je scores

Google Search Console geeft je de meest betrouwbare data. Onder “Ervaring” en dan “Core Web Vitals” vind je de scores van echte bezoekers op jouw site, gemiddeld over de afgelopen 28 dagen.

Geen simulatie. Geen virtueel apparaat op een gemiddelde verbinding. Echte mensen die jouw site hebben bezocht en hun ervaring hebben doorgegeven aan Google.

PageSpeed Insights geeft je een directe meting per URL, handig om snel een specifieke pagina te checken. Wil je weten hoe je zo’n rapport leest? Dat lees je in dit artikel. Als je site nog weinig verkeer heeft, is er soms niet genoeg velddata beschikbaar in Search Console. Dan is PageSpeed Insights je enige houvast.

Altijd beginnen bij LCP

Drie meetpunten. Waar begin je?

LCP.

Van de drie heeft LCP de meeste directe impact op de gebruikerservaring en is het bij de meeste WordPress-sites ook het makkelijkst te verbeteren. Afbeeldingen optimaliseren, hero-afbeelding prioriteit geven, caching instellen: dat zijn concrete stappen die je dit weekend al kunt zetten en waarna je een meetbaar verschil ziet.

INP pak je aan als LCP op groen staat. CLS is daarna vaak een uurtje werk.

Één ding tegelijk. Meten na elke aanpassing. Dan door. Dat is het systeem dat werkt, en nadrukkelijk niet het systeem waarbij je alles tegelijk aanpast en daarna niet meer weet wat het verschil heeft gemaakt. Dat laatste heb ik ook gedaan, voor wie het zich afvroeg.

Wil je leren hoe je WordPress-websites structureel snel maakt, van Core Web Vitals tot WP Rocket tot hosting? In de Speed Boost Camp doe je dat in vijf weken, met een systeem dat je daarna op elke site kunt toepassen.