Google Lighthouse | complete gids voor audits, interpretatie en fixes

Google Lighthouse is een gratis audittool van Google waarmee je snel ziet hoe goed een pagina scoort op snelheid, toegankelijkheid, technische kwaliteit en basis-SEO. Je gebruikt het om knelpunten zoals trage afbeeldingen, zware scripts, layout shifts en serververtraging op te sporen, zodat je gericht kunt verbeteren. Het werkt in Chrome DevTools, via een command line-tool, in PageSpeed Insights en geautomatiseerd in CI/CD. Het belangrijkste is niet alleen de score, maar vooral welke audits en metrics erachter zitten. In deze gids leer je hoe je de tool gebruikt, resultaten interpreteert en omzet in concrete acties.

• Je ontdekt wat de tool meet binnen performance, accessibility, best practices, SEO en PWA.
• Je leert het verschil tussen testdata uit een gecontroleerde omgeving en echte gebruikersdata.
• Je ziet hoe je audits draait via DevTools, de command line, PageSpeed Insights en CI.
• Je krijgt praktische verbeteracties voor LCP, CLS, TBT, afbeeldingen, JavaScript en serverinstellingen.
• Je leert hoe je regressies voorkomt met automatische controles en duidelijke drempelwaarden.

Wat is google lighthouse?

Google Lighthouse is een gratis open-source tool van Google waarmee je websites controleert op prestaties, toegankelijkheid, technische kwaliteit, zoekmachinevriendelijkheid en progressive web app-eisen. Na elke test krijg je een rapport met scores, audits, kansen en diagnostische meldingen. Daardoor is het een veelgebruikte tool voor performance-audits, technische SEO en kwaliteitscontrole in ontwikkelteams.

De tool is nuttig voor developers, DevOps-specialisten, SEO-specialisten, marketeers en productteams. Een ontwikkelaar ziet direct welke scripts blokkeren. Een marketeer begrijpt sneller waarom een landingspagina traag aanvoelt. Een productmanager kan beter prioriteren welke issues eerst opgelost moeten worden.

Overzicht van categorieën

De tool beoordeelt meestal vijf onderdelen:

• Performance: hoe snel de pagina laadt en reageert.
• Accessibility: of de site bruikbaar is voor mensen met beperkingen.
• Best Practices: technische kwaliteit, veiligheid en moderne implementaties.
• SEO: basiscontroles die helpen om pagina’s goed vindbaar en begrijpelijk te maken.
• PWA: controles voor progressive web app-functionaliteit.

Lab-data vs field-data

Een belangrijk verschil in interpretatie is dat Lighthouse vooral werkt met lab-data. Dat zijn testresultaten uit een gecontroleerde omgeving. Daarmee kun je wijzigingen goed vergelijken, omdat de omstandigheden grotendeels gelijk blijven.

Field-data komt van echte bezoekers en laat zien hoe je site in de praktijk presteert. Denk aan verschillen in netwerk, toestel, browser en serverbelasting. In tools zoals PageSpeed Insights zie je vaak beide naast elkaar.

Gebruik testdata vooral om problemen op te sporen en oplossingen te valideren. Gebruik echte gebruikersdata om te beoordelen of bezoekers daadwerkelijk een betere ervaring hebben. Voor een goede analyse heb je beide nodig.

Hoe run je een Lighthouse-audit?

Je kunt op meerdere manieren een audit uitvoeren. Welke methode het beste past, hangt af van je doel. Voor een snelle controle is Chrome DevTools ideaal. Voor herhaalbare tests en automatisering zijn de command line en CI-oplossingen handiger.

Chrome DevTools — snelle test

1. Open de pagina in Chrome.
2. Klik met de rechtermuisknop en kies Inspecteren.
3. Open het tabblad Lighthouse.
4. Selecteer de gewenste categorieën.
5. Kies mobiel of desktop.
6. Klik op Analyze page load.

Na de run krijg je een volledig rapport met scores, opportunities en diagnostics. Dit is de snelste manier om te starten als je wilt weten hoe je een audit uitvoert in Chrome DevTools.

Lighthouse CLI — commando’s en flags

Voor developers is de command line handig omdat je tests lokaal, in scripts of op een buildserver kunt draaien. Daarmee kun je ook eenvoudig rapporten exporteren.

npm install -g lighthouse

lighthouse https://example.com --output html --output-path ./report.html

Wil je JSON-output voor dashboards of automatische verwerking, gebruik dan:

lighthouse https://example.com --output json --output-path ./report.json

Enkele veelgebruikte opties:

lighthouse https://example.com --only-categories=performance,seo
lighthouse https://example.com --preset=desktop
lighthouse https://example.com --chrome-flags="--headless"

Zo kun je gericht testen op categorie, apparaat of headless-omgeving. Wie zoekt naar een praktisch command line-voorbeeld, heeft met deze basis direct een bruikbaar startpunt.

PageSpeed Insights en webinterface

Wil je snel een publieke URL analyseren en tegelijk echte gebruikersdata bekijken, dan is PageSpeed Insights vaak de beste keuze. Je plakt de URL in de tool en krijgt een combinatie van Lighthouse-resultaten en, als beschikbaar, data uit het Chrome User Experience Report.

Dat maakt deze methode sterk als je het verschil wilt begrijpen tussen een lokale testsimulatie en prestaties in de praktijk.

Programmatic gebruik en Node API

Voor teams die rapporten willen verwerken in eigen tooling, dashboards of scripts is programmatisch gebruik interessant. Je kunt de audit rechtstreeks via Node aanroepen en scores automatisch uitlezen.

const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');

(async () => {
  const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
  const options = { logLevel: 'info', output: 'html', port: chrome.port };
  const runnerResult = await lighthouse('https://example.com', options);

  console.log(runnerResult.lhr.categories.performance.score);

  await chrome.kill();
})();

Dit is vooral handig voor maatwerkrapportages, interne dashboards en geautomatiseerde kwaliteitscontroles.

Lighthouse CI en integratie met CI/CD

Wil je voorkomen dat nieuwe releases ongemerkt trager worden, dan is automatisering essentieel. Met Lighthouse CI kun je prestatiecontroles onderdeel maken van je deploymentproces of pull requests.

name: Lighthouse CI
on: [push]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run Lighthouse CI
        run: npx @lhci/cli autorun

Deze basisworkflow voor GitHub Actions is klein, maar effectief. Voor grotere teams is dit vaak de eerste stap om audits standaard mee te laten draaien en regressies vroeg te detecteren.

Wil je hulp bij het opzetten van structurele prestatiebewaking? Bekijk onze performance-audit.

De belangrijkste metrics uitgelegd

De totaalscore is nuttig als samenvatting, maar de onderliggende metrics vertellen waar het echte probleem zit. Vooral voor prestaties zijn deze signalen belangrijk, omdat ze direct samenhangen met gebruikerservaring en conversie.

Performance-metrics: LCP, FCP, TBT, CLS, TTI en TTFB

LCP staat voor Largest Contentful Paint. Dit meet wanneer het grootste zichtbare element in beeld staat. Vaak gaat het om een hero-afbeelding, banner of grote kop. Streef naar 2,5 seconden of sneller.

FCP staat voor First Contentful Paint. Dit is het moment waarop de eerste zichtbare content verschijnt. Een goede richtlijn is 1,8 seconden of sneller.

TBT betekent Total Blocking Time. Deze metric laat zien hoeveel tijd de browser geblokkeerd wordt door zware taken, meestal JavaScript. Een waarde onder 200 milliseconden is een goed doel.

CLS staat voor Cumulative Layout Shift. Daarmee meet je onverwachte verschuivingen in de layout. Denk aan knoppen of tekst die opschuiven tijdens het laden. Een goede waarde ligt op 0,1 of lager.

TTI betekent Time to Interactive. Dit geeft aan wanneer de pagina niet alleen zichtbaar is, maar ook bruikbaar reageert op interactie.

TTFB staat voor Time to First Byte. Dit meet hoe snel de server de eerste byte terugstuurt. Een richtwaarde is 0,8 seconden of sneller.

Accessibility en best practices: voorbeelden van audits

Binnen toegankelijkheid controleert de tool onder meer kleurcontrast, alt-teksten, labels voor formulieren, correcte headingstructuur en toetsenbordgebruik. Binnen best practices kijkt het rapport bijvoorbeeld naar HTTPS, foutgevoelige browser-API’s, console errors en veilige laadpatronen.

Deze onderdelen zijn niet alleen belangrijk voor compliance of techniek, maar ook voor vertrouwen en gebruiksgemak.

SEO en PWA-checks

De SEO-controles richten zich vooral op basisvoorwaarden, zoals crawlbare links, meta-informatie, viewport-instellingen en indexeerbaarheid. Voor PWA’s kijkt de tool naar zaken zoals een manifest, offline-functionaliteit en installatiemogelijkheden.

Concreet: audits → oorzaken → fixes

Een goed rapport lezen is één ding. Verbeteringen prioriteren is belangrijker. Begin met issues die veel impact hebben op LCP, TBT, CLS of serverrespons. Die leveren vaak de grootste winst op voor gebruikers én scores.

Afbeeldingen en media

Afbeeldingen zijn vaak een van de grootste oorzaken van trage pagina’s. Vooral hero-beelden en banners drukken zwaar op de laadtijd.

• Comprimeer afbeeldingen zonder zichtbaar kwaliteitsverlies.
• Gebruik moderne formaten zoals WebP of AVIF.
• Lever responsive afbeeldingen aan via srcset en sizes.
• Gebruik lazy loading voor media onder de vouw.
• Voeg vaste width en height toe om layout shifts te beperken.

Praktische impact: optimalisatie van één zware hero-afbeelding verlaagt vaak direct de laadtijd van het grootste zichtbare element.

JavaScript en bundling

Veel sites verliezen prestaties door te veel JavaScript, onnodige libraries en scripts van derden. Vooral op mobiel leidt dat snel tot een hoge blocking time.

• Splits bundles op met code splitting.
• Verwijder ongebruikte code met tree shaking.
• Laad scripts met defer of async waar mogelijk.
• Stel niet-kritieke widgets uit tot na interactie.
• Beperk third-party scripts tot wat echt noodzakelijk is.

Prioriteit: pak eerst scripts aan die op elke pagina geladen worden en veel CPU-tijd gebruiken.

Server en netwerk

Een snelle frontend compenseert geen trage server. Als de eerste byte laat komt, begint de rest van de pagina automatisch ook later.

• Gebruik caching headers voor statische assets.
• Schakel Brotli of gzip-compressie in.
• Gebruik een CDN voor internationale of drukbezochte sites.
• Werk waar mogelijk met HTTP/2 of HTTP/3.
• Gebruik preconnect voor kritieke externe domeinen.

Een eenvoudige serverchecklist voor niet-technische stakeholders: vraag of caching actief is, of compressie aanstaat en of zware assets via een CDN geleverd worden.

Rendering en critical CSS

Render-blocking CSS en scripts vertragen de eerste zichtbare weergave. Daardoor voelt een pagina traag, ook als de server snel is.

• Inline kritieke CSS voor inhoud boven de vouw.
• Stel niet-kritieke stylesheets uit.
• Verwijder ongebruikte CSS-regels.
• Minimaliseer afhankelijkheden in het kritieke pad.

Fonts en third-party scripts

Webfonts en externe scripts veroorzaken vaak verborgen vertraging. Denk aan chatwidgets, A/B-testtools, advertentietags en trackers.

• Gebruik font-display: swap.
• Laad alleen de benodigde lettergewichten en subsets.
• Host fonts waar mogelijk lokaal.
• Controleer of externe tools echt nodig zijn op alle pagina’s.
• Verplaats niet-kritieke third-party scripts naar later in de lifecycle.

Prioriteringsmatrix: wat eerst oplossen?

Gebruik deze simpele volgorde voor prioriteit:

1. Hoge impact, lage complexiteit: grote afbeeldingen comprimeren, lazy loading activeren, caching goed zetten.
2. Hoge impact, gemiddelde complexiteit: scripts uitstellen, third-party code verminderen, critical CSS optimaliseren.
3. Hoge impact, hoge complexiteit: backend-optimalisatie, architectuurwijzigingen, renderingstrategie aanpassen.
4. Lage impact: kleine scoreverbeteringen zonder merkbaar effect voor gebruikers pas later oppakken.

Belangrijke scoregrenzen en interpretatie

Gebruik de kleuren in het rapport als snelle indicatie, niet als einddoel.

• Goed: 90 of hoger
• Verbetering nodig: 50 tot 89
• Slecht: lager dan 50

Een score van 100 is niet altijd nodig. Belangrijker is dat echte gebruikers een snelle, stabiele en toegankelijke ervaring krijgen. Focus dus op impactvolle verbeteringen in plaats van cosmetische winstpunten.

Automatiseren en bewaken

Een eenmalige test is nuttig, maar continue bewaking voorkomt dat prestaties langzaam teruglopen. Zeker bij teams met veel releases, templates of campagnes is dat essentieel.

Voorbeeldconfiguratie voor GitHub Actions

name: Lighthouse CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: npm ci
      - name: Run Lighthouse CI
        run: npx @lhci/cli autorun

Strategie voor drempels en regressiepreventie

Begin met realistische thresholds. Zet niet direct elke score op 100. Kies liever per paginatype duidelijke minima, bijvoorbeeld:

• Performance minimaal 90 voor marketingpagina’s
• Accessibility minimaal 95 voor alle publieke pagina’s
• CLS onder 0,1
• TBT onder 200 ms op kritieke templates

Voorkom false positives door meerdere runs te vergelijken, vaste testomstandigheden te gebruiken en uitzonderingen goed te documenteren.

Lees ook onze gids over web performance voor een bredere aanpak buiten alleen audits.

Best practices en quick wins checklist

Wil je snel resultaat? Begin dan met deze checklist:

• Comprimeer zware afbeeldingen en gebruik moderne formaten.
• Voeg lazy loading toe aan media buiten beeld.
• Geef afbeeldingen vaste afmetingen om verschuivingen te voorkomen.
• Beperk third-party scripts tot wat echt nodig is.
• Gebruik caching headers voor statische bestanden.
• Schakel Brotli of gzip in.
• Laad niet-kritieke JavaScript uitgesteld.
• Gebruik font-display: swap voor webfonts.
• Controleer kleurcontrast, alt-teksten en form labels.
• Test meerdere keren en vergelijk met echte gebruikersdata.

Gebruik de Lighthouse Quick Fix Checklist of plan direct een performance-audit.

Veelvoorkomende valkuilen

De meest gemaakte fout is te veel focussen op één score. Een hoge score betekent niet automatisch dat gebruikers tevreden zijn. Andersom hoeft een lagere score niet altijd een acuut probleem te zijn.

Variabiliteit in testresultaten

Scores kunnen schommelen door netwerkcondities, serverbelasting, caching en scripts van derden. Doe daarom meerdere runs en kijk naar trends in plaats van naar één losse meting.

Caching-issues en lokale vertekening

Een test vanaf je eigen machine kan rooskleuriger zijn dan de ervaring van een nieuwe bezoeker. Test daarom ook in schone omstandigheden en combineer resultaten met echte gebruikersdata.

Lab-scores zijn geen volledige waarheid

Gebruik lab-data om oorzaken te vinden. Gebruik field-data om te valideren of bezoekers daadwerkelijk profiteren. Vooral bij grote websites, internationale doelgroepen of zware mobiele traffic is dat verschil belangrijk.

Case study: kort voorbeeld van voor en na

Stel dat een landingspagina start met een LCP van 4,8 seconden, een CLS van 0,22 en een TBT van 420 milliseconden. Na drie gerichte verbeteringen verandert het beeld snel:

• hero-afbeelding gecomprimeerd en in modern formaat geleverd
• niet-kritieke scripts uitgesteld geladen
• twee zware third-party tools verwijderd

Resultaat na optimalisatie:

• LCP: van 4,8 s naar 2,4 s
• CLS: van 0,22 naar 0,04
• TBT: van 420 ms naar 140 ms

Zo’n verbetering zie je niet alleen terug in het rapport, maar vaak ook in lagere bounce rates, een rustiger pagina-ervaring en betere mobiele bruikbaarheid.

Veelgestelde vragen

Conclusie en volgende stappen

Google Lighthouse is een sterke en praktische manier om knelpunten in snelheid, toegankelijkheid, technische kwaliteit en basis-SEO zichtbaar te maken. De echte winst zit niet in de kleur van de meter, maar in het vertalen van audits naar concrete acties met meetbaar effect.

Werk daarom in deze volgorde: eerst analyseren, daarna prioriteren, vervolgens verbeteren en tot slot automatisch bewaken. Combineer testresultaten met echte gebruikersdata, zodat je niet alleen optimaliseert voor rapporten, maar vooral voor bezoekers.

Wil je direct aan de slag? Bekijk onze Lighthouse Quick Fix Checklist of plan een performance-audit.