Google Lighthouse-score uitgelegd: wat betekenen de belangrijkste metrics?

Bij Ninjible is performance een belangrijk uitgangspunt bij het ontwikkelen van websites en digitale platforms. Niet om koste wat kost een perfecte score van 100 te behalen, maar omdat een snelle, stabiele en responsieve website bijdraagt aan een betere gebruikerservaring.

Wat is Google Lighthouse?

Google Lighthouse is een open-source tool waarmee je automatisch verschillende onderdelen van een webpagina kunt testen. Lighthouse kijkt onder andere naar:

• performance;
• accessibility;
• best practices;
• SEO.

Voor ieder onderdeel krijg je een score en aanbevelingen voor mogelijke verbeteringen. Je kunt Lighthouse onder andere uitvoeren vanuit Chrome DevTools. Ook Google PageSpeed Insights gebruikt Lighthouse voor de technische analyse van een pagina.

Wat betekent de Lighthouse Performance-score?

De bekende Performance-score loopt van 0 tot 100. Volgens de documentatie van Chrome for Developers over Lighthouse-scoring worden de scores als volgt ingedeeld:

• 90–100: goed;
• 50–89: verbetering mogelijk;
• 0–49: slecht.

De Performance-score is niet gebaseerd op één meting. Lighthouse combineert verschillende metrics in een gewogen gemiddelde. Sommige metrics hebben daardoor meer invloed op de uiteindelijke score dan andere.

De Performance-score wordt opgebouwd uit vijf belangrijke metrics:

• First Contentful Paint (FCP): 10%;
• Speed Index: 10%;
• Largest Contentful Paint (LCP): 25%;
• Total Blocking Time (TBT): 30%;
• Cumulative Layout Shift (CLS): 25%.

Deze wegingspercentages laten zien waarom één technisch probleem relatief veel invloed kan hebben op de totaalscore. Vooral een hoge Total Blocking Time, een trage Largest Contentful Paint of veel onverwachte verschuivingen kunnen zwaar meewegen.

1. First Contentful Paint (FCP): wanneer verschijnt de eerste content?

First Contentful Paint (FCP) meet hoe lang het duurt voordat de browser het eerste stukje content uit het Document Object Model, oftewel de DOM, op het scherm toont. Dat kan bijvoorbeeld tekst, een afbeelding, een SVG-element of een niet-wit canvas-element zijn.

FCP zegt vooral iets over de eerste indruk van snelheid. Een bezoeker heeft een pagina geopend en wil zo snel mogelijk bevestiging krijgen dat er daadwerkelijk iets gebeurt. Een leeg wit scherm van enkele seconden voelt veel trager dan een pagina waarop vrijwel direct content verschijnt.

Voor mobiele Lighthouse-tests geldt een FCP van maximaal 1,8 seconden als goed. Op desktop hanteert Lighthouse strengere grenzen. Het is daarom verstandig om bij het vergelijken van tests altijd te controleren of je naar de mobiele of desktopmeting kijkt.

FCP vertelt niet het hele verhaal. Dat het eerste stukje content zichtbaar is, betekent namelijk nog niet dat de belangrijkste inhoud van de pagina is geladen. Daarvoor kijken we naar LCP.

2. Largest Contentful Paint (LCP): wanneer is de belangrijkste content zichtbaar?

Largest Contentful Paint (LCP) meet wanneer het grootste zichtbare contentelement binnen de viewport op het scherm wordt weergegeven. Dat kan bijvoorbeeld zijn:

• een grote headerafbeelding;
• een hero-afbeelding;
• een prominent tekstblok;
• een grote afbeelding binnen het zichtbare deel van de pagina.

LCP komt daardoor vaak dichter in de buurt van het moment waarop een gebruiker denkt: de pagina is geladen.

Google beschouwt een LCP van maximaal 2,5 seconden als goed. Voor deze en andere Core Web Vitals kijkt Google bij praktijkdata naar het 75e percentiel van de gemeten paginaweergaven. Dat betekent dat minimaal 75% van de bezoeken binnen de aanbevolen grens moet vallen.

Is je LCP te hoog? Dan kunnen onder andere grote afbeeldingen, een trage serverreactie, render-blocking stylesheets, webfonts, client-side rendering of inefficiënt geladen resources een rol spelen.

3. Speed Index: hoe snel wordt de pagina zichtbaar?

Speed Index meet hoe snel de zichtbare inhoud van een pagina tijdens het laden wordt weergegeven. Lighthouse maakt hiervoor een visuele opname van het laadproces en berekent hoe snel de pagina zich beeld voor beeld vult.

Stel dat twee websites allebei na drie seconden volledig zichtbaar zijn. Website A laat gedurende die drie seconden steeds meer bruikbare content zien. Website B blijft vrijwel helemaal leeg en verschijnt vervolgens in één keer. Hoewel de totale laadtijd vergelijkbaar kan zijn, zal website A voor een gebruiker waarschijnlijk sneller aanvoelen.

Speed Index helpt dat verschil inzichtelijk te maken. Hoe lager de Speed Index, hoe sneller de zichtbare inhoud van de pagina wordt opgebouwd. Voor een mobiele Lighthouse-test geldt een Speed Index tot 3,4 seconden als goed. Voor desktoptests wordt een strengere grens gehanteerd.

4. Total Blocking Time (TBT): hoe lang kan de pagina niet goed reageren?

Een website kan er volledig geladen uitzien en toch traag reageren. Je klikt bijvoorbeeld op een knop, maar er gebeurt even niets. Total Blocking Time (TBT) meet hoeveel tijd de main thread tijdens het laden wordt geblokkeerd.

Lighthouse kijkt daarbij naar langdurige taken tussen First Contentful Paint en Time to Interactive. Een taak geldt als langdurig wanneer deze langer dan 50 milliseconden duurt. Alleen het gedeelte boven die 50 milliseconden telt mee als blocking time.

Een taak van 70 milliseconden levert dus 20 milliseconden blocking time op. Lighthouse telt de blocking time van alle langdurige taken bij elkaar op om de TBT te berekenen.

Deze blokkades worden vaak veroorzaakt door JavaScript. Wanneer de browser bezig is met een zware taak, kan hij ondertussen niet direct reageren op klikken, tikken of toetsenbordinvoer. Een hoge TBT kan er daardoor voor zorgen dat een website traag of stroperig aanvoelt, zelfs wanneer de content al zichtbaar is.

Voor mobiele Lighthouse-tests wordt een TBT van maximaal 200 milliseconden als goed beschouwd. Binnen de Performance-score heeft TBT met een weging van 30% veel invloed op het eindresultaat.

5. Cumulative Layout Shift (CLS): blijft de pagina stabiel?

Ken je dit? Je wilt op een knop klikken, maar precies op dat moment verschijnt er een afbeelding boven de knop en schuift alles naar beneden. Vervolgens klik je per ongeluk ergens anders op. Dat is een voorbeeld van een layout shift.

Cumulative Layout Shift (CLS) meet onverwachte verschuivingen van zichtbare elementen. Veel of grote verschuivingen zorgen voor een onrustige en frustrerende gebruikerservaring.

Een goede CLS-score is volgens Google 0,1 of lager. Mogelijke oorzaken van een slechte CLS-score zijn:

• afbeeldingen en video’s zonder vooraf ingestelde afmetingen;
• advertenties of embeds die later ruimte innemen;
• webfonts die zichtbaar van formaat veranderen;
• content die dynamisch boven bestaande content wordt geplaatst;
• widgets van externe partijen die tijdens het laden van formaat veranderen.

CLS kan zowel in een gecontroleerde testomgeving als bij echte gebruikers worden gemeten. Een labtest ziet echter meestal alleen de verschuivingen die tijdens het laden plaatsvinden. Field data kan ook verschuivingen registreren die later tijdens het bezoek ontstaan.

Lighthouse-score en Core Web Vitals zijn niet hetzelfde

Hier ontstaat regelmatig verwarring. Een Lighthouse Performance-score van 100 betekent niet automatisch dat je website in de praktijk voor iedere gebruiker perfect presteert.

Lighthouse voert een labtest uit. De pagina wordt onder gecontroleerde en gesimuleerde omstandigheden geladen en op basis daarvan geanalyseerd. Dat maakt Lighthouse vooral geschikt om technische problemen op te sporen en verschillende metingen met elkaar te vergelijken.

Core Web Vitals zijn metrics die de gebruikerservaring rond laadsnelheid, responsiviteit en visuele stabiliteit beoordelen. Ze kunnen met labtools worden onderzocht, maar voor een representatief beeld gebruikt Google ook field data van echte Chrome-gebruikers.

De drie huidige Core Web Vitals zijn:

• Largest Contentful Paint (LCP): meet laadperformance;
• Interaction to Next Paint (INP): meet de responsiviteit bij interacties;
• Cumulative Layout Shift (CLS): meet visuele stabiliteit.

Voor een goede gebruikerservaring gelden de volgende richtlijnen:

• LCP: maximaal 2,5 seconden;
• INP: maximaal 200 milliseconden;
• CLS: maximaal 0,1.

Google beoordeelt deze waarden aan de hand van het 75e percentiel van de paginaweergaven, afzonderlijk voor mobiele apparaten en desktops. Zo moet een goede score representatief zijn voor het grootste deel van de gebruikers en niet alleen voor bezoekers met een snel apparaat en een snelle internetverbinding.

Waarom staat INP niet tussen de Lighthouse-metrics?

Interaction to Next Paint is een belangrijke Core Web Vital, maar staat niet als afzonderlijke metric in de standaard Lighthouse Performance-score. Dat komt doordat INP de reactiesnelheid beoordeelt op basis van interacties die gedurende het volledige bezoek plaatsvinden.

Een standaard Lighthouse-test analyseert voornamelijk het laden van een pagina en beschikt niet over dezelfde reeks echte gebruikersinteracties. Daarom rapporteert Lighthouse Total Blocking Time als labmetric voor responsiviteitsproblemen tijdens het laden.

Volgens Googles uitleg over Core Web Vitals meten met Google-tools kan TBT helpen bij het opsporen van problemen die ook INP negatief kunnen beïnvloeden. Denk bijvoorbeeld aan grote hoeveelheden JavaScript en langdurige taken op de main thread.

TBT en INP zijn echter niet hetzelfde. Een lage TBT garandeert niet automatisch een goede INP. Trage interacties kunnen ook optreden nadat de pagina volledig is geladen. Voor een compleet beeld wil je daarom zowel labdata als praktijkdata onderzoeken.

Lighthouse versus PageSpeed Insights: wat is het verschil?

Lighthouse en PageSpeed Insights worden regelmatig door elkaar gehaald. Lighthouse is de onderliggende analysetool voor de technische labtest. Google PageSpeed Insights kan twee soorten informatie combineren:

1. Field data: praktijkgegevens uit het Chrome User Experience Report, ook wel CrUX genoemd. Deze gegevens zijn gebaseerd op echte Chrome-gebruikers en bestrijken de voorgaande periode van 28 dagen.
2. Lab data: een Lighthouse-test onder gesimuleerde omstandigheden waarmee technische problemen kunnen worden opgespoord.

Field data is alleen beschikbaar wanneer Google voldoende praktijkgegevens voor een pagina of website heeft verzameld. Bij websites met weinig verkeer kan deze informatie ontbreken of alleen op domeinniveau beschikbaar zijn.

Het onderscheid tussen lab- en field data is belangrijk. Een Lighthouse-test vertelt je vooral welke technische verbeterpunten tijdens de test naar voren komen. Field data laat zien wat echte gebruikers met verschillende apparaten, verbindingen en omstandigheden daadwerkelijk ervaren.

Voor een goed beeld van websiteperformance wil je daarom naar beide kijken.

Is een Lighthouse-score van 100 nodig?

Nee. Een perfecte Lighthouse-score kan mooi zijn, maar moet niet het doel op zichzelf worden.

Scores kunnen bovendien per meting variëren. Volgens Chrome for Developers kunnen onder meer verschillende apparaten, netwerkroutes, browserextensies, advertenties en andere wisselende omstandigheden invloed hebben op de uitkomst.

Een website met een score van 95 is daarom niet automatisch beter dan een website met een score van 90. Belangrijker is dat de website voor echte gebruikers snel, stabiel en responsief is en dat belangrijke functionaliteiten goed blijven werken.

Gebruik Lighthouse vooral als diagnostisch hulpmiddel. Het helpt developers om technische bottlenecks te vinden, verbeteringen te testen en regressies tijdens de ontwikkeling sneller te signaleren. Combineer die inzichten met Core Web Vitals uit de praktijk en met observaties van echte gebruikers.

Een snelle website begint bij technische keuzes

Een goede Lighthouse-score bereik je niet alleen door aan het einde van een project een paar afbeeldingen te comprimeren. Performance wordt al veel eerder bepaald.

Denk aan keuzes rondom:

• technische architectuur;
• front-endcode;
• JavaScript;
• afbeeldingen en fonts;
• caching;
• hosting en infrastructuur;
• externe scripts;
• API’s;
• databases;
• de manier waarop content wordt geladen.

Daarom behandelen we performance bij Ninjible als onderdeel van het volledige ontwikkelproces. We kijken niet alleen naar een eindscore, maar naar de technische keuzes die bepalen hoe een website of digitaal platform zich in de praktijk gedraagt.

Het uiteindelijke doel is niet een groen bolletje of een score van 100. Het doel is een website of digitaal platform dat voor echte gebruikers snel aanvoelt, stabiel blijft en prettig reageert. Lighthouse helpt ons om technische verbeterpunten zichtbaar en meetbaar te maken.