Elke milliseconde telt. Full page caching is een van de krachtigste manieren om je WordPress-site te versnellen - maar de manier waarop je het implementeert maakt een wereld van verschil. Kies je voor caching op serverniveau met NGINX, of gebruik je een WordPress-plugin zoals WP Super Cache of W3 Total Cache? Beide aanpakken hebben hun eigen voordelen en beperkingen.
In deze vergelijking ontdek je precies hoe beide methoden werken, wanneer je welke kiest en waar de valkuilen liggen. We bouwen voort op de kennis uit eerdere artikelen over wat er tijdens een WordPress request gebeurt en hoe je performance bottlenecks herkent en meet.
Wat doet full page caching precies?
Zonder caching doorloopt elke bezoeker het volledige WordPress-proces: PHP-bootstrap, plugin-initialisatie, database-queries, template-rendering en uiteindelijk HTML-output. Dat kost al snel 200 tot 800 milliseconden - of meer op drukke sites.
Full page caching slaat die gegenereerde HTML op. Bij het volgende bezoek wordt de opgeslagen versie direct uitgeleverd, zonder dat WordPress opnieuw hoeft te draaien. Het resultaat: laadtijden die dalen van honderden milliseconden naar enkele milliseconden.
Dit verschilt fundamenteel van object caching met Redis, dat individuele database-resultaten in het geheugen bewaart. Full page caching werkt op een hoger niveau: de complete pagina wordt als geheel gecacht.
Hoe werkt NGINX full page caching?
NGINX is een webserver die voor WordPress staat. Met de FastCGI Cache-module kan NGINX de volledige HTML-response opslaan voordat het verzoek ooit bij PHP aankomt.
Het proces in stappen
- Een bezoeker vraagt een pagina op
- NGINX controleert of er een gecachte versie beschikbaar is
- Cache hit: NGINX stuurt de opgeslagen HTML direct terug - PHP wordt niet gestart
- Cache miss: het verzoek gaat door naar PHP-FPM en WordPress, de response wordt opgeslagen voor volgende verzoeken
Het cruciale verschil: bij een cache hit komt WordPress er niet aan te pas. Geen PHP, geen database, geen plugins. NGINX handelt alles af op het niveau van de webserver zelf.
Typische configuratie
Een basis FastCGI Cache-configuratie ziet er als volgt uit:
fastcgi_cache_path /var/cache/nginx levels=1:2
keys_zone=wordpress:100m inactive=60m;
server {
set $skip_cache 0;
# Niet cachen voor ingelogde gebruikers
if ($http_cookie ~* "wordpress_logged_in") {
set $skip_cache 1;
}
# Niet cachen voor POST-verzoeken
if ($request_method = POST) {
set $skip_cache 1;
}
location ~ \.php$ {
fastcgi_cache wordpress;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
include fastcgi_params;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
Dit vereist SSH-toegang tot je server en kennis van NGINX-configuratiebestanden. Niet iets dat je zomaar via een WordPress-dashboard regelt.
Hoe werken WordPress caching-plugins?
Caching-plugins pakken het anders aan. Ze haken in op het WordPress-proces en slaan de gegenereerde HTML op als statische bestanden - meestal in wp-content/cache/. Bij een volgend bezoek detecteert de plugin (of een .htaccess/advanced-cache.php-bestand) dat er een gecachte versie is en serveert die.
Populaire opties
- WP Super Cache - gratis, ontwikkeld door Automattic, betrouwbaar en eenvoudig
- W3 Total Cache - uitgebreid met veel configuratiemogelijkheden, steile leercurve
- WP Rocket - betaald, zeer gebruiksvriendelijk, combineert meerdere optimalisaties
- LiteSpeed Cache - gratis, maar vereist een LiteSpeed-webserver voor volledige functionaliteit
Het proces in stappen
- Een bezoeker vraagt een pagina op
- De webserver start PHP (dit is onvermijdelijk)
- Het
advanced-cache.php-bestand controleert of er een gecacht bestand bestaat - Cache hit: de plugin stuurt het opgeslagen HTML-bestand terug en stopt verdere WordPress-uitvoering
- Cache miss: WordPress draait volledig, de plugin slaat de output op voor volgende verzoeken
Let op stap 2: zelfs bij een cache hit moet PHP starten. Dat is het fundamentele verschil met NGINX caching. De overhead is klein - vaak slechts 10 tot 30 milliseconden - maar het is er.
De vergelijking: NGINX vs plugins
Snelheid
NGINX wint overtuigend op puur snelheid. Omdat de cache op webserverniveau wordt uitgelezen, is de TTFB (Time to First Byte) bij een cache hit typisch 2-10 ms. Bij een plugin-gebaseerde cache zie je eerder 20-80 ms, afhankelijk van de server en plugin.
Voor de meeste sites is dat verschil onmerkbaar voor bezoekers. Maar bij hoge bezoekersaantallen of wanneer je Core Web Vitals tot het uiterste wilt optimaliseren, telt elke milliseconde.
Configuratie en beheer
Hier scoren plugins beduidend beter. WP Super Cache of WP Rocket installeer je in een paar klikken. Cache-regels instellen, uitzonderingen definiëren, de cache legen - het gaat allemaal via het WordPress-dashboard.
NGINX-caching vereist:
- SSH-toegang tot de server
- Kennis van NGINX-configuratiesyntax
- Handmatig beheer van cache-invalidatie
- Een helper-plugin (zoals NGINX Helper) om de cache te legen vanuit WordPress
Bij elke wijziging aan je cachingregels moet je de NGINX-configuratie aanpassen en de service herladen. Een fout in de config kan je hele site platleggen.
Cache-invalidatie
Dit is waar het echt complex wordt. Wanneer je een blogpost publiceert, een pagina bijwerkt of een reactie goedkeurt, moet de cache worden vernieuwd. Anders zien bezoekers verouderde content.
Plugins handelen dit automatisch af. Ze weten wanneer WordPress content wijzigt en legen de relevante cache-bestanden. Dit werkt out-of-the-box, zonder configuratie.
NGINX heeft geen directe koppeling met WordPress. Je hebt een aanvullende plugin nodig die purge-verzoeken naar NGINX stuurt. Dit werkt goed, maar je moet het wél opzetten en testen. Edge cases - zoals een WooCommerce-product dat op prijs wijzigt - vereisen extra aandacht.
Serverbelasting
Bij hoog verkeer wint NGINX opnieuw. Omdat PHP niet wordt aangeraakt bij een cache hit, kan NGINX duizenden gelijktijdige verzoeken afhandelen met minimale CPU- en geheugenbelasting. Plugin-caching is efficiënter dan geen caching, maar vergt nog steeds PHP-resources per verzoek.
Compatibiliteit
Plugins werken op vrijwel elke hostingomgeving: Apache, NGINX, LiteSpeed, shared hosting, managed hosting. NGINX FastCGI Cache werkt alleen op - je raadt het - NGINX. En niet elke NGINX-installatie heeft de benodigde module beschikbaar, vooral op shared hosting.
Wanneer kies je NGINX caching?
NGINX-caching is de betere keuze wanneer:
- Je een VPS of dedicated server beheert met SSH-toegang
- Je site hoog verkeer verwerkt (duizenden bezoekers per uur)
- Je maximale TTFB-optimalisatie wilt bereiken
- Je team technische kennis heeft van serverconfiguratie
- Je een headless of API-gebaseerde setup draait waarbij WordPress als backend fungeert
Managed WordPress-hosts zoals Kinsta en Cloudways gebruiken NGINX-caching standaard. Als je bij zo'n host zit, profiteer je er al van zonder het zelf te configureren.
Wanneer kies je een caching-plugin?
Een plugin is de betere keuze wanneer:
- Je op shared hosting zit zonder SSH-toegang
- Je zelfstandig je site beheert zonder systeembeheerder
- Je een eenvoudige opzet wilt zonder serverkconfiguratie
- Je site een gemiddeld bezoekersaantal heeft
- Je extra optimalisaties wilt combineren, zoals CSS/JS-minificatie en lazy loading (bij WP Rocket)
Voor de meeste WordPress-sites - en zeker voor MKB-websites - biedt een goede caching-plugin precies genoeg performance-winst zonder onnodige complexiteit.
De hybride aanpak
In de praktijk zien we vaak een combinatie:
- NGINX FastCGI Cache voor full page caching van anonieme bezoekers
- Redis voor object caching van database-resultaten
- Een lichte plugin (zoals NGINX Helper) voor cache-invalidatie vanuit WordPress
Deze opzet geeft je het beste van beide werelden: de snelheid van server-level caching met het gemak van plugin-gebaseerd beheer. Het vereist wel meer technische kennis om op te zetten en te onderhouden.
Veelgemaakte fouten bij full page caching
Ongeacht welke methode je kiest, deze valkuilen zien we regelmatig:
- Dubbele caching - NGINX én een page-cache-plugin tegelijk draaien is overbodig en kan conflicten veroorzaken
- Dynamische pagina's cachen - winkelwagenpagina's, checkout-pagina's en accountpagina's mogen nooit gecacht worden
- Cache-invalidatie vergeten - je past content aan maar bezoekers zien de oude versie omdat de cache niet is geleegd
- Te agressief cachen - alles voor eeuwig cachen lijkt efficiënt, maar zorgt voor verouderde content
- Geen meting achteraf - je installeert caching maar controleert niet of je TTFB daadwerkelijk is verbeterd
Praktische aanbeveling
Weet je niet zeker welke richting je op moet? Gebruik dit als vuistregel:
Beheer je je eigen server? Kies NGINX FastCGI Cache met Redis als object cache. Voeg NGINX Helper toe voor cache-purging vanuit WordPress. Dit levert de beste prestaties met een beheersbare setup.
Gebruik je managed hosting? Controleer eerst of je host al server-level caching biedt (Kinsta, Cloudways en WP Engine doen dit standaard). Zo ja, installeer geen aanvullende page-cache-plugin - dat veroorzaakt conflicten. Voeg eventueel Redis toe voor object caching.
Zit je op shared hosting? Installeer WP Super Cache of WP Rocket. Beide werken betrouwbaar op vrijwel elke server. Combineer met een goede meetstrategie om het effect te valideren.
Veelgestelde vragen
Wat is full page caching?
Full page caching slaat de volledige HTML-uitvoer van een pagina op, zodat WordPress niet bij elk bezoek opnieuw PHP hoeft te draaien en database-queries hoeft uit te voeren. De opgeslagen versie wordt direct aan de volgende bezoeker geserveerd.
Is NGINX caching sneller dan een WordPress plugin?
Ja, NGINX caching is doorgaans sneller omdat het verzoek al op serverniveau wordt afgehandeld. WordPress wordt niet eens opgestart. Bij een plugin moet PHP nog starten voordat de cache wordt uitgelezen, wat altijd iets meer tijd kost.
Kan ik NGINX caching en een plugin tegelijk gebruiken?
Dat kan, maar het is zelden zinvol. De twee lagen cachen dan dezelfde output, wat de complexiteit verhoogt zonder merkbaar snelheidsvoordeel. Kies één aanpak en combineer die met object caching via Redis voor dynamische content.
Welke WordPress caching-plugin is het beste?
WP Super Cache is betrouwbaar en eenvoudig, W3 Total Cache biedt veel opties voor gevorderden, en WP Rocket is een populaire betaalde optie met uitstekende gebruiksvriendelijkheid. De beste keuze hangt af van je technische kennis en budget.