PageSpeed Insights lezen: Core Web Vitals in gewone taal
Je hebt je website getest in PageSpeed Insights en ziet een rood getal, bijvoorbeeld 45. Wat betekent dat, en hoe erg is het? In dit artikel lees je hoe je het rapport leest, wat de drie Core Web Vitals meten en wat je zelf kunt verbeteren.
De drie metingen
| Meting | Wat het meet | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Hoe snel het grootste stuk inhoud in beeld staat, vaak de grote foto bovenaan | tot 2,5 s | 2,5 tot 4 s | boven 4 s |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert als je klikt, tikt of typt | tot 200 ms | 200 tot 500 ms | boven 500 ms |
| CLS (Cumulative Layout Shift) | Hoeveel de pagina verspringt tijdens het laden (een score, geen tijd) | tot 0,1 | 0,1 tot 0,25 | boven 0,25 |
Een pagina haalt de Core Web Vitals als minstens 75 procent van de bezoeken goed scoort op alle drie, apart voor mobiel en desktop. Niet jouw snelle computer telt dus, maar de ervaring van de meeste bezoekers, ook op een oudere telefoon. INP heeft in maart 2024 de oudere meting FID vervangen. Kom je FID nog tegen, dan is die informatie verouderd.
Velddata en labdata
PageSpeed Insights toont twee soorten metingen, en die geven vaak verschillende getallen:
- Velddata (bovenaan): metingen bij echte bezoekers met Chrome over de afgelopen 28 dagen. Dit bepaalt of je de Core Web Vitals haalt. Heeft je pagina te weinig bezoekers, dan zie je de cijfers van je hele site, of helemaal geen velddata.
- Labdata (daaronder): een test met Lighthouse, die de pagina één keer laadt op een nagebootste middelmatige telefoon en verbinding. Hier komt het getal van 0 tot 100 vandaan. Lighthouse kan geen INP meten, want er klikt niemand.
Gebruik de labdata om oorzaken te vinden en om na een verbetering meteen te zien of het helpt. Begin bij het tabblad Mobiel: daar is het meestal slechter, en Google kijkt vooral naar de mobiele versie van je site.
Hoe zwaar weegt het in Google?
Google schrijft dat de Core Web Vitals meetellen bij het rangschikken. Maar Google laat altijd de meest relevante inhoud zien, ook als die pagina niet de snelste is. Het getal van 0 tot 100 komt uit de labtest en is geen beoordeling door Google; die beoordeling komt uit de velddata. Een perfecte score halen alleen voor Google is volgens Google zelf niet de beste besteding van je tijd. Zorg dat je in het groene of op zijn minst het oranje gebied zit, vooral omdat bezoekers afhaken op een trage of verspringende pagina.
Wat je in de pagina zelf verbetert
- Kleinere afbeeldingen. Een foto van duizenden pixels breed voor een vak van 800 pixels is de meest voorkomende oorzaak van een trage LCP. Verklein foto's vóór het uploaden en gebruik een modern formaat als WebP of AVIF.
- Breedte en hoogte bij elke afbeelding. Zonder
widthenheightweet de browser niet hoeveel ruimte een foto nodig heeft, en verspringt de tekst als hij binnenkomt. Dat verhoogt de CLS:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
- De belangrijkste foto niet lui laden.
loading="lazy"is goed voor foto's verderop, maar niet voor de foto die bij het openen al in beeld is. Anders wacht de browser juist met de foto die je LCP bepaalt. - Niets later boven de inhoud invoegen. Een cookiebalk, advertentie of widget die de pagina naar beneden duwt, laat alles verspringen. Laat zo'n balk liever over de pagina heen liggen.
- Minder scripts van anderen. Een slechte INP komt bijna altijd door te veel JavaScript: zware thema's, sliders, chatvensters en trackers. Kijk kritisch naar elke plugin of ingesloten dienst.
Wat de server doet
Alles begint met de eerste reactie van de server, de Time to First Byte (TTFB). Die is zelf geen Core Web Vital, maar met een trage eerste reactie is een goede LCP bijna onmogelijk. Als richtwaarde is 0,8 seconde of minder goed. Oorzaken zijn vaak een site zonder cache, te weinig rekenkracht of doorsturingen. De server hoort tekstbestanden ook ingepakt te versturen (compressie met gzip of Brotli). Hoe je de serverkant aanpakt, lees je in Mijn website is traag of gebruikt te veel CPU: zo maak je hem sneller en in de DirectAdmin-handleiding, Mijn website is traag.
In de AI Builder en WordPress
Een site van de AI Builder zet breedte en hoogte bij afbeeldingen waarvan de maat bekend is, laadt de eerste foto van een pagina direct en met voorrang en de rest pas als ze in beeld komen, en maakt bij het publiceren een kleinere versie van grote foto's. In WordPress helpen een cacheplugin en het verkleinen van afbeeldingen het meest. Dat lees je in de gratis WordPress-cursus, lessen Wat maakt een site traag, en hoe meet je het? en Afbeeldingen, PHP en andere snelheidswinst.
Verder lezen
- web.dev: Web Vitals (Engels)
- Over PageSpeed Insights (Engels)
- Google: pagina-ervaring en Google Zoeken (Engels)
- Google: het rapport Site-vitaliteit