Website sneller maken: praktische checklist voor laadtijd

Je website sneller maken doe je in vaste volgorde: eerst meten, dan de zwaarste posten.

Die zware posten zijn je server, je afbeeldingen, je scripts en je third-party tools.

Pas daarna check je de fijnafstelling, zoals fonts en caching.

Het verdict: wie willekeurig begint te sleutelen, wint zelden iets blijvends. Wie de checklist hieronder van boven naar onder afwerkt, ziet zijn laadtijd doorgaans flink dalen.

De volgorde in één beeld:

*Werk van zwaar naar licht: meet eerst, pak dan de zwaarste posten aan en eindig bij de fijnafstelling.*

Waarom is snelheid belangrijk voor een B2B-website?

Omdat een trage site je leads kost voor ze je aanbod zien.

Een snelle site is geen technisch pluspunt maar een omzetfactor.

Elke seconde extra laadtijd kost je bezoekers die afhaken, en in B2B betekent dat verloren leads.

Een trage site kost ook vertrouwen.

Als de eerste indruk hapert, twijfelt een prospect aan de rest.

Wat Google erover zegt

Snelheid weegt bovendien mee in hoe Google je pagina’s beoordeelt.

De Core Web Vitals worden volgens Google gebruikt door zijn ranking-systemen.

Het echte argument is eenvoudiger.

Een bezoeker die snel vindt wat hij zoekt, blijft langer en converteert vaker.

Snelheid is dus een hefboom voor een website die leads genereert, niet een doel op zich.

Ze is ook een vast onderdeel van goede user experience.

De drempels die je moet halen

Google zet per meetpunt een grens voor een goede ervaring.

Volgens web.dev zijn dat deze:

Google meet die grens op het 75e percentiel van alle paginabezoeken, apart voor mobiel en desktop.

Concreet: 3 op de 4 bezoeken moeten onder de grens blijven.

Hoe meet je je laadtijd voordat je begint?

Met een nulmeting op mobiel, voor je ook maar één instelling aanpast.

Begin nooit met optimaliseren zonder nulmeting. Anders weet je achteraf niet of je iets hebt opgelost.

Drie gratis tools volstaan

• PageSpeed Insights: plak je URL en je krijgt scores plus concrete knelpunten, de zwaarste bovenaan.
• Lighthouse: ingebouwd in Chrome (onder de developer tools), handig om herhaaldelijk te testen tijdens het werk. Meer in Google Lighthouse uitgelegd.
• Google Search Console: toont hoe je hele site presteert bij echte bezoekers, niet alleen in een labtest.

Lees de velddata

Test altijd op mobiel, want daar is de ervaring het zwaarst en het verkeer vaak het grootst.

Zo ziet een mobiele meting eruit in PageSpeed Insights, voor onze eigen site:

Onze eigen mobiele velddata in PageSpeed Insights, oktober 2026. LCP is goed (1,9 s), maar één zwak meetpunt (CLS 0,13) laat de beoordeling falen.

Onze LCP van 1,9 seconden zit ruim onder de grens van 2,5. Onze CLS van 0,13 zit erboven.

Eén zwak meetpunt volstaat dus om de hele beoordeling te laten falen. Naast de drempels gezet:

Onze mobiele velddata van oktober 2026 naast de drempels van web.dev. LCP haalt de grens, CLS niet.

Tip: noteer je startwaarden, zodat je elke ingreep kan afmeten aan de nulmeting.

Hoe versnel je je server en hosting?

Door de basis eerst op orde te zetten: hosting, CDN, compressie en caching.

Je server bepaalt hoe snel de eerste byte bij de bezoeker aankomt. Die basis kan je niet wegoptimaliseren met trucjes erbovenop.

Loopt je hosting achter? Begin dan daar.

Kijk eerst naar de opsplitsing

PageSpeed Insights splitst je LCP op in onderdelen. Zo zie je of de server de rem is:

LCP-opsplitsing in PageSpeed Insights voor een van onze eigen artikels, labtest op mobiel, oktober 2026. Hoge TTFB wijst op de server, hoge render delay op CSS en scripts.

Is de time to first byte hoog? Lees dan eerst TTFB verbeteren.

Loop deze punten na

• Kies hosting die past bij je verkeer. Goedkope gedeelde hosting deelt capaciteit met veel andere sites en wordt traag op piekmomenten. Voor een B2B-site weegt betrouwbare snelheid zwaarder dan een paar euro per maand.
• Zet een CDN op. Een content delivery network bewaart kopieën van je site op servers wereldwijd. Bezoekers krijgen de versie die het dichtst bij hen staat.
• Schakel server-side compressie in. Met Brotli of Gzip verstuurt je server bestanden in compacte vorm. Beide worden breed ondersteund door moderne browsers en zijn vaak met een enkele instelling aan te zetten.
• Gebruik caching. Laat de browser statische bestanden lokaal bewaren, zodat terugkerende bezoekers ze niet telkens opnieuw downloaden.

Een CDN scheelt vooral als je publiek geografisch verspreid zit. Hoe caching en een CDN samenwerken, lees je in caching en CDN uitgelegd.

Wat hosting met SEO te maken heeft

Welk platform je ook gebruikt, deze laag is meestal het eerste waar serieuze winst zit. Het verband met je posities staat in hosting, snelheid en SEO.

Wil je dat goed inrichten bij een nieuwe of vernieuwde site? Bekijk dan hoe wij je professionele website laten maken.

Hoe optimaliseer je afbeeldingen en assets?

Door elke afbeelding kleiner, moderner en op de juiste maat aan te leveren.

Afbeeldingen zijn op de meeste sites veruit de zwaarste post, dus hier ligt vaak de snelste winst. Een homepagina vol ongecomprimeerde foto’s laadt traag, hoe goed je server ook is.

De checklist voor je beeld

• Comprimeer elke afbeelding voor je ze uploadt. Veel sites tonen beelden die veel groter zijn dan nodig.
• Gebruik moderne formaten zoals WebP of AVIF. Die leveren vergelijkbare kwaliteit bij een kleiner bestand en worden inmiddels breed ondersteund. Houd voor de laatste procenten bezoekers een JPEG of PNG als fallback achter de hand.
• Schaal beelden op de juiste afmetingen. Toon geen foto van 3000 pixels breed in een vak van 600 pixels. Lever de maat die je echt nodig hebt.
• Stel responsive afbeeldingen in zodat mobiele bezoekers een lichtere versie krijgen dan desktopgebruikers.
• Laad afbeeldingen onder de vouw lui in met het attribuut loading="lazy".

Met lazy loading haalt de browser een beeld pas op wanneer de bezoeker er bijna is, in plaats van alles meteen. Volgens web.dev werkt dat attribuut in alle grote browsers.

Geef beelden vaste afmetingen

Geef beelden ook een vaste breedte en hoogte mee. Dan verspringt de pagina niet tijdens het laden.

Dat houdt je layout stabiel en je bezoeker rustig.

Een verspringende layout zie je in Search Console terug als CLS-probleem. Bij ons ging het om 349 mobiele URL’s:

Het Core Web Vitals-rapport in onze eigen Search Console, oktober 2026. Het probleem zit in layoutverschuiving, niet in het platform.

Meer technieken per formaat vind je in afbeeldingen optimaliseren voor je website.

Hoe verklein je de impact van fonts?

Met minder fonts, in WOFF2 en met font-display: swap.

Lettertypes lijken klein, maar ze kunnen je tekst onzichtbaar houden tot het font geladen is. Een paar gerichte ingrepen halen die rem weg:

• Beperk het aantal fonts en gewichten. Elk extra lettertype en elke extra dikte is een apart bestand. Twee fonts en een handvol gewichten volstaan meestal ruim.
• Overweeg je fonts zelf te hosten in plaats van ze bij een externe dienst op te halen. Dat scheelt een verbinding naar een ander domein, maar de winst is niet gegarandeerd. Volgens web.dev is zelf hosten meestal pas sneller met een CDN en HTTP/2, en subsetting en compressie regel je dan zelf.
• Gebruik moderne fontbestanden zoals WOFF2, die compacter zijn dan oudere formaten.
• Zet font-display: swap. Dan toont de browser meteen een systeemletter en wisselt naar je eigen font zodra het klaar is.

Zo blijft je tekst direct leesbaar. Ook als het font nog binnenkomt.

Hoe houd je scripts en code licht?

Door minder code te laden, en de rest later.

Zware JavaScript en CSS laten de browser werken voor de bezoeker iets kan doen. Dat voelt traag aan, zelfs als de pagina visueel al staat.

Vier ingrepen

• Verwijder code die je niet gebruikt. Oude plugins, ongebruikte libraries en restjes van vorige projecten stapelen onnodig gewicht op.
• Minify je bestanden. Spaties en commentaar weghalen maakt JavaScript en CSS kleiner zonder de werking te veranderen.
• Stel uit wat niet meteen nodig is. Laad scripts die niet boven de vouw nodig zijn later, met defer of async, zodat ze het tekenen van de pagina niet blokkeren.
• Bundel verstandig. Te veel losse bestanden betekent te veel verzoeken, te grote bundels laden traag. Zoek de balans.

Een headless of modern opgezette site helpt die ballast te beperken.

Bij WordPress

Op WordPress zit het gewicht vaak in plugins. Lees te veel WordPress-plugins of de gerichte aanpak in een trage WordPress-site sneller maken.

Veel van dit werk gebeurt onder de motorkap en vraagt een ontwikkelaar die weet wat hij weglaat.

Het loont. Zware scripts zijn vaak de stille reden waarom een simpele pagina toch traag aanvoelt.

Hoe beperk je de schade van third-party tools?

Door alleen de externe tools te houden die aantoonbaar iets opleveren.

Externe scripts zijn de meest onderschatte rem op een B2B-site. Elke tracker, chatwidget of embed laadt code van een ander domein waar jij geen controle over hebt.

Ze sluipen er ongemerkt bij. Tool per tool.

Wat je kan doen

• Inventariseer wat er echt draait. Analytics, advertentiepixels, chatbots, video’s, A/B-testtools: tel ze op en vraag je bij elk af of het zijn gewicht waard is.
• Schrap wat niemand gebruikt. Veel sites slepen tracking mee van campagnes die allang voorbij zijn.
• Laad zware embeds pas op interactie. Toon bijvoorbeeld een afbeelding met een afspeelknop in plaats van een volledige videospeler.
• Houd nieuwe tools kritisch tegen het licht. Elke marketingtool kost een beetje snelheid. Weeg dat af tegen wat hij oplevert.

Dit is bij uitstek het punt waar de afweging telt. Een tool die geen aantoonbare leads oplevert maar wel je site vertraagt, kost je netto klanten.

Stel bijvoorbeeld dat je site nog een chatwidget, twee advertentiepixels en een heatmaptool laadt. Vraag dan per tool: wie kijkt hier nog naar, en wat leverde het op?

Welke volgorde werkt het best?

Van zwaar naar licht, met een meting na elke stap.

Wil je per meetpunt dieper gaan? Lees dan Core Web Vitals verbeteren.

De korte samenvatting

Je website sneller maken is geen kwestie van een wondermiddel, maar van een checklist in de juiste volgorde.

Meet eerst met PageSpeed Insights of Lighthouse. Pak dan de zwaarste posten aan:

• een degelijke server met compressie en caching
• gecomprimeerde afbeeldingen in moderne formaten
• lichte fonts
• opgeschoonde scripts
• alleen de third-party tools die hun gewicht waard zijn

Werk van zwaar naar licht. Meet na elke ingreep opnieuw.

Het doel blijft hetzelfde als bij alles wat we bouwen: niet een snelle site om de snelheid, maar een site die bezoekers vasthoudt tot ze contact opnemen.

Snelheid is een hefboom voor leads, geen pluim voor de techneut. Hoe dit past in een site die je hele groei moet dragen, lees je in onze gids om een B2B-website te laten maken.

Veelgestelde vragen

Waar begin ik als ik mijn website sneller wil maken?

Bij een nulmeting op mobiel met PageSpeed Insights of Lighthouse.

Daarna pak je de zwaarste posten aan: server, afbeeldingen, scripts en third-party tools.

Is nieuwe hosting genoeg om mijn site sneller te maken?

Zelden.

Een trage server remt alles, maar de grootste winst zit meestal in afbeeldingen, scripts en externe tools.

Kijk in de LCP-opsplitsing of de server echt de rem is.

Welke laadtijd is goed genoeg?

Volgens web.dev verschijnt de grootste inhoud best binnen 2,5 seconden, reageert de pagina binnen 200 milliseconden en verspringt de layout niet meer dan 0,1.

Loopt je site nog altijd achter?

Haal je het niet opgelost met deze lijst? Wij brengen in kaart wat je site vertraagt en lossen het op bij de wortel.

Neem contact op