Korte versie
Begin met labtests en beschikbare praktijkdata. Onderzoek daarna serverrespons, hoofdbeeld, kritieke CSS, JavaScript, fonts, caching en externe scripts. Pak aan wat jouw meting als grootste vertraging aanwijst en blijf de prestaties na wijzigingen volgen.
Wil je de laadtijd van je website verbeteren? Meet eerst waar de vertraging zit, pak het grootste probleem aan en controleer het resultaat. De negen stappen hieronder helpen je daarbij. Zo besteed je minder tijd aan kleine aanpassingen die je bezoeker nauwelijks merkt.
Op een pagina die vlot reageert, kunnen bezoekers sneller vinden en doen wat ze willen. Toch begint optimalisatie vaak met losse ingrepen: een cacheplugin, kleinere bestanden of een CDN. Die kunnen helpen, maar zonder diagnose weet je niet of je het juiste probleem oplost. Wil je de cijfers eerst duiden, lees dan hoe een SEO-analyse metingen omzet in prioriteiten. Deze gids gaat over de uitvoering. Google gebruikt Core Web Vitals in zijn rankingsystemen, maar belooft daarmee geen hoge positie (Google Search Central).
De 9 stappen die ik telkens opnieuw gebruik
Gebruik de stappen als onderzoeksvolgorde, niet als vaste ranglijst van problemen. Als het hoofdbeeld de pagina vertraagt, levert dat doorgaans meer op dan twintig kleine icoontjes aanpakken. Wacht de browser vooral op de server, begin dan daar.
Stap 01
Meet eerst, anders optimaliseer je op gevoel
Praktijkdata naast labtests
Combineer labtests met beschikbare praktijkdata. Lighthouse of WebPageTest test een pagina onder ingestelde omstandigheden. Het Chrome UX Report (CrUX) bundelt praktijkdata van deelnemende Chrome-gebruikers, officieel field data, met uiteenlopende apparaten en verbindingen. De actuele CrUX API gebruikt een venster van 28 dagen. Eigen bezoekersmetingen kunnen die publieke data aanvullen. In onze vergelijking van 19 websitebouwers hadden zeven bureaus een bruikbare actuele CrUX-waarde; hun Lab-LCP lag tot 16,7x zo hoog als de CrUX-LCP (p75). Dat verschil bewijst niet welke oorzaak erachter zit.
Controleer ook het meetbereik. CrUX kan gegevens voor één URL of voor een hele origin tonen, waarin meerdere pagina’s zijn gebundeld. Vergelijk die niet ongemerkt met één mobiele labtest. Ontbrekende CrUX-data betekent evenmin dat een website traag is: de opvraag kan onvoldoende bruikbare waarnemingen hebben of niet aan de CrUX-voorwaarden voldoen.
Welke waarden noteer je?
Kijk niet alleen naar één totaalscore. Noteer Largest Contentful Paint voor het laden van het grootste zichtbare content-element, Interaction to Next Paint voor reacties op interacties en Cumulative Layout Shift voor onverwachte layoutverschuivingen. De grenzen voor een goede uitslag zijn LCP maximaal 2,5 seconden, INP maximaal 200 milliseconden en CLS maximaal 0,1 (web.dev, Core Web Vitals). Beoordeel elke metriek op het 75e percentiel, apart voor mobiel en desktop. Bij LCP betekent p75 dat minstens 75% van de gemeten paginaladingen op of onder die waarde zit. Voor goede Core Web Vitals moeten alle drie de metrieken voldoen; het gaat niet om een gemiddelde of noodzakelijk dezelfde 75% bij elke metriek.
“LCP should occur within 2.5 seconds of when the page first starts loading.” — web.dev, Core Web Vitals
Leg daarnaast de serverrespons, de hoeveelheid JavaScript en de grootste netwerkverzoeken vast. Dat is je nulmeting: dezelfde aanpak als in een SEO-analyse, maar gericht op snelheid.
- Test mobiel én desktop op een koude cache.
- Meet een homepage, inhoudspagina en conversiepagina afzonderlijk.
- Bewaar het netwerkdiagram (de waterfall); daarin zie je wachttijd en afhankelijkheden.
- Herhaal dezelfde test na elke betekenisvolle wijziging.
Stap 02
Verlaag de wachttijd vóór de eerste HTML
Wacht de browser lang op het eerste document? Controleer de Time to First Byte: de tijd tot de eerste byte van de serverrespons. Trage databasequeries, zware serverplugins, grote afstand tot de server of dynamische rendering zonder cache kunnen die wachttijd verhogen. Onderzoek welke oorzaak bij jouw pagina speelt.
Voor grotendeels vaste marketingpagina’s is statische generatie vaak de eenvoudigste winst: de HTML ligt vooraf klaar en kan via een wereldwijd netwerk worden geleverd. Voor dynamische toepassingen helpt gerichte servercache, maar cache nooit blind persoonlijke of winkelmanddata. Meet ook de origin rechtstreeks; een CDN kan een trage bron tijdelijk maskeren.
Stap 03
Maak het hoofdbeeld zo licht als zijn functie toelaat
Afbeeldingen nemen vaak veel van het paginagewicht in, en het hoofdbeeld is geregeld het LCP-element. In juli 2025 woog de mediane mobiele homepage 2.559 KB (Web Almanac 2025, Page Weight). Een jaar eerder rapporteerde het onderzoek voor mobiel een mediaan van 900 KB aan beelden en 558 KB aan JavaScript (Web Almanac 2024, Page Weight). Dat zijn afzonderlijke medianen, geen optelsom voor één doorsneepagina.
Lever niet automatisch een foto van 3000 pixels breed aan een vak van 720 pixels. Genereer responsieve varianten en houd rekening met de pixeldichtheid van het scherm. Gebruik een modern formaat zoals WebP of AVIF en kies de compressie per beeldtype. Een zachte foto verdraagt doorgaans meer compressie dan een interfacebeeld met scherpe tekst.
Laad het LCP-beeld niet uitgesteld: de browser moet het meteen ontdekken. Beelden buiten het eerste zichtbare scherm kun je wel lazy-loaden. Geef width en height mee zodat de browser vooraf ruimte reserveert en de layout niet verspringt. Gebruik je een CMS, controleer dan of de templates die afmetingen en beeldvarianten correct meegeven.
Vergelijking: welk beeldformaat kies je?
Er bestaat geen formaat dat altijd wint. Kies op basis van inhoud, browserondersteuning en de transparantie of animatie die je werkelijk nodig hebt.
| Formaat | Beste voor | Sterk punt | Let op |
|---|---|---|---|
| AVIF | Foto's en complexe illustraties | Klein bestand bij hoge kwaliteit | Encoderen duurt langer |
| WebP | Algemeen webgebruik | Breed ondersteund en compact | Soms groter dan AVIF |
| SVG | Logo's, iconen en diagrammen | Scherp op elke resolutie | Niet geschikt voor foto's |
| PNG | Lossless details en fallback | Exacte pixels en alpha | Vaak onnodig zwaar |
Stap 04
Laat kritieke CSS niet wachten op de rest
De browser heeft CSS nodig om het eerste scherm correct te tekenen. Een groot stylesheet met veel ongebruikte regels kan dat vertragen. Verwijder overbodige code, splits alleen waar dat helpt en voorkom een keten van @import-bestanden. Controleer daarna of de belangrijkste inhoud eerder verschijnt.
Inline critical CSS kan bij grote toepassingen helpen, maar heeft ook onderhoudskosten. Begin eenvoudiger: één goed gecachet stylesheet, lokale fonts en geen blokkerende externe stijlen. Controleer daarna pas of verder opsplitsen meetbare winst geeft.
Stap 05
Verstuur minder JavaScript en voer het later uit
JavaScript kost meer dan downloadtijd. De browser moet het ontleden, compileren en uitvoeren, meestal op dezelfde hoofdthread die ook invoer van je bezoeker verwerkt. Een bundel die op je laptop onschuldig voelt, kan op een doorsnee telefoon merkbare vertraging veroorzaken. Voor reactiesnelheid meet Google inmiddels met INP, niet meer met de oudere First Input Delay-metriek: “INP is the successor metric to First Input Delay (FID)” (web.dev, Interaction to Next Paint). Wie vandaag nog op een oude FID-score optimaliseert, kijkt naar een metriek die niet meer beoordeeld wordt.
Schrap libraries die één kleine interactie oplossen, laad paginafuncties pas waar ze nodig zijn en gebruik native HTML voor accordeons, formulieren en video waar dat kan. Zet niet-kritieke scripts op defer en initialiseer zware widgets pas na een bewuste interactie. De snelste code is nog altijd code die je niet verstuurt.
Stap 06
Beperk webfonts zonder je huisstijl te verliezen
Vijf lettertypefamilies en twaalf gewichten zijn zelden nodig. Kies bijvoorbeeld één lettertype voor koppen en één voor lopende tekst. Beperk de fontbestanden tot de benodigde tekens en gewichten, maar vergeet accenten en andere talen niet. Host fonts lokaal wanneer je controle over caching, privacy en beschikbaarheid wilt.
Preload alleen het font dat direct boven de vouw nodig is. Te veel preloads concurreren met het hoofdbeeld en CSS. Gebruik font-display: swap zodat tekst zichtbaar blijft terwijl het font binnenkomt, en kies fallbackfonts met vergelijkbare verhoudingen om verspringing te beperken.
Stap 07
Gebruik caching en een CDN als versneller, niet als pleister
Stel lange cacheheaders in voor assets met een unieke bestandsnaam. Wanneer de inhoud verandert, verandert de hash en krijgt de browser automatisch de nieuwe versie. HTML vraagt meestal een kortere strategie, omdat actuele inhoud belangrijker is dan maximale bewaartijd.
Een CDN brengt bestanden dichter bij bezoekers en vangt verkeerspieken op. Het maakt een bestand alleen niet kleiner en verwijdert geen blokkerende code. Los dus eerst het gewicht en de afhankelijkheden op; verspreid daarna de efficiënte versie.
Stap 08
Geef elk extern script een duidelijk doel
Chatwidgets, heatmaps, advertentiepixels, videospelers en tagmanagers komen vaak van andere servers. Je controleert hun snelheid niet en één tagmanager kan ongemerkt tientallen requests starten. Inventariseer daarom elk extern script met een eigenaar en een duidelijk doel.
Laad marketingtags pas na toestemming, toon eerst een lokale videoposter en activeer de externe speler na een klik. Verwijder tools die niemand nog gebruikt. Maak van “mag dit script erbij?” dezelfde serieuze beslissing als “mag deze feature erbij?”.
Stap 09
Maak snelheid onderdeel van elke release
Een eenmalige optimalisatie blijft niet vanzelf goed. Nieuwe beelden, tags en componenten schuiven het gewicht langzaam omhoog. Stel daarom budgetten in voor JavaScript, beelden en Core Web Vitals. Laat je build waarschuwen bij overschrijding en controleer na een grote wijziging opnieuw de belangrijkste templates.
Bekijk maandelijks de beschikbare praktijkdata, met mobiel en desktop afzonderlijk. Wil je nieuwe en terugkerende bezoekers of verbindingstypen vergelijken, gebruik dan eigen bezoekersmetingen die die segmenten ondersteunen. CrUX biedt niet al die uitsplitsingen. Een gemiddelde of één groene Lighthouse-run kan problemen bij een deel van de bezoeken verbergen.
Spreek af wie elke waarschuwing opvolgt. Maak een ticket met de URL, de verslechterde meetwaarde en het afgesproken budget. Neem bij nieuwe componenten prestaties mee in de acceptatiecriteria: hoeveel extra JavaScript komt erbij, welke afbeelding wordt het LCP-element en wat gebeurt er op een trage verbinding? Bij webdesign kun je daar al rekening mee houden door beelden, functies en paginaopbouw gericht te kiezen.
Vergeet ook betrouwbaarheid niet. Een snelle eerste render die daarna vastloopt door een fout script is geen goede ervaring. Controleer consolefouten, mislukte requests en time-outs samen met de vitals. De beste performance-aanpak maakt een pagina niet alleen vlugger, maar ook eenvoudiger en voorspelbaar.
Wat pak je maandag als eerste aan?
- Maak een nulmetingNoteer LCP, INP, CLS, serverrespons en de drie zwaarste netwerkverzoeken. Vermeld welke waarden uit labtests of praktijkdata komen.
- Los één groot probleem opKies op basis van je meting, bijvoorbeeld het hoofdbeeld, serverwerk of blokkerend JavaScript.
- Meet dezelfde pagina opnieuwControleer het resultaat onder dezelfde testomstandigheden en volg daarna de beschikbare praktijkdata.
Zo kun je uitleggen waarom een wijziging prioriteit krijgt en controleren of ze werkelijk helpt. Levert een aanpassing niets op, onderzoek dan de volgende gemeten oorzaak in plaats van nog een plugin toe te voegen.