Caching uitgelegd: de vijf lagen die je website snel maken

Bij Robuust regelen wij dit voor je. Caching is bij ons onderdeel van de hosting: server-side caching, Cloudflare ervoor en een cache-strategie die past bij je type site. Wil je begrijpen wat er onder de motorkap gebeurt? Lees verder.

"Zet caching aan" is het meest gegeven en slechtst begrepen snelheidsadvies op internet. Het probleem: caching is niet één ding. Het zijn vijf verschillende lagen, ze werken op verschillende plekken, en als je ze verkeerd combineert maak je je site niet sneller maar kapot, met prijzen die niet kloppen, winkelwagens die van iemand anders zijn, of wijzigingen die pas na een week zichtbaar worden.

Dit artikel legt de lagen uit in de volgorde waarin een verzoek ze tegenkomt.

Wat caching in de kern doet

Elke keer dat iemand een WordPress-pagina opvraagt, gebeurt er standaard dit: PHP start op, doet een reeks database-query's, bouwt de HTML op, en stuurt die terug. Dat kost 200 tot 800 milliseconden, voor een pagina die voor elke bezoeker identiek is.

Caching bewaart het resultaat, zodat het werk niet elke keer opnieuw hoeft. Dat is alles. De kunst zit niet in het bewaren, maar in weten wanneer je het weg moet gooien.

Laag 1: Browsercache

De cache die het dichtst bij de bezoeker zit. Je server vertelt de browser via HTTP-headers: "dit logo mag je een jaar bewaren."

De volgende keer haalt de browser het logo helemaal niet op. Nul netwerkverkeer, nul wachttijd. Voor terugkerende bezoekers is dit de snelste laag die bestaat.

De klassieke fout: een lange cachetijd op bestanden die wél veranderen. Je past je stylesheet aan, maar bezoekers zien een week lang de oude. Hun browser vraagt het bestand niet eens meer op.

De oplossing heet cache-busting: je zet een versienummer in de bestandsnaam (stijl.a7f3e9.css). Verandert het bestand, dan verandert de naam, en dan is het voor de browser simpelweg een ander bestand. Moderne frameworks doen dit automatisch; in WordPress regelen goede thema's en plugins het via een ?ver=-parameter.

Vuistregel: afbeeldingen, fonts, CSS en JS mogen lang gecachet worden (maanden tot een jaar) mits ze cache-busting hebben. HTML nooit lang.

Laag 2: CDN / edge-cache

Een Content Delivery Network zet kopieën van je bestanden in datacenters over de hele wereld. Cloudflare heeft er honderden. De bezoeker haalt het bestand op bij de locatie die het dichtst bij is, niet bij jouw server in Duitsland.

Standaard cachet Cloudflare alleen statische bestanden: afbeeldingen, CSS, JS, fonts. Je HTML wordt standaard niet gecachet: en dat is verstandig, want die bevat vaak persoonlijke elementen.

Wil je meer snelheidswinst, dan kun je ook HTML op de edge cachen. Maar dan moet je heel precies zijn over uitzonderingen (zie laag 5). Voor een brochure-website is dit een enorme winst. Voor een webshop is het een mijnenveld.

Laag 3: Paginacache op de server

Dit is wat plugins als WP Rocket, LiteSpeed Cache of W3 Total Cache doen. De eerste bezoeker van een pagina triggert het volledige PHP- en databasewerk; het resultaat wordt als kant-en-klaar HTML-bestand weggeschreven. Alle volgende bezoekers krijgen dat bestand.

Het effect is dramatisch: van 600 milliseconden naar 30. Dit is doorgaans de grootste enkele winst die je op een WordPress-site kunt boeken.

Waar het misgaat: de cache moet worden geleegd op de juiste momenten. Publiceer je een blog, dan moet niet alleen die pagina vernieuwd worden, maar ook je blog-overzicht, je homepage als daar recente posts staan, en je sitemap. Een goed geconfigureerde cacheplugin regelt dat. Een slecht geconfigureerde laat je nieuwe artikel drie dagen onzichtbaar.

Laag 4: Object- en databasecache

Laag 3 slaat hele pagina's op. Laag 4 slaat losse queryresultaten op, meestal in Redis of Memcached, in het werkgeheugen van de server.

Dit is de laag die telt wanneer paginacache níét kan werken: ingelogde gebruikers, winkelwagens, accountpagina's, filters. Elke bezoeker ziet iets anders, dus je kunt de pagina niet bewaren, maar de honderd query's die eronder liggen zijn voor iedereen hetzelfde.

Voor een brochure-site is objectcache overbodig. Voor een WooCommerce-shop of ledenportaal is het vaak het verschil tussen werkbaar en onwerkbaar.

WooCommerce zelf heeft hier een belangrijke stap gezet: sinds de introductie van High-Performance Order Storage (HPOS) worden bestellingen in eigen, geïndexeerde tabellen opgeslagen in plaats van in de algemene wp_posts-tabel. Sinds versie 10.4 (december 2025) is de bijbehorende caching-laag geen experimentele functie meer. Voor shops met veel orders is dat de meest impactvolle databasewijziging die er momenteel te maken is.

Laag 5: Wat je nooit mag cachen

Dit is de laag waar echte schade ontstaat. Cache deze nooit als statische pagina:

• Winkelwagen, afrekenen, mijn-account. Cache je die, dan kan bezoeker B de winkelwagen van bezoeker A zien. Dit gebeurt vaker dan je denkt en het is een datalek, geen bug.
• Ingelogde sessies. Alles achter een login is per definitie persoonlijk.
• Formulieren met een security-token. Contactformulieren en checkouts gebruiken nonces die verlopen. Een gecachet formulier levert onverklaarbare "verlopen sessie"-fouten.
• Voorraad en prijzen die realtime zijn. Een gecachete "nog 2 op voorraad" verkoopt producten die je niet hebt.
• Zoekresultaten en gefilterde overzichten. Technisch cachebaar, maar het aantal varianten is zo groot dat je cache vol loopt met pagina's die nooit een tweede keer worden opgevraagd.

WooCommerce en de meeste cacheplugins sluiten deze pagina's standaard uit. Controleer het toch, vooral als je een custom checkout of een aangepaste URL-structuur hebt.

De volgorde van een verzoek

Zo ziet het er samen uit:

Bezoeker
  → Browsercache        (0 ms: niets verlaat het apparaat)
  → CDN-edge            (~20 ms: dichtstbijzijnde datacenter)
  → Paginacache server  (~30 ms: kant-en-klare HTML)
  → Objectcache         (~80 ms: query's uit geheugen)
  → PHP + database      (~600 ms: volledig opbouwen)

Elke laag die een verzoek kan afvangen, bespaart alle lagen eronder. Daarom is de bovenste laag de waardevolste, en daarom is één goed geconfigureerde laag meer waard dan vier die elkaar tegenwerken.

De vier fouten die we het vaakst tegenkomen

1. Meerdere cacheplugins tegelijk. Twee plugins die allebei paginacache doen, legen elkaars cache op onvoorspelbare momenten. Kies er één.

2. Cachen zonder een leegmaak-strategie. Als je niet weet hoe je cache wordt geleegd bij een wijziging, ga je "waarom zie ik mijn aanpassing niet" debuggen. Dat is bijna altijd caching.

3. Testen met een gecachete pagina. Meet je snelheid op een pagina die net gecachet is, dan meet je je cache, niet je site. Test ook de eerste laadbeurt, want dat is wat Google's crawler en een deel van je bezoekers krijgen.

4. Caching gebruiken om een traag fundament te verbergen. Caching maakt een trage site snel voor de tweede bezoeker. Het maakt een pagina met 4 MB aan ongeoptimaliseerde afbeeldingen niet lichter, en het repareert geen database die vastloopt op een slechte query. Los eerst de oorzaak op, cache daarna.

Wat je vandaag kunt doen

1. Controleer of je paginacache actief is. Laad een pagina twee keer en kijk naar de laadtijd van de tweede. Groot verschil? Cache werkt. Geen verschil? Er is werk te doen.
2. Controleer je uitsluitingen. Log uit, leg iets in je winkelwagen, en kijk in een privévenster of je die winkelwagen daar ook ziet. Zo ja: stop en repareer dit vandaag.
3. Zet Cloudflare ervoor als dat er nog niet staat. Het CDN is gratis en levert direct winst op je statische bestanden.
4. Meet de eerste laadbeurt, niet de tweede.

Caching is geen schakelaar maar een strategie, en de juiste strategie hangt af van wat voor site je hebt. Een brochure-website mag agressief gecachet worden tot en met de HTML. Een webshop vraagt om precisie op laag 4 en 5. Behandel je ze hetzelfde, dan krijg je gegarandeerd één van de twee problemen: een site die te traag is, of een site die de verkeerde dingen laat zien.