Redis Cache voor WordPress snelheid

Ik installeerde Redis Cache op mijn WordPress-site in de hoop op een snelheidsboost, maar het resultaat was een teleurstelling: geen meetbare snelheidswinst. In dit artikel deel ik mijn ervaring: een stap-voor-stapinstallatie, gevolgd door de harde analyse waarom Redis vaak geen verschil maakt voor standaard WordPress-sites – en wat wél werkt voor echte rankingwinst.

Wat is Redis Cache en waarom ik het installeerde?

Laat me eerlijk zijn. Ranken is tegenwoordig een gevecht. Een bijna onmogelijk gevecht voor kleine websites als decomputer.be.

Je doet alles “goed”: goede teksten schrijven, de snelheid optimaliseren, alle checklistjes afvinken. Maar het voelt als rennen op een lopende band die steeds sneller gaat. In de ogen van zoekmachines is het nooit goed genoeg. Het algoritme hunkert naar autoriteit met een hoofdletter A, en die krijg je niet zomaar.

Mijn site is niet traag. Integendeel. Volgens Pingdom Speedtest heeft hij een performance grade van A. Een page size van ~600 KB. Slechts 16 requests. Een laadtijd van 1,14 seconde.

Technisch gezien is dat uitstekend. Maar in mijn hoofd klopte een onrustige stem: “Dit kan nóg sneller. Dit MOET nóg sneller. Elke milliseconde telt in die ranking oorlog.”

En toen, midden in die zoektocht naar de heilige graal van snelheid, zag ik het in mijn hostingpaneel staan: “Redis Cache”.

Cache.
Het woord alleen al straalt snelheid uit. Het is de technische toverformule die je overal hoort. Mijn gedachtegang was even simpel als onweerstaanbaar: “Cache = Snelheid. Deze knop aanzetten = Snelheidswinst. Meer snelheid = Betere ranking.”

De installatie was eenvoudiger dan ik dacht

Gevoed door de belofte van snelheid, dook ik de installatie in. En eerlijk? Het technische gedeelte was eenvoudiger dan ik dacht. Te eenvoudig bijna. Dat had me moeten waarschuwen.

Het ging zo, in mijn geval via DirectAdmin:

1. In het hostingpaneel klikte ik op “Redis® Cache Manager” en maakte een nieuwe database aan. Eén klik.
2. Na het aanmaken klikte ik op de database, en dan op “Get Redis Cache Database”. Prompt verschenen de connectiegegevens: host, poort, wachtwoord.
3. Het spannende (en gevaarlijke) deel: deze gegevens moesten in de wp-config.php van mijn WordPress site. Dit is het kloppende hart van je website. Eén fout en alles ligt plat.

Ik opende het bestand met knikkende knieën en plakte de volgende regels, uiteraard met mijn waarden:

define('WP_REDIS_HOST', '10.0.24.1');
define('WP_REDIS_PASSWORD', 'mijn_wachtwoord');
define('WP_REDIS_PORT', 22400);
define('WP_REDIS_MAXTTL', 60 * 60 * 24 * 5); // Cache bewaart 5 dagen

De Gouden regel: Deze code moest ik boven de volgende, cruciale regel plakken:

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Mijn belangrijkste tip, gebaseerd op pure angst: Zorg dat je het originele wp-config.php bestand onmiddellijk kunt herstellen. Open het in een tweede tabblad, of heb een back-up klaar staan. Bij het minste syntaxfoutje (een vergeten komma, een verkeerd haakje) krijg je een “White Screen of Death” en laadt je hele site niet meer. Dit was mijn angstzweet moment.

4. De laatste stap: Redis aan WordPress koppelen. Hier zijn twee veelgebruikte paden:
   • Optie A (Specifiek): Installeer de officiële “Redis Object Cache” plugin. Deze zoekt automatisch naar de ingestelde constanten en toont een knop “Enable Object Cache”.
   • Optie B (Geïntegreerd): Als je, zoals ik, al een geavanceerde caching plugin gebruikt (bijv. LiteSpeed Cache), kun je de Redis-gegevens rechtstreeks invullen in de instellingen, onder een sectie zoals “Object Cache”.

Ik koos voor optie B, vulde de gegevens in, en… klikte op activeren.

Het groene vinkje verscheen. “Object Cache Enabled”. Geen foutmeldingen. De site bleef gewoon werken.

Het gevoel was euforisch. “Het werkt! Nu komt de snelheid.” Ik opende mijn Pingdom-tool en GTmetrix, klaar om de spectaculaire daling in laadtijd te aanschouwen.

Die daling kwam niet.

De installatie was geslaagd. De belofte was ingelost. Maar het resultaat… het resultaat was een maat voor niets.

Hoe Redis cache precies werkte – en waarom dat géén effect had op mijn site

Redis Cache slaat database queries op in het RAM-geheugen van de server. Queries die al zijn uitgevoerd, hoeven daardoor niet opnieuw te lopen, maar worden direct uitgelezen. Dat is veel sneller.

Maar op een niet-query-intensieve site zoals decomputer.be is de potentiële winst minimaal. Een artikelpagina doet hier slechts twee hoofdbewerkingen: de artikeltekst ophalen en de eventuele reacties. Dat zijn maar twee simpele queries.

Laten we rekenen. Een simpele WordPress query op goede hosting duurt 1-5 milliseconden. Zelfs als Redis die perfect zou elimineren, praat je over een theoretische maximale winst van ~10ms.

Die winst wordt bovendien volledig tenietgedaan door de overhead van Redis zelf: het opzetten van de verbinding, het serialiseren van data en het netwerkverkeer (zelfs op localhost) kost ook 2-5 ms. Netto winst: nul.

Hier komt de cruciale nuance:
“Als ik LiteSpeed Cache met page caching gebruik, waarom heeft het dan überhaupt een ‘Object Cache’ optie voor Redis?”

Die optie is er voor specifieke, tussentijdse scenario’s waar page caching even niet actief is:

1. Bij het eerste bezoek ooit, voordat de page cache is aangemaakt.
2. Direct na het leegmaken van de cache (bij een update).
3. Voor dynamische, niet-cachebare onderdelen van een verder gecachte pagina (bijv. een live winkelwagen-teller).

De harde realiteit voor mijn site:
Mijn bezoekersaantallen zijn laag. Het scenario waarbij de page cache leeg is én er tegelijk een nieuwe bezoeker arriveert, is zeldzaam. De kans dat Redis in die micro-momenten een verschil maakte, is statistisch verwaarloosbaar.

De genadeslag was dit: Redis optimaliseert een laag (database queries) die op mijn site, dankzij de page cache, vrijwel nooit meer wordt aangesproken door gewone bezoekers. Het was als een reservewiel monteren op een auto die alleen op perfecte snelwegen rijdt – technisch correct, maar in de praktijk een dode investering.

Is Redis Cache dan zinloos? Een scam? Nee!

Laat ik dit heel duidelijk maken: mijn ervaring betekent niet dat Redis slecht is. Integendeel. Het betekent dat ik het voor het verkeerde probleem probeerde in te zetten.

Op mijn relatief statische site was het een maat voor niets. Maar verander het scenario, en het hele verhaal kantelt.

Stel je voor: een druk bezochte WooCommerce-winkelpagina.
De pagina laadt niet alleen het product. Hij moet ook: gerelateerde producten, klantreviews, voorraadstatus, persoonlijke aanbevelingen en een dynamische winkelwagen tonen. Plots heb je niet 2, maar 20, 30, of zelfs 50+ database queries per paginaweergave.

Op goedkope, trage shared hosting waar elke query 20-50ms kost, loopt de totale database-tijd op tot een seconde of meer. Dán wordt Redis niet langer een optie, maar een noodzaak.

Dus: Wanneer is Redis wél een succes?
Het wordt een krachtig wapen als je aan minstens twee van deze drie voorwaarden voldoet:

1. Je site is écht query-intensief (forums, sociale netwerken, grote webshops).
2. Je hosting is de bottleneck (trage database).
3. Je hebt géén sterke page cache (heel dynamische, gepersonaliseerde pagina’s).

In die gevallen is Redis geen “magische snelheidsknop”, maar een kritisch onderdeel van je performance-stack.

Conclusie en mijn echte snelheidsplan

De moraal is niet “gebruik Redis nooit”. De moraal is: ken je vijand. Meet eerst.

Installeer de plugin Query Monitor. Als die je een muur aan trage queries toont, dan is Redis je nieuwe beste vriend. Toont het, zoals bij mij, een handvol snelle queries? Sla Redis dan over en focus op wat wél werkt:

1. Schakel een CDN in (Cloudflare, gratis) – grootste winst voor internationale snelheid
2. Optimaliseer élke afbeelding naar WebP (ShortPixel of Imagify)
3. Zet een sterke Page Cache aan (via WP Rocket of je hosting-plugin)
4. Clean je database en reduceer het aantal plugins
5. Kies een licht, snel thema (GeneratePress, Kadence)

Voor mijn site decomputer.be betekende dit: Redis uitschakelen, de CDN optimaliseren en afbeeldingen verder comprimeren. Mijn laadtijd bleef een snelle 1,15 seconde, maar de perceived performance (hoe snel het voor de bezoeker voelt) werd veel beter.

Snelheid is geen toverwoord. Het is een diagnose. Stel die eerst, en kies dan je gereedschap. En vergeet niet: soms is de beste optimalisatie om te accepteren dat je site al snel genoeg is – en je tijd te besteden aan wat écht telt: goede content.