Caching en CDN uitgelegd: waarom je site er sneller van wordt

Caching en een CDN maken je site sneller door werk en afstand te besparen.

Caching is het opslaan van een kant-en-klare kopie, zodat de volgende aanvraag die meteen krijgt.

Een CDN (Content Delivery Network) is een wereldwijd netwerk van servers dat die kopieën verspreidt.

Zo hoeft iemand in Antwerpen niet te wachten op een server in de Verenigde Staten.

Dat is de hele CDN uitleg in twee zinnen.

Het verdict: voor bijna elke zakelijke site zijn caching en een CDN geen luxe maar basis. Meestal zitten ze al in je platform, de kunst is ze goed in te stellen.

Hieronder staat in gewone taal welke caching-lagen er bestaan, hoe ze samenwerken aan laadtijd en uptime, en wanneer je er als B2B-bedrijf echt iets aan hebt.

Wat is caching in gewone taal?

Caching is het bewaren van een kopie van iets dat je net hebt gemaakt, zodat je het de volgende keer niet opnieuw hoeft te maken.

Wat er zonder cache gebeurt

Stel je voor dat je website bij elk bezoek een pagina volledig moet opbouwen. Dat zijn drie stappen:

• gegevens ophalen
• de opmaak samenstellen
• afbeeldingen klaarzetten

Dat kost tijd en rekenkracht.

Met caching doe je dat werk één keer, sla je het resultaat op en serveer je die kopie razendsnel aan iedereen die daarna langskomt.

De bakker als vergelijking

Je kan caching vergelijken met een bakker die populaire broden vooraf bakt. Hij begint niet pas zodra een klant binnenkomt.

De eerste klant wacht misschien even. Daarna gaat het veel sneller.

Kernidee: vermijd herhaald werk. Hoe vaker iets opnieuw gevraagd wordt en hoe minder vaak het verandert, hoe meer je wint met caching.

Welke caching-lagen heeft een website?

Een typische site cachet op meerdere niveaus tegelijk, elk dichter bij of verder van de bezoeker.

Die lagen werken samen, niet in plaats van elkaar. Er zijn er vier.

1. Browsercache

De browser van je bezoeker bewaart bestanden zoals je logo, lettertypes en scripts lokaal.

Bij een tweede bezoek hoeft hij die niet opnieuw te downloaden (web.dev van Google). Herhaalbezoeken voelen daardoor sneller.

Hoe lang: dat bepaal je met de header Cache-Control. Voor bestanden met een versienummer in de naam raadt web.dev max-age=31536000 aan: één jaar, het maximum.

Let op: zonder Cache-Control-header gaat caching niet uit. De browser gokt dan zelf een beleid, aldus dezelfde web.dev-pagina.

2. CDN- of edge-cache

Het CDN bewaart kopieën van je bestanden op servers verspreid over de wereld, dicht bij de bezoeker. Hierover lees je verderop meer.

3. Server- of paginacache

Op je eigen server bewaar je complete, opgebouwde pagina’s.

In plaats van een pagina telkens opnieuw samen te stellen, lever je een opgeslagen versie.

Op WordPress doet een cacheplugin precies dit. Meer daarover in een trage WordPress-site sneller maken.

4. Applicatie- en objectcache

Een tussenlaag bewaart de uitkomst van zware bewerkingen. Denk aan het resultaat van een database-query.

Zo hoeft de site die niet bij elke aanvraag opnieuw te berekenen.

Dichter bij de bezoeker is sneller

Hoe dichter de cache bij de bezoeker zit, hoe sneller het antwoord komt:

Een bestand uit de browsercache is er meteen. Een bestand van een CDN-server in de buurt is er bijna meteen.

Een pagina die je server opnieuw moet opbouwen, kost het meeste tijd.

Wat is een CDN precies?

Een CDN is een netwerk van servers verspreid over de wereld. Het bewaart kopieën van je bestanden dicht bij je bezoekers.

Het probleem: afstand

Zonder CDN staat je site op een server op een vaste plek.

Iemand ver weg moet dan wachten terwijl de gegevens fysiek die afstand afleggen.

Internet is snel, maar niet oneindig snel.

De oplossing: knooppunten dicht bij de bezoeker

Een CDN kopieert je statische bestanden naar knooppunten, vaak “edge”-servers genoemd. Het gaat om bestanden zoals:

• afbeeldingen
• lettertypes
• scripts en stylesheets

Komt er een bezoeker uit Brussel, dan levert een knooppunt in de buurt de bestanden.

Komt er iemand uit Sydney, dan doet een knooppunt daar hetzelfde.

De inhoud reist een kortere afstand. De pagina laadt dus sneller.

Waarom afbeeldingen tellen: volgens web.dev over CDN’s maken afbeeldingen ongeveer 50% uit van de overgedragen bytes op een mediane webpagina. Hoe je ze lichter maakt, staat in afbeeldingen optimaliseren voor je website.

Meer dan versnellen

Een CDN doet vaak meer dan alleen versnellen. Drie extra taken:

• Comprimeren: bestanden kleiner maken onderweg
• Beveiligen: versleutelde verbindingen afhandelen
• Afremmen: kwaadaardig verkeer tegenhouden voor het je eigen server bereikt

Dezelfde web.dev-pagina noemt nog een snelheidswinst: TLS 1.3 halveert de handshake van twee naar één roundtrip.

Dat verkort de opbouw van een verbinding met 33% voor HTTP/1 en HTTP/2.

Een CDN is zelf caching

Belangrijk om te begrijpen: een CDN is in essentie zelf een vorm van caching, alleen geografisch verspreid.

Het cachet je bestanden niet op je server of in de browser.

Het cachet ze op tientallen plekken tegelijk, zo dicht mogelijk bij wie ze opvraagt.

Meetpunt: de cache hit ratio is het aandeel aanvragen dat uit de cache komt. Web.dev noemt 90% een goed doel voor de meeste sites.

Hoe verbeteren caching en een CDN samen je laadtijd en uptime?

Samen pakken ze de twee grootste oorzaken van traagheid aan: te veel herhaald werk en te grote afstand.

Caching schrapt het herhaalde werk. Een CDN verkort de afstand.

De combinatie zorgt ervoor dat de meeste aanvragen worden afgehandeld zonder dat je eigen server zwaar werk hoeft te doen.

Wat het doet met je laadtijd

Het eerste wat verbetert, is de Time to First Byte (TTFB): de wachttijd tot de eerste byte van je server binnenkomt.

Volgens web.dev over TTFB streven de meeste sites naar 0,8 seconden of minder. Boven 1,8 seconden is de waarde slecht.

Web.dev noemt een lagere TTFB het belangrijkste voordeel van een CDN.

Dat helpt meteen je Largest Contentful Paint, de laadtijd van het grootste element.

In PageSpeed Insights zie je die opsplitsing per element. Kijk naar de eerste balk, de TTFB:

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 TTFB hoog, dan zit de winst in caching en een CDN.

Is de render delay hoog, dan zit ze in je code.

Wat het doet met je uptime

Uptime is de tijd dat je site bereikbaar is.

Vangt een CDN het grootste deel van het verkeer op vanuit zijn cache, dan krijgt je eigen server veel minder aanvragen.

Hoe je die bereikbaarheid bewaakt, lees je in website-uptime monitoren.

Pieken opvangen

Bij een plotse piek vangt het CDN die golf op, in plaats van je server te laten bezwijken.

Denk aan het verkeer na een campagne of een vermelding in de pers.

Een CDN is daar volgens web.dev van Google net goed geschikt voor.

Tip voor drukte: web.dev raadt aan om bij heel veel verkeer zelfs dynamische pagina’s kort te cachen, bijvoorbeeld 5 seconden. Dat ontlast je server sterk, terwijl de inhoud vrijwel vers blijft.

Als je server even uitvalt

Valt je oorsprongserver even uit? Dan kan een CDN in veel gevallen nog steeds een gecachte versie tonen.

Bezoekers lopen dan niet tegen een foutmelding aan.

Het standaardmechanisme daarvoor is de directive stale-if-error, beschreven in RFC 5861 (Engelstalig).

Bij een fout 500, 502, 503 of 504 mag een cache dan nog een verlopen kopie tonen, gedurende een tijd die jij instelt. Het voorbeeld uit de RFC zelf: max-age=600, stale-if-error=1200.

Dat gebeurt dus niet vanzelf. Het hangt af van hoe je je CDN instelt.

Het effect op je Core Web Vitals

Het effect is meetbaar in cijfers waar Google en je bezoekers naar kijken.

Snelle, stabiele pagina’s scoren beter op de Core Web Vitals, de signalen die de laadervaring meten.

Zo ziet dat eruit voor onze eigen site, met echte bezoekersdata op mobiel:

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.

Let op wat dit bewijst: snelle levering haalt de LCP binnen, maar lost layoutverschuiving niet op.

Dat is werk aan je opmaak, zie wat CLS is.

Wil je weten hoe je site er nu voor staat?

Een gratis test, zoals beschreven in onze uitleg over Google Lighthouse, toont waar je tijd verliest.

Waarom is dit belangrijk voor een B2B-website?

Snelheid is op een B2B-site een conversiefactor. Geen technisch detail.

Beslissers hebben weinig geduld

Je bezoekers zijn vaak beslissers met weinig geduld.

Elke seconde wachttijd vergroot de kans dat ze afhaken voor je formulier of aanbod in beeld komt.

Een site die traag laadt, ondermijnt het vertrouwen nog voor iemand een woord heeft gelezen.

Onze aanpak: we sturen klanten op leads en omzet. Laadtijd is een van de eenvoudigste hefbomen om daar winst te boeken, zonder dat je iets aan je boodschap verandert.

Mobiel en onderweg

Daar komt bij dat veel B2B-bezoek vandaag mobiel en onderweg gebeurt, waar verbindingen wisselvalliger zijn.

Net daar maken caching en een CDN het grootste verschil. Ze zijn minder afhankelijk van een perfecte verbinding met een verre server.

Meer over die mobiele bezoeker lees je in mobiele conversie op een B2B-website.

Van snelheid naar formulieren

Sneller laden zet een kettingreactie in gang:

• meer mensen zien de pagina effectief
• meer mensen klikken door
• meer formulieren worden ingevuld

Heb je een CDN altijd nodig, en moet je het zelf instellen?

Nodig? Meestal wel. Zelf instellen? Meestal niet.

Vaak zit het er al in

Veel moderne websiteplatforms en hostingpartijen leveren caching en een CDN standaard mee. Je hoeft er dan niets handmatig voor te configureren.

Bouw je op een beheerd platform, dan zit de basis er vaak gewoon in.

Het verschil tussen beheerd en zelf hosten staat in managed hosting vs zelf hosten.

Zelf gehost: een bewuste keuze

Werk je met een zelf gehoste opzet, bijvoorbeeld een eigen serverconfiguratie of een headless architectuur?

Dan is een CDN doorgaans een bewuste keuze die je toevoegt.

Hoe hosting en snelheid samenhangen, lees je in hosting en snelheid voor SEO.

Welke situatie is de jouwe?

Deze tabel vat het samen:

De valkuil: een oude kopie

Caching is krachtig. Maar het voegt complexiteit toe.

De klassieke valkuil is dat een bezoeker een oude, gecachte versie ziet nadat jij iets hebt aangepast.

Goede systemen lossen dit op met cache-invalidatie: het gericht verversen van de kopie zodra de inhoud verandert.

Web.dev beschrijft het mechanisme erachter.

Met een ETag vraagt de browser of een bestand veranderd is, en de server antwoordt met 304 Not Modified als dat niet zo is.

Laat het goed opzetten

Dat is precies het soort technisch fundament dat je beter goed laat opzetten dan achteraf herstelt.

Een snelle site bouwen draait niet om een trucje, maar om een doordachte opzet van die lagen samen.

Dat hoort bij solide webdesign en behandelen we ook in onze gids over een B2B-website laten maken.

De korte samenvatting

Caching laat je site werk hergebruiken in plaats van het bij elke bezoeker opnieuw te doen.

Dat gebeurt op vier lagen: in de browser, op een CDN, op je server en in de applicatie.

Een CDN is een wereldwijd netwerk dat kopieën van je bestanden dicht bij de bezoeker bewaart.

Het resultaat: samen verlagen ze je laadtijd, vangen ze pieken op en houden ze je site stabieler.

Voor een B2B-site betekent dat meer bezoekers die blijven en converteren.

Wil je weten of jouw site dit fundament goed benut? Neem contact op en we bekijken je TTFB en cache-instellingen samen.