Core Web Vitals: Waarom een Snelle Site Wint

Snelheid is de enige kwaliteitsverbetering waarvoor je de businesscase niet hoeft te verdedigen. Een trage site raakt mensen kwijt voordat ze een woord lezen, en de mensen die hij kwijtraakt zijn onevenredig vaak degenen op een telefoon, op mobiel internet, die je via een zoekopdracht vonden — met andere woorden, nieuwe klanten.

Google meet dit met drie getallen, verzameld bij echte Chrome-gebruikers in plaats van in een labtest. Dit zijn ze, en dit verbetert ze werkelijk.

De drie getallen

Largest Contentful Paint (LCP) — hoe lang tot het grootste element in beeld verschijnt. Meestal een hero-afbeelding of een kop. Goed is onder 2,5 seconde. Dit is de "is het er al"-maat en telt het zwaarst voor de vraag of iemand blijft.

Interaction to Next Paint (INP) — als iemand tikt of klikt, hoe lang voordat de pagina zichtbaar reageert. Goed is onder 200 milliseconden. Dit verving First Input Delay omdat het elke interactie meet, niet alleen de eerste, wat een veel eerlijker beeld bleek.

Cumulative Layout Shift (CLS) — hoeveel de pagina verspringt tijdens het laden. Goed is onder 0,1. Dit is de maat achter de universele ervaring dat je naar een knop reikt en een advertentie hem onder je duim vandaan duwt.

De drempel is dat 75 procent van de bezoeken "goed" moet halen. Je wordt niet beoordeeld op je gemiddelde, maar op de vraag of de meeste mensen een fatsoenlijke ervaring hadden.

Wat ze meestal breekt

In onze ervaring zijn de oorzaken saai consistent.

LCP is bijna altijd afbeeldingen. Een foto van 3 MB op volle resolutie naar een telefoon gestuurd, zonder modern formaat en zonder afmetingen. De oplossingen zijn weinig spectaculair: serveer WebP of AVIF, schaal de afbeelding op wat er echt wordt getoond, markeer de hero-afbeelding als hoge prioriteit en laad hem nooit lui, en laad alles onder de vouw wél lui.

De tweede oorzaak zijn render-blokkerende bronnen — een stylesheet of lettertype dat de browser moet ophalen voordat hij iets kan tekenen. Lettertypen zelf hosten en de kleine hoeveelheid CSS voor het eerste scherm inline zetten lost dat meestal op.

INP is bijna altijd JavaScript. Te veel ervan, draaiend op de hoofdthread, waardoor de browser niet kan reageren. De eerlijke vraag voor de meeste mkb-sites is hoeveel van dat JavaScript iets doet waar de bezoeker om vroeg. Een carrouselbibliotheek, drie trackingscripts, een chatwidget en een animatieframework tellen op een middenklasse Android-telefoon zo op tot een seconde geblokkeerde hoofdthread.

CLS is bijna altijd ontbrekende afmetingen. Afbeeldingen en iframes zonder breedte en hoogte, weblettertypen die wisselen en de tekst laten herschikken, banners die na het laden bovenaan worden ingeschoten, en content die uitklapt als een script klaar is. Reserveer de ruimte voordat hij wordt gevuld en het probleem verdwijnt.

Wat de getallen echt verbetert

Grofweg op volgorde van rendement:

1. Repareer de hero-afbeelding. Juist formaat, juiste maat, hoge prioriteit, expliciete afmetingen. Deze ene wijziging tilt een falende LCP vaak in z'n eentje naar groen.
2. Gooi JavaScript weg dat je niet gebruikt. Elk verwijderd script helpt dubbel: minder downloaden, minder uitvoeren. Begin bij de analytics- en marketingtags waar niemand het afgelopen jaar naar heeft gekeken.
3. Render op de server. Komt de pagina binnen als HTML in plaats van als lege huls die JavaScript vult, dan heb je de grootste enkele bron van vertraging weggenomen. Dat is de belangrijkste reden dat wij met een server-renderend framework bouwen.
4. Host lettertypen zelf en laad hooguit twee gewichten. Een lettertypeverzoek naar een derde partij is een hele extra verbinding voordat er tekst kan verschijnen.
5. Reserveer ruimte voor alles wat laat laadt. Afbeeldingen, embeds, advertenties, cookiebanners.
6. Serveer vanaf een plek dicht bij je bezoekers. Een Nederlands bedrijf op een Amerikaanse server betaalt bij elk verzoek zonder reden een retourtje over de oceaan.

Meet het goed

Twee tools, en het verschil ertussen doet ertoe.

PageSpeed Insights geeft een labscore en, bij genoeg verkeer, de velddata van echte Chrome-gebruikers. De velddata telt voor de zoekmachine; de labscore is een diagnose.

Search Console heeft een Core Web Vitals-rapport dat je echte gebruikers per paginatype groepeert. Dat is degene om te vertrouwen, want het meet je feitelijke bezoekers op hun feitelijke apparaten.

Eén waarschuwing die herhaling verdient: jaag niet op de 100. Een labscore van 100 op een pagina die echte gebruikers traag vinden is niets waard, en de laatste paar punten kosten meestal meer dan ze opleveren. Kom in het groen op de velddata en steek de resterende energie in content.

Is het echt een rankingfactor?

Ja, en het is de moeite waard precies te zijn over hoeveel. Core Web Vitals horen bij Googles page experience-signalen. Ze zijn echt maar bescheiden vergeleken met relevantie en contentkwaliteit. Een snelle pagina over niets verslaat geen trage pagina die de vraag beantwoordt.

Waar snelheid werkelijk beslist, is tussen pagina's van vergelijkbare kwaliteit — en dat is bij de meeste competitieve zoekopdrachten het geval — en, veel belangrijker, in wat er ná de klik gebeurt. Snellere pagina's houden meer van de mensen die binnenkomen. Dat effect is veel groter dan het rankingeffect, en het geldt ongeacht of Google meekijkt.

De korte versie

Repareer je afbeeldingen, gooi het JavaScript weg dat je niet nodig hebt, render op de server, en reserveer ruimte voor alles wat laat laadt. Dat is het meeste werk. Meet daarna met velddata en stop als je in het groen zit, want wat je met dat volgende uur doet is meer waard dan nog twee punten.