Lighthouse is het open-source auditgereedschap van Google dat een webpagina automatisch beoordeelt op performance, toegankelijkheid, best practices en SEO. Toch werpen de meeste mensen één blik op die ronde performancescore en raken in paniek. De score is slechts een samenvatting van het echte verhaal. In dit artikel laat ik je zien hoe je het rapport echt leest, welke metingen de gebruikerservaring werkelijk bepalen, en hoe je de knelpunten die je vindt stap voor stap oplost.
Een Lighthouse-rapport uitvoeren
Er zijn meerdere manieren om Lighthouse te bereiken; de juiste keuze is die welke past bij jouw situatie:
- Chrome DevTools > tabblad Lighthouse: snel, visueel en lokaal uitgevoerd. Het nadeel is dat de CPU en het netwerk van je machine het resultaat beïnvloeden.
- PageSpeed Insights (pagespeed.web.dev): gebruikt dezelfde engine maar draait op de servers van Google en toont ook data van echte gebruikers (CrUX / Field Data).
- CLI: ideaal voor automatisering. Het commando
npx lighthouse https://aslain.dev --viewgenereert het rapport en opent het in de browser.
Een belangrijk punt: meet altijd in een incognitovenster met extensies uitgeschakeld. Adblockers en andere add-ons injecteren code in de pagina en vertekenen de score. Vertrouw ook niet op één meting; performance is variabel, dus voer hem 3 tot 5 keer uit en kijk naar de mediaan.
Labdata of velddata?
Lighthouse biedt twee soorten data, en die door elkaar halen is de meest gemaakte fout. Labdata (DevTools/Lighthouse) meet één enkele laadbeurt in een gecontroleerde, gesimuleerde omgeving; reproduceerbaar maar kunstmatig. Velddata (Core Web Vitals) zijn geanonimiseerde metingen die via Chrome zijn verzameld van gebruikers die je site de afgelopen 28 dagen daadwerkelijk bezochten. Het is de velddata waar Google rekening mee houdt voor de ranking. Dus zelfs als je labscore 100 is, betekent slechte velddata dat het echte probleem nog niet is opgelost.
Welke metingen ertoe doen: LCP, CLS en TBT
De performancescore is een gewogen gemiddelde; deze metingen leveren de grootste bijdrage:
- LCP (Largest Contentful Paint): hoe lang het grootste zichtbare element (meestal de hero-afbeelding of de kop) nodig heeft om te renderen. Doel: onder
2,5 s. - CLS (Cumulative Layout Shift): onverwachte verschuiving van elementen tijdens het laden. Doel: onder
0,1. - TBT (Total Blocking Time): hoe lang de hoofdthread door JavaScript geblokkeerd is voor gebruikersinteractie. De veldtegenhanger is INP. Doel: onder
200 ms. - FCP en Speed Index: de snelheid van de eerste inhoud en van de visuele opbouw.
Lees de kleur naast elke meting (groen/oranje/rood) samen met de secties "Opportunities" en "Diagnostics". Het zijn deze punten, niet de score zelf, die je vertellen wat je moet doen.
Het LCP-knelpunt oplossen
LCP komt meestal voort uit een grote afbeelding of een te laat geladen webfont. Praktische stappen:
- Converteer de hero-afbeelding naar een modern formaat (WebP/AVIF) en serveer hem in de juiste grootte. Stuur geen afbeelding van 3000px breed naar een vak van 800px.
- Geef de browser een hint zodat hij de kritieke afbeelding vroeg ontdekt:
<link rel="preload" as="image"
href="/img/hero.avif"
fetchpriority="high">Gebruik voor fonts font-display: swap zodat de tekst niet onzichtbaar blijft terwijl het font downloadt. De serverresponstijd (TTFB) beïnvloedt LCP ook rechtstreeks; cache zware queries en gebruik waar mogelijk een CDN. Deze paar punten hebben doorgaans een grote impact, maar de volgorde verschilt per site — open het LCP-element waar het rapport naar wijst en zoek de echte oorzaak.
CLS en TBT verlagen
Voor CLS luidt de gulden regel: reserveer vooraf ruimte voor elk element. Voeg width- en height-attributen toe aan afbeeldingen (de browser berekent de verhouding en reserveert ruimte), geef advertentie-/embedvakken een vaste hoogte en vermijd late banners die de inhoud naar beneden duwen. Om verschuiving door webfonts te beperken, helpen size-adjust en een afgestemd fallback-font.
TBT is vrijwel altijd een overdaad aan JavaScript. Wat te doen:
- Verwijder ongebruikte JS; neem de waarschuwing "Reduce unused JavaScript" serieus.
- Laad scripts van derden (analytics, chat, advertenties) met
asyncofdefer, en stel ze uit tot na de interactie waar mogelijk. - Splits grote bundles op met code splitting; verstuur alleen de code die elke pagina nodig heeft.
<script src="/js/app.js" defer></script>
<script src="https://analytics.example.com/s.js" async></script>De audit tot gewoonte maken
Performance is geen eenmalige klus; elke deploy kan een nieuwe afbeelding of script introduceren die een regressie veroorzaakt. Voeg Lighthouse daarom toe aan je CI-pipeline. Met Lighthouse CI stel je budgetten in op elke pull request en breek je de build als de score daalt. Zo wordt "waarom is de site trager geworden?" beantwoord tijdens de code review, voordat een gebruiker klaagt. In plaats van de score na te jagen, jaag de gebruiker na: test op echte apparaten onder echte netwerkomstandigheden.
Veelgestelde vragen
Waarom verandert mijn Lighthouse-score elke keer?
Omdat de labmeting wordt beïnvloed door de huidige CPU-belasting van je machine, de netwerkomstandigheden en achtergrondprocessen. Daarom is 3 tot 5 metingen nemen in een incognitovenster en de mediaan gebruiken veel gezonder dan vertrouwen op één enkele score.
Moet ik per se 100 halen?
Nee. 100 is een mooi doel, maar wat echt telt is het halen van de Core Web Vitals-drempels (LCP < 2,5 s, CLS < 0,1, INP < 200 ms) in de velddata. Een site met 92 en "goede" velddata is beter dan een site met 99 en slechte velddata.
Waarom verschillen mobiele en desktopscores zo sterk?
Lighthouse simuleert in de mobiele test een traag apparaat en een afgeknepen netwerk. Omdat de meeste van je gebruikers mobiel komen, moet je eerst de mobiele score verbeteren.
Wil je de performance van je site serieus nemen? We kunnen je Lighthouse-rapport samen lezen en de LCP-, CLS- en TBT-knelpunten definitief oplossen. Neem contact met me op en laten we beginnen met de snelheidsanalyse van je site.