Wie zijn WordPress-site sneller wil maken, staat binnen vijf minuten in de cache-jungle: WP Rocket, W3 Total Cache, LiteSpeed Cache, Redis, object cache… En ergens roept ook nog iemand dat je hoster “al caching heeft”. Wat betekent dat allemaal — en wat heb je nou echt nodig?
Goed nieuws: het is overzichtelijker dan het lijkt. Er zijn maar twee smaken die ertoe doen: pagina-cache en object cache. Als je die twee snapt, prik je door elk pluginlijstje heen.
Even terug: wat caching ook alweer doet
Zonder cache bouwt WordPress elke pagina voor elke bezoeker opnieuw op: PHP start, de database wordt tientallen keren bevraagd, en pas dan rolt er HTML uit. Een cache bewaart het eindresultaat en serveert dat kant-en-klaar aan de volgende bezoeker. De basis (en waarom je soms je eigen wijziging niet ziet) legden we eerder uit in wat is caching?.
Vandaag gaan we een laag dieper: wáár die kopie wordt bewaard maakt namelijk veel uit voor de snelheid.
Plugincache vs servercache
Een klassieke cache-plugin (zoals WP Super Cache of W3 Total Cache) bewaart de kant-en-klare pagina’s als bestanden binnen je WordPress-installatie. Sneller dan niks, zeker. Maar voor elk bezoek moet er meestal alsnog een stukje PHP draaien om die kopie op te diepen.
Servercache werkt een verdieping lager: de webserver zelf bewaart de kopie en levert hem direct uit, zonder PHP er ook maar bij te halen. Dat is de snelste route die er bestaat — je site serveert dan in feite statische pagina’s.
LiteSpeed is zo’n webserver met ingebouwde cache, en hij is populair bij hostingproviders. De bijbehorende LiteSpeed Cache-plugin is dus geen cache op zichzelf, maar de afstandsbediening: de plugin vertelt de server wat gecachet mag worden en wanneer een kopie moet worden ververst (bijvoorbeeld als jij een pagina aanpast). Het zware werk doet de server.
Belangrijk detail: de LiteSpeed Cache-plugin werkt alléén als je hosting daadwerkelijk op een LiteSpeed-server draait. Installeer je hem op andere hosting, dan doet de pagina-cache simpelweg niets. Weet je het niet zeker? De plugin waarschuwt er zelf voor, en anders weet je hoster het in één seconde.
LiteSpeed Cache instellen: de veilige route
De plugin heeft tientallen opties en dat maakt hem intimiderend. Het eerlijke verhaal: voor de grootste winst hoef je bijna niets te doen.
- Installeer en activeer de plugin en zet onder Cache de hoofdschakelaar aan. Dit alleen al levert doorgaans de grootste snelheidswinst op.
- Laat de standaardwaarden staan. Ingelogde gebruikers en winkelwagen/afreken-pagina’s worden standaard níet gecachet — precies zoals het hoort.
- Blijf voorlopig af van de geavanceerde toeters: opties als ESI, kritieke CSS genereren en “guest mode” kunnen extra winst geven, maar ook je opmaak of je shop slopen. Eerst weken stabiel draaien, dan pas experimenteren — één optie tegelijk.
Pas je een pagina aan en zie je de wijziging niet? De plugin ruimt de kopie normaal zelf op, maar met de knop “Purge All” dwing je het af.
En Redis dan? Object cache uitgelegd
Pagina-cache helpt bezoekers die anonieme, “gewone” pagina’s bekijken. Maar zodra iemand inlogt of iets in een winkelwagen legt, is elke pagina persoonlijk — en dus niet als geheel te cachen. Dan moet WordPress wél naar de database, voor elke klik opnieuw.
Daar komt object cache om de hoek. Die bewaart niet hele pagina’s, maar de antwoorden op databasevragen in het werkgeheugen. Vraagt WordPress voor de duizendste keer dezelfde instellingen of productgegevens op, dan komt het antwoord bliksemsnel uit het geheugen in plaats van uit de database. Redis (en het vergelijkbare Memcached) is het programma dat dat geheugen beheert.
Wanneer heeft dat zin?
- WooCommerce-shops: winkelwagen, afrekenen en ingelogde klanten leunen zwaar op de database.
- Ledensites en cursusplatforms: vrijwel iedereen is ingelogd, dus pagina-cache vangt er weinig.
- Een traag wp-admin: het beheerscherm wordt nooit door pagina-cache geholpen, wel door object cache.
Voor een brochuresite van tien pagina’s zonder inloggers voegt Redis weinig toe — pagina-cache vangt daar al bijna alles af. Wil je het gebruiken, dan moet je hoster Redis aanbieden op je pakket; aanzetten kan daarna gewoon vanuit de LiteSpeed Cache-plugin (onder Cache → Object).
Wat je vooral níet moet doen: stapelen
De klassieker: er draaien twee cache-plugins tegelijk. Twee pagina-caches over elkaar leveren geen dubbele snelheid op, maar dubbele ellende: verouderde pagina’s die maar niet verdwijnen (welke van de twee moet je legen?), opmaak die stukloopt doordat beide plugins CSS zitten te optimaliseren, en in het ergste geval witte pagina’s.
De regel is simpel: één pagina-cache-oplossing. Draai je op LiteSpeed, kies dan de LiteSpeed Cache-plugin en verwijder (niet alleen deactiveren) de rest. Object cache is een andere laag en mag er prima naast bestaan — LiteSpeed Cache plus Redis is juist een prima duo.
En temper de verwachtingen: caching lost niet álles op. Botverkeer dat je cache omzeilt bijvoorbeeld — daarover schreven we in webshop traag of 503-fout? Grote kans dat het een bot is.
Samengevat
- Pagina-cache bewaart hele pagina’s; servercache (zoals LiteSpeed) is daarvan de snelste vorm.
- De LiteSpeed Cache-plugin is de afstandsbediening van de server-cache — en werkt alleen op LiteSpeed-hosting.
- Aanzetten met standaardinstellingen = de grootste winst; geavanceerde opties pas later, één tegelijk.
- Redis/object cache versnelt databasewerk: zinvol voor WooCommerce, ledensites en een traag wp-admin.
- Nooit twee pagina-cache-plugins tegelijk; pagina-cache + object cache mag wél.
Wanneer schakel je hulp in?
Weet je niet op welke webserver je draait, of Redis voor jouw pakket beschikbaar is, of welke instellingen veilig zijn voor jouw shop? Eén vraag aan je hoster scheelt uren puzzelen — een hoster die op LiteSpeed draait (zoals KeurigOnline) kan de cache-setup meestal direct voor je beoordelen en goed zetten. Ga je zelf experimenteren met de geavanceerde opties: maak eerst een back-up en test daarna je winkelwagen en afrekenpagina.