Je vult het webadres van je pagina in op pagespeed.web.dev en PageSpeed Insights geeft je pagina een oranje 62 of een rode 38. Dat getal is een labscore: Lighthouse laadt je pagina in een gesimuleerde omgeving en rekent daar een cijfer van 0 tot 100 uit. Het wijst aan waar je pagina traag is. Het zegt niet hoe echte bezoekers hem ervaren en ook niet waar je in Google staat.
Kijk daarom eerst naar de Core Web Vitals-beoordeling bovenaan de uitslag. Die rust op metingen bij echte Chrome-gebruikers over de afgelopen 28 dagen. Zakt je pagina daar op LCP, INP of CLS, dan weet je wat je eerste klus is. Staat daar alles op groen, dan is een oranje labscore een lijst met verbeterpunten en geen alarmsignaal.
Labdata en velddata in PageSpeed Insights
PageSpeed Insights zet twee soorten metingen in één uitslag. Elke soort beantwoordt een andere vraag (bron: About PageSpeed Insights, Google for Developers):
- Velddata komt uit het Chrome User Experience Report (CrUX): metingen bij echte bezoekers die Chrome gebruiken, over een periode van 28 dagen. Dit deel laat zien hoe je pagina het in de praktijk doet.
- Labdata komt uit Lighthouse. Die tool laadt je pagina onder vaste omstandigheden: voor mobiel met een middenklasse-telefoon op een mobiel netwerk, voor desktop met een bekabelde verbinding. Dit deel helpt je de oorzaak van een probleem te vinden.
Spreken de twee elkaar tegen, dan is dat geen fout in de tool. Velddata beschrijft hoe veel verschillende bezoekers je pagina op hun eigen toestel en verbinding hebben beleefd. Labdata is één laadbeurt op één toestel met één netwerkinstelling. Google waarschuwt dan ook dat een goede labscore niet automatisch betekent dat echte bezoekers een goede ervaring hebben.
Als er geen velddata verschijnt
Velddata verschijnt alleen voor openbare pagina’s met genoeg bezoeken van Chrome-gebruikers. Heeft je pagina die niet, dan toont PageSpeed Insights de cijfers van je hele domein, de zogenoemde origin. Zijn er ook voor het domein te weinig metingen, dan krijg je alleen labdata. Bij een nieuwe of rustige pagina is de labscore dus vaak het enige getal dat je ziet. Lees er dan niet meer in dan erin zit.
De prestatiescore van 0 tot 100 lezen
Het grote getal bovenaan het labdeel is de prestatiescore van Lighthouse. Lighthouse deelt die score in drie kleuren in (bron: Lighthouse performance scoring, Chrome for Developers):
|
Score |
Kleur |
Betekenis volgens Lighthouse |
|
0 tot en met 49 |
rood |
slecht |
|
50 tot en met 89 |
oranje |
moet beter |
|
90 tot en met 100 |
groen |
goed |
De score is een gewogen gemiddelde van vijf labmetingen. Lighthouse past die weging af en toe aan. Sinds Lighthouse 10 telt Total Blocking Time voor 30 procent en tellen Largest Contentful Paint en Cumulative Layout Shift elk voor 25 procent. First Contentful Paint en Speed Index tellen elk voor 10 procent. Een slechte waarde op Total Blocking Time drukt je score daardoor harder dan een slechte waarde op Speed Index. Kijk bij een oranje score dus welke van de vijf metingen rood of oranje staan en hoe zwaar die meetellen.
Draai je de test twee keer achter elkaar, dan kan de score verschillen zonder dat je iets hebt aangepast. Google noemt als oorzaken de beschikbaarheid van het netwerk en van de rekenkracht tijdens de test. Ook wisselende advertenties of A/B-tests op je pagina veranderen de uitkomst. Test daarom een paar keer voordat je conclusies trekt over een aanpassing.
Een score van 100 hoef je niet na te streven. Lighthouse schrijft zelf dat een perfecte score lastig te halen is en niet wordt verwacht: van 99 naar 100 vraagt ongeveer evenveel verbetering in de metingen als van 90 naar 94. De inzichten en diagnoses onder de score tellen ook niet direct mee in het getal. Een aanbeveling levert pas punten op als hij een van de vijf metingen verbetert.
Wanneer je slaagt voor de Core Web Vitals
De Core Web Vitals zijn drie metingen uit de velddata (bron: Understanding Core Web Vitals, Google Search Central):
- Largest Contentful Paint (LCP) meet hoe snel de grootste inhoud in beeld staat.
- Interaction to Next Paint (INP) meet hoe snel de pagina reageert als de bezoeker iets doet.
- Cumulative Layout Shift (CLS) meet hoe stabiel de pagina blijft, dus hoeveel inhoud verspringt terwijl je kijkt.
PageSpeed Insights toont per meting niet het gemiddelde maar het 75e percentiel. Driekwart van de bezoeken scoorde dus minstens zo goed als het getal dat je ziet. Google kiest die grens zodat een pagina ook goed werkt voor bezoekers met een trager toestel of een slechtere verbinding.
Je pagina slaagt als alle drie de metingen bij dat 75e percentiel in de groene zone vallen. Zijn er te weinig gegevens over INP, dan beslissen LCP en CLS samen. Ontbreekt LCP of CLS, dan krijg je geen beoordeling.
Verbeteren per metriek: drempel en eerste ingreep
De tabel zet per meting de grenzen uit de documentatie van PageSpeed Insights naast de ingreep die het Chrome-team als eerste aanraadt (bron: The most effective ways to improve Core Web Vitals, web.dev).
|
Metriek |
Goed |
Moet beter |
Slecht |
Eerste ingreep |
|
LCP |
tot en met 2,5 seconde |
tot en met 4 seconden |
boven 4 seconden |
Zet de grootste afbeelding direct in de HTML, geef hem voorrang met fetchpriority=”high” en haal lazy loading van die afbeelding af. |
|
INP |
tot en met 200 milliseconden |
tot en met 500 milliseconden |
boven 500 milliseconden |
Knip lange JavaScript-taken op en schrap scripts en tags die niets meer doen. |
|
CLS |
tot en met 0,1 |
tot en met 0,25 |
boven 0,25 |
Geef afbeeldingen een vaste breedte en hoogte en reserveer ruimte voor inhoud die later laadt. |
LCP: de grootste afbeelding sneller in beeld
Op bijna drie op de vier mobiele pagina’s is het grootste element een afbeelding, volgens de Web Almanac 2024 die web.dev aanhaalt. Pagina’s met een slechte LCP verliezen volgens het Chrome-team de meeste tijd vóór het downloaden: de browser ontdekt de afbeelding te laat. Staat je headerfoto alleen in een CSS- of JavaScript-bestand, dan vindt de browser hem pas als die bestanden binnen zijn. Reageert je server zelf traag (Time to First Byte), dan helpt een CDN dat je pagina’s vanaf een server dichter bij de bezoeker uitlevert.
INP: de browser vrijmaken voor klikken
Een taak die langer dan 50 milliseconden duurt, heet een lange taak. Zolang zo’n taak loopt, moet een klik of tik van de bezoeker wachten. Je verkort die wachttijd door minder JavaScript te laden en lange taken op te knippen, zodat de browser tussendoor op de bezoeker reageert. Gebruik je een tagmanager, loop de tags dan na en haal oude tags met ongebruikte code weg.
CLS: ruimte reserveren voordat inhoud laadt
Inhoud verspringt meestal doordat iets later laadt en de rest opzij duwt. Een afbeelding zonder breedte en hoogte begint met een hoogte van 0 pixels en schuift de tekst omlaag zodra hij binnenkomt. Geef afbeeldingen daarom vaste afmetingen en geef vakken voor advertenties of video’s een minimale hoogte. Let ook op cookiebanners die de pagina in schuiven: een animatie die de opmaak verandert, telt mee in CLS.
Wat de score wel en niet zegt over je vindbaarheid
De rankingsystemen van Google Search gebruiken de Core Web Vitals. Google raadt website-eigenaren aan om die op orde te hebben (bron: Understanding page experience, Google Search Central). Op dezelfde pagina staat dat goede uitkomsten geen garantie zijn voor een plek bovenaan. Volgens Google is een perfecte score najagen alleen voor SEO waarschijnlijk niet de beste besteding van je tijd.
Let ook op wat je meet. De Core Web Vitals beschrijven volgens Google de ervaring van echte gebruikers, terwijl de prestatiescore van 0 tot 100 een labmeting is. Voor SEO kijk je dus naar de velddata en gebruik je de labscore om oorzaken te vinden.
Snelheid hoort bij de techniek, een van de drie pijlers van SEO naast content en autoriteit. Google toont altijd de meest relevante inhoud, ook als de paginabeleving tegenvalt. Bij zoekopdrachten met veel bruikbare antwoorden kan een goede paginabeleving meewegen. Voor je zichtbaarheid in Google weegt relevante inhoud dus zwaarder dan een paar punten extra in PageSpeed Insights.
PageSpeed Insights meet hoe je pagina laadt en reageert, niet hoe vaak hij gevonden wordt. Voor die vraag gebruik je andere Google SEO tools.
Waar je als eerste begint
Met een oranje of rode score op je scherm werk je in deze volgorde:
- Test eerst de pagina’s waar de meeste bezoekers binnenkomen. Welke dat zijn, lees je af in Google Analytics.
- Lees de Core Web Vitals-beoordeling. Zakt de pagina, werk dan aan de meting die rood of oranje staat, met de ingreep uit de tabel hierboven.
- Is er geen velddata, gebruik dan de labdata en begin bij de metingen die het zwaarst wegen: Total Blocking Time, LCP en CLS.
- Test na een aanpassing een paar keer in het labdeel. Het volle effect in de velddata zie je pas als de periode van 28 dagen helemaal na je wijziging valt.
- Stop met schaven zodra de Core Web Vitals groen zijn. De laatste punten richting 100 kosten volgens Lighthouse onevenredig veel werk.