Laadsnelheid uitgelegd: wat de Core Web Vitals over je website zeggen

In het kort: de Core Web Vitals meten drie dingen: hoe snel het belangrijkste deel van een pagina verschijnt (LCP), hoe snel ze reageert op een klik of tik (INP) en hoeveel ze verspringt tijdens het laden (CLS). Test je website met PageSpeed Insights. Te grote beelden, te veel scripts en trage hosting zijn de gewone verdachten.

Waarom laadsnelheid ertoe doet

Een trage website kost geduld, en geduld is schaars bij iemand die op zijn telefoon snel een bakker, kapper of loodgieter zoekt. Wie te lang naar een leeg scherm kijkt, gaat terug naar de zoekresultaten en klikt op de volgende.

Ook Google kijkt mee. Volgens Google Search Central worden de Core Web Vitals gebruikt door de systemen die zoekresultaten rangschikken. Tegelijk zegt Google dat het altijd eerst de meest relevante inhoud toont, ook als een pagina minder vlot laadt. Snelheid is dus geen vervanging voor goede inhoud, maar wel een voordeel bovenop.

De drie metingen

Google beschrijft de Core Web Vitals op web.dev. Dit zijn de grenzen voor een goede score:

Google kijkt niet naar één bezoek, maar naar 75% van de bezoeken, apart voor mobiel en desktop. Een pagina scoort goed als minstens drie op de vier bezoeken binnen de grens blijven.

INP is de jongste van de drie. Sinds 2024 vervangt ze de oudere meting First Input Delay. Kom je in oudere artikels FID tegen, dan weet je waarom.

LCP: verschijnt het belangrijkste snel?

LCP meet het moment waarop het grootste stuk inhoud zichtbaar is. Op de meeste websites is dat de grote foto bovenaan, of de titel als er geen foto staat.

Veelvoorkomende oorzaken van een trage LCP:

• een hoofdfoto die veel groter is dan nodig, bijvoorbeeld rechtstreeks van een camera;
• een server die traag antwoordt, zodat alles later begint;
• lettertypes, stijlen of scripts die eerst geladen moeten worden voor de pagina iets toont;
• een foto die pas geladen wordt nadat een script ze inlaadt.

INP: reageert de pagina meteen?

INP gaat over het gevoel van een website. Tik je op een menu en duurt het een halve seconde voor het opent, dan voelt de website stroef, ook al was ze snel geladen.

De oorzaak is bijna altijd JavaScript dat de browser bezighoudt. Denk aan zware sliders, chatvensters, trackingcodes, advertentiescripts en paginabouwers die veel code meesturen. Elk script afzonderlijk lijkt onschuldig, samen leggen ze de browser lam.

CLS: blijft alles op zijn plaats?

Je wilt op een knop tikken, er schuift net een banner boven en je tikt op iets anders. Dat is wat CLS meet.

Typische oorzaken:

• foto’s en video’s zonder vaste afmetingen, waardoor de browser pas achteraf weet hoeveel ruimte ze innemen;
• banners of meldingen die bovenaan de inhoud naar beneden duwen;
• lettertypes die laat laden en de tekst van grootte doen veranderen;
• ingesloten inhoud, zoals een kaart of een sociale-mediapost, zonder vaste ruimte.

Een cookiemelding die over de pagina zweeft, verschuift niets. Een melding die de pagina naar beneden duwt, wel.

Zo meet je je eigen website

PageSpeed Insights (pagespeed.web.dev) is het eenvoudigste vertrekpunt. Vul je adres in en je krijgt twee soorten resultaten:

• Gegevens van echte bezoekers. Die komen uit Chrome en tonen hoe je website het doet bij mensen die ze echt bezoeken. Kleine websites hebben vaak te weinig bezoekers om hier cijfers te krijgen. Dat is normaal.
• Een labotest. Een gesimuleerd bezoek met een vaste telefoon en verbinding. Handig om problemen te vinden, maar het is geen meting van echte bezoeken. INP kan een labotest niet meten, omdat niemand klikt. In de plaats daarvan toont ze de Total Blocking Time, een benadering.

Google Search Console heeft een rapport Core Web Vitals. Het toont welke groepen pagina’s goed scoren of verbetering nodig hebben, op basis van echte bezoeken. Heb je Search Console nog niet ingesteld, dan is dat sowieso een goed idee.

Test altijd de mobiele versie. Die is strenger, en ze is wat de meeste bezoekers van een lokale zaak zien.

Wat je zelf kunt doen

Je hoeft geen ontwikkelaar te zijn om een groot deel van de winst te halen.

1. Verklein je foto’s. Een foto voor een website hoeft zelden breder te zijn dan 2000 pixels. Moderne formaten als WebP of AVIF zijn veel lichter dan JPG of PNG.
2. Ruim scripts op. Gebruik je dat chatvenster, die trackingcode of die oude advertentiepixel nog? Wat niet nodig is, gaat eruit.
3. Wees zuinig met video. Een ingesloten video laadt veel code mee. Toon eerst een afbeelding en laad de video pas als iemand op afspelen klikt.
4. Gebruik weinig lettertypes. Elke extra variant is een extra bestand.
5. Kijk naar je hosting. Is de eerste reactie van je server traag, dan helpt optimaliseren aan de pagina maar beperkt. Een CDN of betere hosting maakt dan meer verschil. Meer daarover in Hosting uitgelegd zonder vakjargon.
6. Beperk plugins. Bij WordPress laadt elke plugin vaak eigen bestanden mee, ook op pagina’s waar ze niets doet.

Hoe deze website het aanpakt

Bij anseric.be maakt de bouw van elke foto automatisch kleinere versies in WebP, in verschillende breedtes. De browser kiest de versie die past bij het scherm. Elke foto heeft vaste afmetingen, zodat er niets verspringt. En omdat de pagina’s statisch zijn, kan de server ze meteen versturen. Waarom dat zoveel uitmaakt, lees je in Waarom een statische website sneller en veiliger is.

Een perfecte score is geen doel

Een 100 in PageSpeed Insights ziet er mooi uit, maar het is geen doel op zich. Google schrijft zelf dat een goede score geen topplaats garandeert, en dat jagen op perfecte scores alleen voor zoekmachines niet de beste besteding van je tijd is.

Gebruik de cijfers als thermometer. Zit je in het groen, besteed je tijd dan aan betere teksten, foto’s en een duidelijke volgende stap. Zit je in het rood, dan weet je waar je moet beginnen.