Page speed met een klein budget: de optimalisaties die het meest uitmaken

De optimalisaties die het meest uitmaken

Als Core Web Vitals-consultant krijg ik veel verschillende aanvragen voor pagespeed-hulp. En ja, soms is er weinig budget. Is dat zo, dan moet ik extra efficiënt met mijn tijd omgaan. Ik doe dan alleen optimalisaties met veel impact en weinig moeite die de Core Web Vitals echt in beweging krijgen.

Laatst gecontroleerd door Arjen Karel in maart 2026

De cijfers spreken voor zich. Volgens de 2025 Web Almanac haalt slechts 48% van de mobiele origins alle drie de Core Web Vitals. De mediane mobiele pagina weegt 2,6 MB, met 632 KB aan JavaScript (waarvan 251 KB ongebruikt). Dit zijn problemen die je prima fixt zonder groot budget.

Core Web Vitals TIP: Mijn On-Call Consultancy is de meest budgetvriendelijke manier om hulp van een expert te krijgen. Boek een sessie van 2 uur (€300) en ik analyseer je Core Web Vitals-problemen, fix de meest urgente knelpunten en geef je een duidelijke strategie voor de rest. Ik bereid me vooraf voor, dus we verspillen geen tijd.

Boek een sessie!

1. Breng eerst de problemen in kaart

Optimaliseer je web performance met een klein budget, dan moet je zeker weten dat je zo effectief mogelijk te werk gaat. We moeten dus eerst weten wat het echte probleem is.

Met het uitstekende, gratis PageSpeed Insights vraag je de CrUX-data op. Die CrUX-data is de enige databron die ertoe doet, want dat is de databron die Google gebruikt.

Onder de CrUX-score zie je een Lighthouse-audit.

Laat ik duidelijk zijn over de Lighthouse-audit: op dit moment maakt Lighthouse niets uit. Waarom? Omdat het de Core Web Vitals niet meet. Zeker, Lighthouse is een geweldige testtool en loop gerust alle suggesties na. Maar met een klein budget draait het om slagen voor de Core Web Vitals. Slagen voor synthetische tests boeit nu even niet!

Terug naar de CrUX-data. Dit zijn de richtlijnen als je met een klein budget werkt. Onderzoek de Core Web Vitals in precies deze volgorde en pak deze knelpunten als eerste aan!

• Haal je de Time to First Byte niet, fix die dan als eerste!
• Haal je de First Contentful Paint niet, fix dan de render blocking resources (defer scripts en optimaliseer styles)
• Haal je de Largest Contentful Paint niet, prioriteer dan resources die je nodig hebt voor die LCP (zoals fonts of afbeeldingen)
• Haal je de CLS niet, geef alle afbeeldingen dan een width en height, spoor CSS-transitions op en verwijder ze, en reserveer ruimte voor laat renderende elementen (zoals advertenties, productfilters, etc.)
• Haal je de Interaction to Next Paint niet, dan gebruik je hoogstwaarschijnlijk te veel JavaScript op het verkeerde moment. Verwijder overbodige scripts en plugins en gebruik een RUM-tool zoals CoreDash om de traagste scripts te vinden

2. Optimaliseer je afbeeldingen

Volgens de 2025 Web Almanac zijn afbeeldingen goed voor 911 KB van de mediane mobiele pagina. Dat is meer dan een derde van het totale paginagewicht. En 57% van de LCP-afbeeldingen wordt nog altijd als JPG geserveerd, terwijl WebP bij dezelfde kwaliteit kleiner is. Met een klein budget levert het optimaliseren van afbeeldingen je de meeste impact op voor de minste moeite.

Converteer afbeeldingen gratis naar WebP

Er zijn volop gratis tools en plugins beschikbaar waarmee je afbeeldingen converteert naar nieuwere, snellere en modernere formaten zoals WebP. Voor WordPress raad ik bijvoorbeeld het uitstekende en gratis WebP Express aan.

Implementeer lazy loading

Lazy loading geeft de browser een seintje dat een afbeelding pas geladen hoeft te worden als deze bijna in de zichtbare viewport staat. Staan er 15 afbeeldingen op een pagina en zijn er maar 3 direct zichtbaar, dan kun je gerust loading="lazy" toevoegen aan de afbeeldingen buiten de zichtbare viewport.

Dit kun je op 2 manieren aanpakken. De eerste is lazy loading aanzetten in je CMS. Daarmee krijgt elke afbeelding lazy loading. Kijk daarna in de documentatie hoe je lazy loading weghaalt bij afbeeldingen die direct zichtbaar en belangrijk zijn. De andere manier is om loading="lazy" handmatig toe te voegen aan afbeeldingen below-the-fold. Voor een complete handleiding lees je hoe je offscreen afbeeldingen uitstelt.

<img loading="lazy" src="image.jpg" width="800" height="600">

Stel de fetchpriority van de afbeelding in

Met fetchpriority="high" op een img-tag geef je de browser een seintje dat deze afbeelding belangrijker is dan andere afbeeldingen en als eerste gedownload moet worden. Er zijn betere manieren zoals image preloading en 103 Early Hints, maar fetchpriority instellen is simpel, snel en effectief! Bepaal gewoon wat de belangrijkste afbeelding op je pagina is, pas het template aan en zet fetchpriority="high" op de afbeelding:

<img fetchpriority="high" src="image.jpg" width="800" height="600">

3. Fix je browser caching

Gebruik je budgethosting, dan is de webserver waarschijnlijk niet optimaal geconfigureerd. Een fout die ik regelmatig tegenkom is verkeerd geconfigureerde browser caching. Zonder de juiste caching-headers downloaden terugkerende bezoekers dezelfde afbeeldingen, scripts en stylesheets telkens opnieuw. Dat is zonde van de bandbreedte en van de tijd.

Gebruik je Apache als webserver, maak dan een bestand met de naam .htaccess aan in de root directory van je website en voeg deze regels toe:

<FilesMatch "\.(ico|pdf|jpg|jpeg|png|webp|gif|css|js|woff|woff2)$">
  <IfModule mod_headers.c>
    Header set Cache-Control "max-age=172800, public, must-revalidate"
  </IfModule>
</FilesMatch>

Als je toch bezig bent in het .htaccess-bestand, zet dan meteen GZIP-compressie aan. Dit comprimeert tekstuele resources (HTML, CSS, JavaScript) voordat ze naar de browser gaan. Op de meeste sites scheelt dit 60 tot 80% in transfer size.

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
  AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>

Gebruik je een andere webserver zoals NGINX, neem dan contact op met je hostingprovider en verwijs ze naar dit artikel!

4. Overweeg Cloudflare (zelfs het gratis plan helpt)

Zelfs op het gratis plan biedt Cloudflare al veel van de belangrijkste performance-features. Zit je op budgethosting, dan is je DNS omzetten naar Cloudflare een van de aanpassingen met de meeste impact en de minste moeite. Bekijk voor een uitgebreid stappenplan de complete Cloudflare-configuratiegids.

Op het gratis plan

1. Snelle DNS. De DNS-servers van Cloudflare zijn gratis en presteren waarschijnlijk een stuk beter dan de DNS-servers van je budgethoster. CrUX-data uit de 2025 Web Almanac laat zien dat slechts 44% van de mobiele origins een goede TTFB heeft. Trage DNS is een veelvoorkomende oorzaak, en overstappen op Cloudflare fixt dat direct.
2. HTTP/3 en Brotli. Cloudflare gebruikt de nieuwste protocollen en de snelste compressiemethoden. Zonder al te diep op de details in te gaan: dit maakt je netwerk minimaal 10% sneller.
3. Consistente browser caching. Cloudflare heeft een sterke reputatie als het gaat om het cachen van statische resources. De out-of-the-box configuratie is waarschijnlijk al beter dan wat je nu hebt.
4. Edge caching voor statische resources. Cloudflare cachet versies van je statische resources zoals afbeeldingen, scripts en CSS-bestanden en serveert ze direct aan de eindgebruiker vanaf hun edge network. Daardoor zijn er geen round trips meer nodig naar je origin server.
5. Rocket Loader. Rocket Loader deferrt het laden van scripts en vangt de complicaties op die daarbij ontstaan. Het is een botte methode, maar lukt het je niet om scripts handmatig te deferren, dan verbetert dit waarschijnlijk paint metrics zoals Largest Contentful Paint. Let op: Rocket Loader gebruikt verouderde browser-API's en PageSpeed Insights kan hier waarschuwingen over geven. Zie je die waarschuwingen, overweeg dan om je scripts alsnog handmatig te deferren.

Op het Pro-plan

Zie ik een gratis Cloudflare-plan, dan zeg ik vrijwel meteen: "go pro!". Kun je die $ 25 missen en wil je dat uitgeven aan een snellere site, overweeg het dan zeker.

1. Alle gratis features. Uiteraard bevat het Pro-plan alle gratis features.
2. Cloudflare APO voor WordPress. APO voor WordPress is een complete tool die je pagina's op het edge network cachet wanneer bezoekers niet zijn ingelogd. Dit kan de Time to First Byte enorm versnellen.
3. Lossless en lossy afbeeldingoptimalisatie. Een van de grootste voordelen van de Pro-versie van Cloudflare is hun optimalisatie van afbeeldingen. Cloudflare converteert en cachet afbeeldingen in WebP-formaat en serveert ze alleen aan bezoekers van wie de browser dit formaat ondersteunt.

5. Self-host zoveel mogelijk

Nog een simpele en effectieve optimalisatie is het self-hosten van statische resources. Op veel sites staan statische resources op externe CDN's. Zo staat jQuery op https://code.jquery.com/, Bootstrap op https://cdn.jsdelivr.net en je fonts op https://fonts.googleapis.com. Ik snap de aantrekkingskracht. Die CDN's presenteren zich als snel en makkelijk, maar ze gebruiken is eigenlijk een slecht idee. Het maakt je site juist trager.

Het idee achter een gedeeld CDN voor dit soort bestanden klopte vroeger wel, toen browsers deze bestanden nog over verschillende websites heen konden delen. Die tijd is voorbij. Daardoor moet een nieuwe bezoeker het statische bestand altijd downloaden, en is er voor elk bestand een nieuwe verbinding met een nieuwe server nodig. En die nieuwe verbindingen naar die nieuwe servers kosten flink wat extra tijd.

De oplossing is simpel: self-host die third-party bestanden. Download het bestand, zet het op je eigen server en pas de verwijzing naar het bestand aan. Specifiek voor fonts lees je hier hoe je Google Fonts zelf host.

6. Defer je scripts

Blokkerende scripts in de head van de pagina kunnen een enorm knelpunt zijn. Deze scripts vertragen het laden van de pagina soms wel met 20 seconden! Uit de 2025 Web Almanac blijkt dat slechts 15% van de mobiele pagina's slaagt voor de audit voor render blocking resources. Dat laat wel zien hoe wijdverspreid dit probleem is.

Die scripts deferren is helemaal niet moeilijk. Voeg gewoon defer toe aan de script-tag en je bent klaar. Kun je dit doen, doe het dan! Pas het template aan en verander je script zo:

<!-- oude blokkerende script-tag -->
<script src="script.js"></script>

<!-- nieuwe deferred script-tag -->
<script defer src="script.js"></script>

Maar er zitten haken en ogen aan! Defer toevoegen aan script-tags kan allerlei problemen en dependency-fouten veroorzaken. En met een klein budget ga ik ervan uit dat je geen JavaScript-expert kunt inhuren om elk probleem te fixen. Probeer je scripts dus te deferren en controleer op fouten (druk op Ctrl+Shift+I in Chrome en kijk in het tabblad Console). Zie je na het testen geen fouten, dan hoor je bij de weinige gelukkigen! Krijg je wel foutmeldingen, wijk dan uit naar een van de volgende opties. Voor het complete overzicht bekijk je 16 methoden om JavaScript te deferren.

Gebruik Rocket Loader

Zoals gezegd krijg je in de gratis versie van Cloudflare toegang tot Rocket Loader. Dit deferrt alle scripts op een pagina. Het is absoluut niet perfect, maar meestal doet het zijn werk heel behoorlijk.

Gebruik een plugin

De meeste CMS-sites hebben een enorm plugin-aanbod. Er zijn volop plugins waarmee je JavaScript deferrt en die alle complicaties opvangen die bij het deferren van scripts komen kijken.

7. Optimaliseer je fonts

Webfonts zijn een verborgen kostenpost voor de performance van budgetsites. De mediane pagina laadt volgens de 2025 Web Almanac 122 KB aan font-bestanden. Laad je fonts via Google Fonts, dan kost elk eerste bezoek extra DNS-lookups en TCP-verbindingen.

Twee gratis fixes:

1. Self-host je fonts. Download de font-bestanden, zet ze op je eigen server en laad ze daarvandaan. Dit scheelt de overhead van verbindingen naar fonts.googleapis.com en fonts.gstatic.com.
2. Voeg font-display: swap toe. Dit vertelt de browser om tekst direct in een fallback-font te tonen terwijl het webfont downloadt. Je bezoekers zien content sneller en je voorkomt het probleem van onzichtbare tekst. Bekijk voor de volledige strategie hoe je onzichtbare tekst tijdens het laden van webfonts fixt.

8. Caching, caching, caching

Heb je een klein budget en wil je niet veel uitgeven aan hosting, dan is caching een van de meest effectieve manieren om een website sneller te maken. Caching werkt vooral goed tegen een hoge Time to First Byte. Cachen kan op verschillende niveaus.

Client side cache: Configureer je webserver zodat browsers de opdracht krijgen zoveel mogelijk statische resources te cachen. Dit vermindert de belasting van je server. (Zie het .htaccess-voorbeeld in punt 3.)

Object cache: Een object cache gebruik je om data op te slaan die veel rekenkracht kost om opnieuw op te bouwen, zoals de uitkomst van complexe database-queries. Vraag je hoster om Redis of Memcached te installeren.

Full page cache: Gebruik je een CMS, dan wil je waarschijnlijk een full page cache toevoegen aan je site. Voor WordPress zijn WP Fastest Cache of WP Core Web Vitals goede opties.

9. Maak strategische keuzes voor je hosting

Bij hosting loont het om goed rond te kijken: de duurste hoster is lang niet altijd de snelste. Over het algemeen zoek je een hostingpakket dat geoptimaliseerd is voor jouw CMS, want wie van alle markten thuis probeert te zijn, blinkt nergens in uit. Kies minimaal voor hosting met PHP 8+, HTTP/2 en SSD-opslag. Een goede WordPress-hoster met die basis presteert altijd beter dan een generieke shared host.

10. Monitor je performance

Al die optimalisaties zijn niets waard als je niet weet of ze echt gewerkt hebben. Richt Real User Monitoring in, zodat je ziet hoe echte bezoekers je site ervaren, en niet alleen hoe Lighthouse scoort in een lab. Lab-scores zijn nuttig bij het debuggen, maar field data van echte bezoekers is wat Google gebruikt voor je ranking. CoreDash trackt de Core Web Vitals van echte gebruikers en laat je precies zien waar je staat.