Website sneller maken begint met meten: per template zie je in PageSpeed Insights waar de tijd heen gaat. Daarna zit de meeste winst doorgaans in een server die snel antwoordt, een hoofdafbeelding die meteen laadt en minder scripts van derden.
Dit artikel is de lijst met oplossingen. Hoe je per metriek uitzoekt wat er faalt, staat in Core Web Vitals verbeteren. Wil je eerst weten hoe je mobiele snelheid ervoor staat naast de rest van je vindbaarheid, doe dan de gratis SEO-quickscan.
Hoe snel moet een website laden?
De hoofdinhoud moet binnen 2,5 seconde in beeld staan, gemeten bij 75% van de bezoeken, apart voor mobiel en desktop (web.dev, Web Vitals). Daarnaast moet de pagina binnen 200 milliseconden reageren op een klik en mag hij nauwelijks verspringen. Eén 'laadtijd' in seconden zegt dus weinig: een pagina kan na 1 seconde leesbaar zijn en pas na 6 seconden 'klaar'. De bezoeker merkt dat eerste moment, niet het tweede.
| Wat je meet | Goed | Wat het zegt |
|---|---|---|
| Time to First Byte (TTFB) | 0,8 s of minder | Hoe snel de server begint te antwoorden; ruwe richtlijn, geen Core Web Vital |
| Largest Contentful Paint (LCP) | 2,5 s of minder | Wanneer het grootste element, meestal de hoofdafbeelding of kop, zichtbaar is |
| Interaction to Next Paint (INP) | 200 ms of minder | Hoe snel de pagina reageert op klikken en tikken |
| Cumulative Layout Shift (CLS) | 0,1 of minder | Hoeveel de pagina verspringt tijdens het laden |
Waar per metriek de grens tussen 'verbetering nodig' en 'slecht' ligt, staat in de gids over Core Web Vitals.
Waarom is mijn website traag?
Waarom je website traag is, zie je meestal aan wat er tijdens het laden gebeurt. Zoek hieronder wat je ziet en begin bij de ingreep die erbij staat.
| Wat je ziet | Waarschijnlijke oorzaak | Begin bij |
|---|---|---|
| Elke pagina blijft eerst even wit, ook een korte tekstpagina | Trage server: geen page caching, oude PHP-versie, redirectketen | Ingreep 1 en 2 |
| De tekst staat er, de grote foto bovenaan komt als laatste | Hoofdafbeelding wordt lazy of laat geladen, of is te zwaar | Ingreep 3 en 4 |
| De pagina verspringt terwijl je begint te lezen | Afbeeldingen zonder maten, fonts die wisselen, banners die later inschuiven | Ingreep 5 en 6 |
| De pagina staat er, maar menu en knoppen reageren traag | Te veel JavaScript, vaak van chatwidgets, tag managers en plugins | Ingreep 7 en 8 |
| Alleen pagina's uit de paginabouwer zijn traag | Thema of paginabouwer laadt CSS en scripts van alle blokken | Ingreep 8 en 9 |
| Een tweede bezoek is net zo traag als het eerste | Bestanden worden niet of te kort in de browser bewaard | Ingreep 10 |
Helpen de ingrepen bij je symptoom weinig, dan zit de rem vaak in het thema zelf; daarover gaat de sectie onderaan.
Websitesnelheid meten: per template, niet per pagina
Een site bestaat uit een handvol templates: home, dienstpagina, blogartikel, product, categorie. Een verbetering aan het template werkt voor alle pagina's tegelijk.
- Kies per template één voorbeeld-URL.
- Test die in PageSpeed Insights, op mobiel.
- Noteer LCP, INP en CLS uit de velddata bovenaan, en de verbeterpunten uit de test eronder.
- Dat is je nulmeting. Na elke ingreep meet je dezelfde URL's opnieuw.
Velddata zijn metingen bij echte bezoekers over 28 dagen; de test eronder is één gesimuleerde laadbeurt. Andere meetinstrumenten vind je bij gratis SEO-tools.
De 12 ingrepen in het kort
- Maak de server snel: page caching, actuele PHP-versie, geen redirectketens.
- Zet een CDN en compressie aan: Brotli of gzip, HTTP/2 of HTTP/3.
- Laad de hoofdafbeelding meteen: geen lazy-load, wel fetchpriority="high".
- Lever het juiste formaat en de juiste maat: AVIF of WebP, met srcset en sizes.
- Geef elke afbeelding maten mee: width en height, en lazy-load wat onder de vouw staat.
- Laad minder fonts: woff2, weinig gewichten, font-display en een afgestemd fallback-font.
- Ruim scripts van derden op: weg wat niemand gebruikt, de rest pas na een klik.
- Laad je eigen JavaScript uitgesteld: defer, en geen plugin-scripts op pagina's die ze niet nodig hebben.
- Snoei ongebruikte CSS: vooral bij paginabouwers en zware thema's.
- Stel browsercaching goed in: lange cacheduur voor bestanden met een versie in de naam.
- Houd de back/forward-cache werkend: geen unload-handlers.
- Laad de volgende pagina vooruit: met de Speculation Rules API.
De ingrepen staan in volgorde van bereik: wie de snelheid van zijn website wil verbeteren, begint met wat alle pagina's tegelijk sneller maakt, daarna komt de verfijning.
WordPress sneller maken: begin hier
Wil je je website sneller maken in WordPress, loop dan deze stappen na. Het nummer achter elke stap verwijst naar de ingreep verderop.
- Doe eerst de nulmeting hierboven: één URL per template, op mobiel.
- Zet page caching aan. Draait je host op LiteSpeed, gebruik dan LiteSpeed Cache; anders de cache van je host of een betaalde plugin als WP Rocket. Nooit twee caching-plugins tegelijk (ingreep 1).
- Zet in je hostingpaneel PHP 8.3 of hoger aan (ingreep 1).
- Laat een afbeeldingsplugin, bijvoorbeeld ShortPixel of Imagify, je beelden omzetten naar AVIF of WebP (ingreep 4).
- Controleer in PageSpeed Insights onder 'LCP request discovery' dat je hoofdafbeelding niet lazy geladen wordt (ingreep 3).
- Zet plugin-scripts uit op pagina's die ze niet gebruiken, met een scriptbeheer-plugin als Asset CleanUp of Perfmatters (ingreep 8).
Server en levering
1. Maak de server snel (Time to First Byte)
Alles op de pagina wacht op de eerste byte HTML van de server. web.dev noemt 0,8 seconde of minder 'goed' en boven 1,8 seconde 'slecht', als ruwe richtlijn (web.dev, Time to First Byte).
- Page caching: de server bouwt de pagina dan niet bij elk bezoek opnieuw op uit de database.
- Actuele PHP-versie: WordPress raadt PHP 8.3 of hoger aan (WordPress, requirements). PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer (php.net, supported versions).
- Geen redirectketens: elke extra redirect is een extra rondgang voordat de pagina begint te laden. Link intern direct naar de eindbestemming.
- Hosting dicht bij je bezoekers: voor een Nederlandse site een datacenter in of vlak bij Nederland.
In PageSpeed Insights zie je dit terug als het verbeterpunt 'Document request latency'. Wij gebruiken in dit artikel de Engelse namen; zet ?hl=en achter het adres van PageSpeed Insights (pagespeed.web.dev/?hl=en), dan vind je ze één-op-één terug.
2. Zet een CDN en compressie aan
Een CDN (bijvoorbeeld het gratis abonnement van Cloudflare, of de CDN van je hoster) levert afbeeldingen, CSS en scripts, zodat je eigen server alleen nog HTML hoeft te maken.
- Zet Brotli- of gzip-compressie aan voor HTML, CSS en JavaScript.
- Controleer dat HTTP/2 of HTTP/3 actief is; PageSpeed Insights meldt het onder 'Modern HTTP' als dat niet zo is.
- Ondersteunt je CDN 103 Early Hints, dan kan de browser kritieke bestanden zoals je CSS al ophalen terwijl de server de HTML nog bouwt (web.dev, TTFB optimaliseren).
Afbeeldingen
3. Laad de hoofdafbeelding meteen
De grote afbeelding bovenaan is meestal het LCP-element: het grootste dat in beeld verschijnt. Die moet zo vroeg mogelijk binnen zijn.
- Geen loading="lazy" op deze afbeelding. Lazy-load stelt het laden uit tot de layout bekend is, en vertraagt zo juist het belangrijkste beeld.
- Voeg fetchpriority="high" toe. Afbeeldingen starten anders met lage prioriteit; alle actuele browsers ondersteunen dit attribuut (Chrome en Edge 102+, Firefox 132+, Safari 17.2+).
- Zet hem als gewone img in de HTML, niet als CSS-achtergrond of via een slider-script. Dan vindt de browser hem pas laat. Moet het een achtergrond zijn, laad hem dan vooruit met een preload-regel.
Bronnen: web.dev, Fetch Priority en web.dev, LCP optimaliseren. Controleren zonder code te lezen: open in PageSpeed Insights 'LCP request discovery'. Daar zie je per punt met een vinkje of lazy load ontbreekt, of fetchpriority=high is gezet en of de afbeelding direct in de HTML staat.
4. Lever het juiste formaat en de juiste maat
Moderne formaten schelen veel bytes. Volgens MDN is AVIF bij vergelijkbare kwaliteit rond de 50% kleiner dan JPEG, en WebP gemiddeld 25-35% (MDN, image types). Beide werken in alle actuele browsers; met een picture-element geef je oudere browsers een JPEG als terugval.
Lever met srcset en sizes per schermbreedte een passende maat, zodat een telefoon geen afbeelding van 2.400 pixels breed downloadt. PageSpeed Insights bundelt dit onder 'Improve image delivery'.
5. Geef elke afbeelding maten mee, lazy-load wat onder de vouw staat
Geef elke afbeelding width en height, zodat de browser ruimte reserveert en de layout niet verspringt. Afbeeldingen verder op de pagina krijgen daarnaast loading="lazy"; dat bespaart vooral data voor bezoekers die niet doorscrollen.
Lighthouse 13 schrapte de controle 'offscreen images': de browser geeft zulke afbeeldingen zelf al een lage prioriteit, dus het effect op wat Lighthouse meet is klein (Chrome for Developers, Lighthouse 13).
Fonts
6. Laad minder fonts, alleen in woff2
- Gebruik alleen woff2; dat comprimeert volgens web.dev ongeveer 30% beter dan woff.
- Laad alleen de gewichten die je echt gebruikt, of één variabel font in plaats van vier losse bestanden.
- Preload hooguit het font van je kop of hoofdtekst; elke preload gaat ten koste van andere bestanden.
- Kies font-display: swap (tekst direct zichtbaar) of optional (geen verspringing), en stem het fallback-font af met size-adjust.
- Zelf hosten op je eigen domein of CDN scheelt een verbinding met een extra domein, maar volgens web.dev is het niet automatisch sneller: in de Web Almanac renderden sites met fonts van derden zelfs iets sneller. Meet het op je eigen site.
Bron: web.dev, best practices voor webfonts. Overweeg ook een systeemfont voor de lopende tekst: dat hoeft helemaal niet geladen te worden.
Scripts en CSS
7. Ruim scripts van derden op
Chatwidgets, tag managers, heatmaps, A/B-tools en embeds zijn een veelvoorkomende oorzaak van een trage reactie op klikken (INP). Maak een lijst:
- Welke scripts laden er? PageSpeed Insights toont ze onder 'Third parties'.
- Wie gebruikt de data nog? Een heatmap van twee jaar geleden die niemand opent, mag weg.
- Wat blijft, laad je later: een chatwidget pas als iemand op de knop klikt, een video pas na een klik op een stilstaand voorbeeldbeeld.
Laat tags in je tag manager alleen afgaan op de pagina's waar ze iets doen, niet standaard op elke pagina.
8. Laad je eigen JavaScript uitgesteld
Zet defer op scripts die niet nodig zijn voor de eerste weergave; dan blokkeren ze het tekenen van de pagina niet. Scripts die dat wel doen, staan in PageSpeed Insights onder 'Render-blocking requests'.
Bij WordPress laden veel plugins hun scripts op elke pagina, ook waar ze niets doen: een formulierplugin op je blog, een sliderplugin op je contactpagina. Dat zet je uit met een plugin voor scriptbeheer per pagina, bijvoorbeeld Asset CleanUp of Perfmatters: laat het formulierscript alleen op je contactpagina laden. Controleer daarna in het Network-tabblad van Chrome DevTools of het bestand op de andere pagina's echt weg is. Meer over een schone WordPress-basis staat bij WordPress SEO.
9. Snoei ongebruikte CSS
Paginabouwers en thema's laden vaak de CSS van alle mogelijke blokken. Het Coverage-paneel in Chrome DevTools laat zien hoeveel daarvan op een pagina echt gebruikt wordt; Lighthouse, dat ook in PageSpeed Insights draait, meldt het als de diagnose 'Reduce unused CSS'.
Veel optimalisatieplugins kunnen kritieke CSS inline zetten en de rest uitgesteld laden. Klik daarna je menu, je contactformulier en eventuele pop-ups door: die breken als eerste als er CSS ontbreekt.
Caching en navigatie
10. Stel browsercaching goed in
Geef CSS, JavaScript, fonts en afbeeldingen een lange cacheduur, bijvoorbeeld Cache-Control: max-age=31536000, immutable (een jaar). Een terugkerende bezoeker hoeft ze dan niet opnieuw te downloaden.
Dat kan alleen veilig als je build de bestandsnaam verandert bij elke wijziging (fingerprinting, bijvoorbeeld style.3f9a2c.css). Anders blijven bezoekers een jaar lang je oude CSS zien. PageSpeed Insights meldt een te korte cacheduur onder 'Use efficient cache lifetimes'.
11. Houd de back/forward-cache werkend
Met de back/forward-cache (bfcache) toont de browser een vorige pagina direct als een bezoeker op 'terug' tikt, zonder opnieuw te laden. De grootste blokkade is een unload-handler in je eigen code of in een script van derden (web.dev, bfcache). Chrome telt zo'n terugnavigatie in de velddata als apart paginabezoek met een bijna directe LCP.
Cache-Control: no-store hield pagina's vroeger altijd buiten de bfcache. Chrome laat zulke pagina's sinds 2025 toch toe, maar korter (3 minuten) en verwijdert ze zodra een cookie of inlogstatus verandert (Chrome for Developers). Test het in Chrome DevTools, tabblad Application, onder 'Back/forward cache'; Lighthouse heeft er ook een eigen diagnose voor: 'Page didn't prevent back/forward cache restoration'.
12. Laad de volgende pagina vooruit
Met de Speculation Rules API laadt de browser een pagina alvast voordat de bezoeker erop klikt. Bij de stand 'moderate' gebeurt dat op desktop na 200 milliseconden met de muis op een link; bij 'conservative' pas zodra de klik of tik begint. Op mobiel start 'moderate' niet bij aanraken, maar 500 milliseconden nadat het scrollen stopt, voor links in de buurt van waar de bezoeker het laatst tikte (Chrome for Developers, speculation rules).
- Werkt in Chrome en Edge. Firefox ondersteunt het niet en Safari alleen achter een instelling; daar gebeurt dus niets, maar het kan ook geen kwaad.
- WordPress zet het sinds versie 6.8 standaard aan in de voorzichtige stand: prefetch met 'conservative', niet voor ingelogde gebruikers en niet zonder nette permalinks (WordPress Core).
- Bij andere systemen voeg je een korte regelset toe, zoals hieronder. Die sluit uitlog- en winkelmand-URL's uit; pas de paden aan je eigen site aan en sluit ook andere actie-URL's uit.
<script type="speculationrules">
{
"prefetch": [{
"where": { "and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/uitloggen*" } },
{ "not": { "href_matches": "/winkelmand*" } }
] },
"eagerness": "moderate"
}]
}
</script>PageSpeed verbeteren: welke ingreep lost welke melding op?
De namen hieronder komen uit de Engelse interface. Staat PageSpeed Insights bij jou in het Nederlands, open dan pagespeed.web.dev/?hl=en om ze één-op-één terug te vinden.
| Ingreep | Raakt vooral | Verbeterpunt in PageSpeed Insights |
|---|---|---|
| 1-2 Server, CDN, compressie | LCP (via Time to First Byte) | Document request latency, Modern HTTP |
| 3 Hoofdafbeelding | LCP | LCP request discovery, LCP breakdown |
| 4 Formaat en maat | LCP | Improve image delivery |
| 5 Maten en lazy-load | CLS, en minder dataverbruik | Layout shift culprits |
| 6 Fonts | LCP en CLS | Font display |
| 7-9 Scripts en CSS | INP, en LCP via blokkerende bestanden | Third parties, Render-blocking requests, Reduce unused CSS (Lighthouse-diagnose) |
| 10 Browsercaching | Herhaalbezoeken | Use efficient cache lifetimes |
| 11-12 Back/forward-cache en vooruit laden | LCP in de velddata: terugnavigatie uit de bfcache telt als bijna direct; vooraf ophalen (prefetch) haalt de wachttijd op de server weg | Page didn't prevent back/forward cache restoration (Lighthouse-diagnose) |
De meeste namen staan in het overzicht van de performance insights; de twee met 'Lighthouse-diagnose' zijn losse Lighthouse-controles.
Veelgemaakte fouten
- Drie optimalisatieplugins tegelijk. Ze doen hetzelfde werk dubbel, bijten elkaar en breken formulieren of menu's. Kies er één.
- Alles tegelijk aanpassen. Wijzig per stap en meet opnieuw, anders weet je niet wat werkte of wat iets stukmaakte.
- Afbeeldingen comprimeren maar niet verkleinen. Een goed gecomprimeerde foto van 2.400 pixels breed is op een telefoon nog steeds veel te groot.
- Een lange cacheduur zonder versie in de bestandsnaam. Bezoekers houden dan na een wijziging je oude CSS en JavaScript.
- Optimaliseren en daarna niets meer controleren. Elke nieuwe plugin, tag of embed kan de winst weer tenietdoen.
Als het thema zelf de rem is
Blijft de LCP op mobiel na ingreep 1 tot en met 9 boven 2,5 seconde, en laadt het thema op elke pagina tientallen CSS- en JS-bestanden, dan haal je de rest alleen met een nieuw thema of herbouw.
Die herbouw doen we als maatwerk binnen een SEO-traject; zie de Maatwerk-optie bij onze SEO-pakketten en prijzen. We starten met een SEO-audit, zodat de keuze voor herbouw op metingen rust. Snelheid is één onderdeel van technische SEO.
Veelgestelde vragen
Hoe test ik hoe snel mijn website is?
Voer je URL in bij PageSpeed Insights en kijk eerst naar de velddata bovenaan: dat zijn metingen bij echte bezoekers. Heeft je site te weinig verkeer voor velddata, dan heb je alleen de test eronder. Gebruik die om oorzaken te vinden, niet als eindcijfer.
Wat is een goede laadtijd voor een website?
Een goede laadtijd: de hoofdinhoud staat bij 75% van de bezoeken binnen 2,5 seconde in beeld (LCP), en de server antwoordt binnen 0,8 seconde (web.dev). Voor de totale laadtijd van je website bestaat geen officieel getal: een tool die een 'volledig geladen'-tijd meldt, telt ook scripts mee waar de bezoeker niets van merkt.
Welke plugin maakt mijn WordPress-site sneller?
Draait je host op LiteSpeed, gebruik dan LiteSpeed Cache; anders de cache van je host of een betaalde plugin als WP Rocket. Voor AVIF en WebP bijvoorbeeld ShortPixel of Imagify. Nooit twee caching-plugins tegelijk, en geen plugin haalt zware scripts van derden weg of repareert een log thema.
Heeft een CDN zin als al mijn bezoekers in Nederland zitten?
Ja: het gaat om ontlasten, niet om afstand. Je eigen server hoeft dan alleen nog HTML te maken; pagina's met inlog of winkelmand horen niet in de gedeelde cache.
Maakt een snellere website mijn SEO beter?
Een beetje, en vooral indirect. Google gebruikt Core Web Vitals in de ranking, maar toont de meest relevante pagina ook als de pagina-ervaring minder is (Google Search Central). Het grootste effect is dat minder bezoekers afhaken voordat de pagina er staat. Meer hierover in wat Google zegt over Core Web Vitals en ranking.
Hoe vaak moet ik de snelheid opnieuw controleren?
Na elke nieuwe plugin, tag, embed of thema-update, en daarnaast eens per maand in het Core Web Vitals-rapport van Search Console. Velddata lopen over 28 dagen, dus een terugval zie je pas na een paar weken volledig.