Websitecache & servercache: zo werkt caching in WordPress
Toen ik websitecache en servercache controleerde op een server met Nginx + Apache, liepen WordPress-paginaverzoeken in volgorde van de browser via CDN, paginacache, OPcache en Redis naar beneden en stopten ze bij de laag die een kopie had. Paginaverzoeken die rechtstreeks bij de bronserver binnenkwamen, kregen van nginx meteen het HTML-bestand dat WP Rocket had gemaakt, en gingen niet door tot PHP en de database.
Ⅰ. Opbouw van de WordPress-cache
In de informatica is een cache een techniek om gegevens tijdelijk op te slaan zodat ze snel toegankelijk zijn; op het web werkt het volgens hetzelfde principe en draagt het flink bij aan betere prestaties.
Doordat caching gegevens bewaart, hoeft er niet bij elk bezoek aan een website alles opnieuw bij de server te worden opgevraagd: opgeslagen gegevens worden snel geladen en de laadtijd van de pagina daalt. Zo vermindert de serverbelasting en verbetert de gebruikerservaring.
De caches die bij WordPress-verzoeken worden gebruikt, vallen in twee groepen uiteen: websitecache en servercache. De HTTP-cachingstandaard, zoals MDN die beschrijft, noemt een cache die alleen in de browser van één bezoeker staat een private cache, en CDN- en proxycaches die veel bezoekers delen een shared cache; in dit artikel vallen die twee samen onder websitecache.
Paginacache, OPcache en objectcache zijn caches die meedraaien in het proces waarin WordPress op de server wordt uitgevoerd. De HTTP-standaard heeft er geen eigen categorie voor; de officiële WordPress-documentatie deelt ze in als cachingplugins (paginacache), objectcache en servercache (opcode-caches zoals OPcache).
Alle toepassingsgebieden van caching staan in het artikel Cache: definitie en alle toepassingsgebieden van caching en de vier takken van prestatieoptimalisatie, caching inbegrepen, worden in het artikel Webprestatie-optimalisatie: opbouw en definitie uitgelegd.
Kies in de simulator hieronder een cache in de boom links en klik op een knop: je ziet dan op welke laag het verzoek stopt. De laag die WordPress-beheerders met een cachingplugin als eerste aanzetten, is de paginacache.
| Laag | Opslaglocatie | Wat het opslaat | Voorbeeld met Nginx + Apache |
|---|---|---|---|
| Browsercache | Apparaat van de bezoeker | HTML · CSS · JS · afbeeldingen · lettertypen | CSS · afbeeldingen 7 dagen |
| CDN · proxycache | Vóór de server (edge · reverse proxy) | Kopieën van pagina's · statische bestanden | Bunny CDN |
| Paginacache | Schijf · geheugen van de server | Door PHP gemaakte HTML | WP Rocket + nginx |
| OPcache | Servergeheugen | PHP-bytecode | PHP 8.3, JIT uit |
| Objectcache | Servergeheugen | Queryresultaten · objecten | Redis |
Ⅱ. Websitecache
Websitecache is de cache waarbij de server via responsheaders aangeeft hoe iets bewaard moet worden, waarna de browser van de bezoeker en CDN's of proxy's volgens die aanwijzing een kopie opslaan. Typische headers zijn [Cache-Control], [ETag] en [Expires]; is de bewaartermijn voorbij, dan wordt met een voorwaardelijk verzoek ([304 Not Modified]) gecontroleerd of er iets is veranderd.
1️⃣ Browsercache
Browsercache is de HTTP-cache in de webbrowser van de bezoeker. Die bewaart HTML, CSS, JavaScript, afbeeldingen en lettertypen, en als dezelfde bron opnieuw wordt opgevraagd, gaat het verzoek niet naar de server of wordt alleen gecontroleerd of er iets is veranderd.
De bewaartermijn bepaalt de server, niet de bezoeker. De Nginx + Apache-server hieronder geeft CSS en afbeeldingen 7 dagen mee en beantwoordt HTML-pagina's zonder termijn, zodat ze bij elk nieuw bezoek opnieuw worden gecontroleerd.
If-None-Match: "6ab12775-2ee8"cache-control: max-age=604800 expires: Sat, 17 Oct 2026 03:21:00 GMT etag: "6ab12775-2ee8"
etag: "6ac9298c-95575" last-modified: Fri, 09 Oct 2026 17:51:08 GMT
2️⃣ CDN · proxycache
CDN- en proxycaches zitten tussen bezoekers en de bronserver en worden door veel bezoekers gedeeld. Een forward proxy staat vooraan aan de kant van de bezoeker, zoals in een bedrijfsnetwerk; reverse proxy's en CDN's staan vóór de server en antwoorden in plaats van de bronserver met een opgeslagen kopie.
Een typische reverse proxy is Varnish Cache, en CDN's zoals Bunny CDN en Akamai volgen dezelfde opbouw. Met DNS per regio kun je bezoekers in de regio van de bronserver rechtstreeks met de bronserver verbinden, terwijl bezoekers uit andere regio's antwoord krijgen van een nabije CDN-edge (bijv. Bunny CDN) die zelfs de HTML opslaat.
De opbouw en de voordelen van een CDN worden in het artikel Wat is een CDN? Redenen om een CDN te gebruiken en 5 voordelen uitgelegd.
Ⅲ. Servercache
Servercache is de cache die meedraait in het proces waarin WordPress een pagina bouwt nadat het verzoek bij de bronserver is aangekomen. Een server met Nginx + Apache verwerkt verzoeken in de volgorde hieronder; vindt een eerdere stap een kopie, dan worden de latere stappen overgeslagen.
Bij Cloudways en ScalaHosting kun je Nginx + Apache als optie kiezen. Bij Cloudways kies je per applicatie de Hybrid stack (Nginx + Apache) of de Lightning stack (alleen Nginx), en bij ScalaHosting zet je in SPanel een instelling aan die Nginx vóór Apache plaatst.
| Cache | Wat het opslaat | Wanneer het wordt opgeslagen |
|---|---|---|
| 1️⃣ Paginacache | Afgewerkte HTML-pagina | 🅑 ⑤ Bij het antwoord slaat WP Rocket het op als bestand |
| 2️⃣ OPcache | Gecompileerde PHP-code (bytecode) | 🅑 ② Als een PHP-bestand voor het eerst draait |
| 3️⃣ Objectcache | Stukjes data zoals queryresultaten en opties | 🅑 ③ Als WordPress de gegevens voor het eerst ophaalt |
1️⃣ Paginacache
Paginacache heet ook full-page cache, en omdat het HTML opslaat, wordt het soms HTML-cache genoemd. De volledige webpagina die PHP heeft gemaakt, wordt als statisch HTML-bestand bewaard, en bij een verzoek voor dezelfde pagina wordt dat bestand verstuurd zonder PHP uit te voeren. Dit is geval 🅐 in de verwerkingsvolgorde hierboven.
Hij wordt bewaard in het servergeheugen (RAM) of op schijf (HDD/SSD): geheugen is snel maar duur en beperkt in omvang, schijf heeft ruimte genoeg maar is relatief traag.
| Type | Voorbeeld | Hoe het opslaat en antwoordt |
|---|---|---|
| Cachingplugin | WP Rocket · WP Super Cache · W3 Total Cache · Cache Enabler | WordPress slaat de pagina op als HTML-bestand en de webserver verstuurt dat bestand. |
| Webservercache | Nginx FastCGI-cache · LiteSpeed Cache | De webserver slaat het PHP-antwoord zelf op en verstuurt het bij het volgende verzoek. |
| Reverse-proxycache | Varnish | Een cacheserver vóór de webserver slaat de pagina op en antwoordt. |
Bij Nginx + Apache leest nginx het HTML-bestand van WP Rocket zelf en verstuurt het, en in de responsheader staat dan [x-rocket-nginx-serving-file: HIT]. Hoe je de paginacache met WP Rocket aanzet en instelt, wordt in het artikel WP Rocket instellen uitgelegd.
2️⃣ OPcache
OPcache slaat PHP-code die vooraf tot bytecode is gecompileerd op in het geheugen, zodat hetzelfde bestand bij een volgende uitvoering niet opnieuw door de PHP-parser hoeft. Het zit standaard in PHP sinds 5.5; APC en XCache, die vroeger werden gebruikt, ondersteunen PHP 7 niet en worden niet meer gebruikt. Dit is stap ② van 🅑 in de verwerkingsvolgorde hierboven.
| Type | Status | Uitleg |
|---|---|---|
| Zend OPcache | Standaard ingebouwd sinds PHP 5.5 | De standaard-opcodecache van nu; aanzetten met [opcache.enable=1]. |
| OPcache JIT | Sinds PHP 8 onderdeel van OPcache | Zet bytecode nog een keer om naar machinecode en voert die uit; aan- en uitzetten met [opcache.jit]. |
| APC | Ontwikkeling gestopt | De opcode-cache van vóór OPcache; de functie voor datacache leeft voort in APCu. |
| XCache | Ontwikkeling gestopt | Ondersteunt PHP 7 niet. |
| WinCache | Voor Windows-servers (IIS) | Een opcode-cache die de officiële WordPress-documentatie naast OPcache noemt. |
OPcache zet je aan met de PHP-instelling [opcache.enable=1], en de JIT die met PHP 8 is gekomen, kun je apart uitzetten met [opcache.jit=disable]. Installatie en configuratie worden in het artikel Zend OPcache: begrip, installatie en configuratie uitgelegd.
3️⃣ Objectcache
Objectcache slaat resultaten van databasequery's of berekende objecten op in een geheugenopslag zoals Redis of Memcached. Standaard onthoudt WordPress objecten alleen binnen één verzoek; pas als je een opslag zoals Redis koppelt, blijven de resultaten ook na afloop van het verzoek bestaan. Dit is stap ③ van 🅑 in de verwerkingsvolgorde hierboven.
| Type | Soort | Blijft na het verzoek bestaan? | Uitleg |
|---|---|---|---|
| WP_Object_Cache | Standaard in WordPress | Nee | Ingebouwde cache die alleen binnen één verzoek onthoudt. |
| Redis | Objectcache | Ja | Een aparte geheugenopslag, gekoppeld via de drop-in van de plugin Redis Object Cache. |
| Memcached | Objectcache | Ja | Een aparte geheugenopslag. |
| APCu | Objectcache | Ja (binnen dezelfde server) | Slaat op in het gedeelde geheugen dat PHP gebruikt. |
| Bestand | Objectcache | Ja | Slaat op als bestanden op schijf. |
| InnoDB-bufferpool | Eigen cache van de database · geen objectcache | Ja | MySQL en MariaDB houden tabelgegevens en indexen in het geheugen. |
| Querycache | Eigen cache van de database · geen objectcache | — | Verwijderd in MySQL 8.0; in MariaDB nog aanwezig, maar standaard uitgeschakeld. |
WordPress maakt verbinding met Redis via het drop-in-bestand ([object-cache.php]) dat de plugin Redis Object Cache toevoegt. De installatie wordt in het artikel Redis Cache voor WordPress installeren en instellen uitgelegd.
🔢 FAQ & aanbevolen content
ℹ️ Affiliatemelding
De content van deze site bevat affiliatelinks. Koopt een bezoeker via een van deze links een product of dienst, dan ontvangt deze site een commissie van de verkoper. Het bedrag dat de koper betaalt (bij acties gaat het omlaag ↓) wordt daardoor niet hoger. De vermelde prijzen, kortingen en voorraad gelden op het moment van schrijven en kunnen afwijken; controleer ze daarom vóór je aankoop bij de verkoper. Producten worden gekozen en beoordeeld volgens onze eigen criteria, en commissies hebben geen invloed op de volgorde of de inhoud van de beoordelingen.