Hoe je een Lighthouse-rapport leest zonder in paniek te raken

De eerste regel: je score is niet je site

Open voor het eerst een Lighthouse-rapport en je wordt geconfronteerd met een muur van cijfers, kleurgecodeerde vakken en waarschuwingen over dingen waar je nog nooit van hebt gehoord. De natuurlijke reactie is paniek. De score is rood. Er zijn zeventien mislukte audits. De site zal wel kapot zijn?

Waarschijnlijk niet. Lighthouse is een diagnostisch hulpmiddel, geen rapportcijfer. De score is een synthetische benchmark die onder laboratoriumomstandigheden wordt uitgevoerd — vaak op een vertraagde verbinding, met een simulatie van een middenklasse telefoon uit 2017. Het vertelt je hoe je site presteert in dat specifieke scenario, niet hoe echte gebruikers de site in de praktijk ervaren.

Dat is belangrijk, omdat de meeste teams zich blindstaren op de score en de context missen. Een score van 65 kan prima zijn voor een complexe webapp met realtime gegevens. Een score van 95 kan nog steeds een slechte ervaring opleveren als de verkeerde dingen zijn geoptimaliseerd. De score is een startpunt voor onderzoek, geen succesmetric.

Wat je eerst moet lezen: Core Web Vitals

Sla de algemene prestatiescore over. Scrol naar de sectie Metrics en kijk naar drie cijfers: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) en Interaction to Next Paint (INP). Dit zijn de Core Web Vitals, en dit zijn de enige prestatiemetrics die Google als rankingsignaal gebruikt.

• LCP meet hoe lang het duurt voordat het grootste zichtbare element wordt weergegeven. Doel: onder 2,5 seconden. Zit je boven 4 seconden, dan wachten gebruikers te lang voordat ze betekenisvolle content zien.
• CLS meet visuele stabiliteit — hoeveel de pagina verspringt tijdens het laden. Doel: onder 0,1. Zit je boven 0,25, dan klikken gebruikers per ongeluk op het verkeerde omdat knoppen zijn verschoven.
• INP meet responsiviteit — hoe snel de pagina reageert op klikken, tikken en toetsaanslagen. Doel: onder 200 ms. Zit je boven 500 ms, dan voelt de site traag aan.

Deze drie metrics correleren met echte gebruikersfrustratie. Los deze op voordat je je zorgen maakt over iets anders.

Mogelijkheden versus diagnostiek: ken het verschil

Lighthouse verdeelt bevindingen in twee categorieën: Mogelijkheden en Diagnostiek. Mogelijkheden worden gerangschikt op geschatte tijdsbesparing. Diagnostiek biedt extra context — dingen die problemen kunnen zijn, maar dat niet per se hoeven te zijn.

Begin met Mogelijkheden. Als Lighthouse zegt dat "Renderblokkerende resources elimineren" 1,2 seconden kan besparen, is dat een concrete winst. Als het zegt dat "Ongebruikte JavaScript verminderen" 0,1 seconden kan besparen, is het waarschijnlijk de refactor niet waard.

Diagnostiek is lastiger. "Vermijd een buitensporige DOM-grootte" klinkt slecht, maar als je CLS goed is en je INP snel, schaadt een grote DOM misschien niemand. Diagnostiek bestaat uit aanwijzingen, geen verplichtingen. Onderzoek de punten die aansluiten bij je daadwerkelijke metrics.

De audits die je meestal kunt negeren

Sommige Lighthouse-waarschuwingen zijn overgebleven uit het verleden of te agressief. Dit zijn de waarschuwingen die de meeste onnodige paniek veroorzaken:

• "Gebruikt geen passieve listeners om scrollprestaties te verbeteren" — Dit is een micro-optimalisatie die zelden veel verschil maakt. Tenzij je bewijs hebt van schokkerig scrollen, kun je dit overslaan.
• "Afbeeldingselementen hebben geen expliciete breedte en hoogte" — Dit is belangrijk voor CLS, maar alleen als afbeeldingen layout shifts veroorzaken. Als je CLS al goed is, refactor dan niet alleen voor de audit.
• "Afbeeldingen aanbieden in next-gen-indelingen" — Ja, WebP en AVIF zijn kleiner. Maar als je afbeeldingen al geoptimaliseerd zijn en je LCP snel is, is dit prettig om te hebben, geen crisis.
• "Vermijd enorme netwerkpayloads" — Lighthouse markeert alles boven 1,6 MB. Maar een pagina van 2 MB die snel laadt is beter dan een pagina van 500 KB die rendering blokkeert. Richt je op hoe de bytes worden geleverd, niet alleen op het totaal.

Wat je doet als alles rood is

Als je Lighthouse-score lager is dan 50 en de meeste audits mislukken, heb je waarschijnlijk te maken met een van drie hoofdoorzaken:

1. Niet-geoptimaliseerde fonts. Webfonts zijn nog steeds de eenvoudigste prestatiewinst op de meeste sites. Controleer of je zes fontgewichten laadt terwijl je er maar twee gebruikt, of dat je WOFF-bestanden levert in plaats van WOFF2.
2. Renderblokkerende CSS en JavaScript. Als je First Contentful Paint (FCP) boven 3 seconden ligt, blokkeert iets de browser om te schilderen. Zoek naar grote CSS-bestanden of synchrone scripts in de <head>.
3. Te grote afbeeldingen. Als je LCP-element een afbeelding is en die 4 MB groot is, is dat je probleem. Comprimeer de afbeelding, lazy-load afbeeldingen onder de vouw en gebruik syntaxis voor responsive images.

Los één van deze punten op en voer Lighthouse opnieuw uit. Vaak zie je een sprong van 20–30 punten. Pak daarna de volgende aan.

Labdata versus velddata: de realiteitscheck

Lighthouse draait in een lab. Het simuleert een trage verbinding en een traag apparaat, maar het kan echt gebruikersgedrag niet simuleren — hoe mensen scrollen, waarop ze klikken, of ze op instabiele Wi-Fi zitten.

Vergelijk je Lighthouse-resultaten voor een realiteitscheck met velddata uit het Chrome User Experience Report (CrUX). CrUX laat zien hoe echte Chrome-gebruikers je site de afgelopen 28 dagen hebben ervaren. Als Lighthouse zegt dat je LCP 4 seconden is, maar CrUX 2 seconden laat zien, vertrouw dan CrUX. Als ze allebei slecht zijn, heb je een echt probleem.

Je vindt CrUX-data in PageSpeed Insights (de webversie van Lighthouse) of in Google Search Console onder "Core Web Vitals." Als er een mismatch is, onderzoek dan waarom. Misschien zitten je echte gebruikers op snellere netwerken. Misschien test Lighthouse een niet-geoptimaliseerde dev-build.

Wanneer je Lighthouse opnieuw uitvoert

Lighthouse is ruisgevoelig. Voer het drie keer achter elkaar uit en je krijgt drie verschillende scores, zelfs op dezelfde pagina. Dat komt doordat prestaties variabel zijn — achtergrondprocessen, netwerkjitter en browserheuristiek beïnvloeden allemaal het resultaat.

Voor een stabiele baseline voer je Lighthouse uit in incognitomodus met alle extensies uitgeschakeld, of gebruik je de CLI met de vlag --preset=desktop voor consistentere resultaten. Voer het drie keer uit en neem het gemiddelde van de scores. Zie je grote schommelingen (meer dan 10 punten), dan is er iets anders mis — misschien is de server traag, of laadt de pagina telkens andere resources.

Voer Lighthouse opnieuw uit na elke belangrijke wijziging. Een nieuwe fontstrategie gedeployed? Controleer LCP. Afbeeldingen lazy-loaded? Controleer CLS. Een script van derden toegevoegd? Controleer INP. Performance is geen eenmalige fix; het is een budget dat je verdedigt.

De tools die je helpen om Lighthouse-bevindingen aan te pakken

Lighthouse vertelt je wat traag is. Het vertelt je niet altijd hoe je het oplost. Daarvoor heb je aanvullende tools nodig:

• WebPageTest geeft je een filmstripweergave van hoe de pagina laadt, frame voor frame. Essentieel voor het diagnosticeren van LCP- en CLS-problemen.
• Chrome DevTools Performance panel laat precies zien welke JavaScript de main thread blokkeert. Gebruik het om de bron van een slechte INP-score te vinden.
• Tools voor afbeeldingscompressie laten je afbeeldingen direct in de browser optimaliseren, wat sneller en privacyvriendelijker is dan uploaden naar een externe dienst. Client-side beeldverwerking is winst voor privacy, omdat je afbeeldingen je machine nooit verlaten.

Lighthouse is het startpunt. Deze tools helpen je de klus af te maken.

Belangrijkste punten

• Je Lighthouse-score is een labbenchmark, geen maatstaf voor de gebruikerservaring in de echte wereld. Vergelijk de score met velddata uit CrUX voordat je in paniek raakt.
• Focus eerst op Core Web Vitals (LCP, CLS, INP). Dit zijn de metrics die correleren met gebruikersfrustratie en SEO-impact.
• Prioriteer Mogelijkheden op basis van geschatte tijdsbesparing. Negeer Diagnostiek die niet aansluit bij je daadwerkelijke prestatieproblemen.
• Sommige audits — zoals passieve listeners of next-gen-afbeeldingsindelingen — zijn micro-optimalisaties. Los eerst de grote dingen op.
• Voer Lighthouse drie keer uit en neem het gemiddelde van de resultaten. Performance is variabel, en één enkele run kan misleidend zijn.

FAQ

Q: Waarom verandert mijn Lighthouse-score elke keer dat ik het uitvoer?
A: Lighthouse meet prestaties onder variabele omstandigheden — netwerksnelheid, CPU-belasting en browserheuristiek beïnvloeden allemaal het resultaat. Voer het drie keer uit in incognitomodus en neem het gemiddelde van de scores voor een stabielere baseline.

Q: Moet ik eerst voor mobiel of desktop optimaliseren?
A: Mobiel. Lighthouse gebruikt standaard een mobiele simulatie, omdat het meeste webverkeer mobiel is en mobiele apparaten langzamer zijn. Als je mobiele score goed is, is je desktopscore meestal ook in orde.

Q: Mijn Lighthouse-score is 95, maar mijn site voelt nog steeds traag. Wat is er mis?
A: Lighthouse meet paginalading, niet interactiviteit na het laden. Controleer je INP-score en gebruik het Chrome DevTools Performance panel om te profilen wat er gebeurt wanneer gebruikers klikken of scrollen. Misschien heb je een JavaScript-probleem dat Lighthouse niet detecteert.

Q: Heb ik een perfecte score van 100 nodig?
A: Nee. Een score van 90+ is uitstekend. Jagen op 100 betekent vaak dat je dingen optimaliseert die voor gebruikers niet belangrijk zijn. Focus op echte metrics — LCP, CLS, INP — en negeer de score.

Q: Kan ik Lighthouse vertrouwen als ik veel scripts van derden gebruik?
A: Lighthouse markeert scripts van derden als probleem, maar kan niet altijd onderscheid maken tussen noodzakelijke en onnodige scripts. Gebruik de audits "Vermijd enorme netwerkpayloads" en "JavaScript-uitvoeringstijd verminderen" om de grootste boosdoeners te identificeren, en beslis daarna of ze het waard zijn om te behouden.

Bronnen

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org