Redis WordPress wordt vaak genoemd als oplossing wanneer een website langzaam is, maar Redis is geen algemene snelheidsknop. De techniek kan WordPress aanzienlijk efficiënter maken wanneer een website vaak dezelfde gegevens uit de database moet ophalen. Bij een eenvoudige bedrijfswebsite met enkele pagina’s kan het verschil juist beperkt zijn.
Om te begrijpen wanneer Redis zin heeft, moet je daarom eerst weten waar WordPress tijd aan besteedt.
Een WordPress-pagina bestaat niet simpelweg als één kant-en-klaar HTML-bestand op de server. Bij veel pagina’s moet WordPress eerst PHP uitvoeren, instellingen ophalen, plugins laden en informatie uit de database verzamelen. Pas daarna kan de uiteindelijke pagina worden opgebouwd.
Redis kan een deel van dat terugkerende databasewerk tijdelijk in het geheugen bewaren. Daardoor hoeft WordPress niet voor ieder verzoek opnieuw dezelfde informatie op te vragen.
Daar zit de belangrijkste winst van een Redis object cache.
Wat is Redis en wat doet het binnen WordPress?
Redis is een snelle gegevensopslag die voornamelijk in het werkgeheugen van een server werkt. De naam staat voor Remote Dictionary Server.
In plaats van bepaalde gegevens telkens opnieuw vanaf een database of andere opslag te lezen, kunnen veelgebruikte gegevens tijdelijk in Redis worden bewaard.
Dat is belangrijk omdat RAM veel sneller toegankelijk is dan traditionele opslag.
Binnen WordPress wordt Redis meestal gebruikt als persistent object cache. Het vervangt MySQL of MariaDB dus niet. Je normale WordPress-database blijft bestaan en blijft de uiteindelijke bron van de gegevens.
Redis komt als extra laag tussen WordPress en een deel van die databaseverzoeken te staan.
Wanneer WordPress bepaalde informatie eerder heeft opgehaald en deze nog in Redis beschikbaar is, kan het systeem die waarde direct uit het geheugen lezen.
Daarom kun je Redis het beste zien als een tijdelijke snelle opslagruimte voor informatie die WordPress regelmatig opnieuw nodig heeft.
Waarom gebruikt WordPress zoveel databasegegevens?
WordPress is sterk databasegestuurd.
Vrijwel iedere moderne WordPress-site haalt voortdurend gegevens op. Een pagina bevat bijvoorbeeld niet alleen de zichtbare tekst. WordPress kan tijdens dezelfde aanvraag ook instellingen, menu’s, widgets, gebruikersrechten, pluginconfiguraties en metadata nodig hebben.
Een eenvoudige blogpagina kan tientallen databasequeries uitvoeren.
Bij complexere websites kan dat aantal veel hoger liggen.
WooCommerce voegt daar bijvoorbeeld producten, prijzen, voorraad, klantgegevens en winkelwageninformatie aan toe. Een membershipwebsite moet mogelijk rechten en gebruikersinformatie controleren. Een website met uitgebreide filters kan bij iedere zoekactie opnieuw grote hoeveelheden data verwerken.
Daarom kan database caching in WordPress vooral interessant worden wanneer dezelfde informatie steeds opnieuw wordt opgevraagd.
Wat is WordPress object caching?
WordPress heeft zelf al een mechanisme voor object caching.
Tijdens één pagina-aanvraag kan informatie tijdelijk worden opgeslagen zodat WordPress dezelfde databasequery binnen die aanvraag niet opnieuw hoeft uit te voeren.
Het probleem is dat deze standaardcache meestal niet persistent is.
Zodra de aanvraag is afgelopen, verdwijnt de informatie weer.
Komt een volgende bezoeker naar dezelfde website, dan begint het proces grotendeels opnieuw.
Met een persistent object cache blijft een deel van deze informatie beschikbaar tussen verschillende aanvragen.
Redis is een veelgebruikte techniek om dat mogelijk te maken.
Daarom is het verschil tussen standaard object caching en Redis vooral de levensduur van de cache.
De standaard WordPress-cache helpt binnen één aanvraag. Redis kan relevante cachegegevens langer beschikbaar houden.
Redis object cache is niet hetzelfde als page caching
Dit verschil zorgt vaak voor verwarring.
Een Redis object cache en een normale page cache proberen allebei de website sneller te maken, maar ze doen iets anders.
Een page cache bewaart in veel gevallen een complete versie van een reeds opgebouwde webpagina. Wanneer de volgende bezoeker dezelfde pagina opent, hoeft WordPress de pagina niet opnieuw volledig op te bouwen.
De server kan de opgeslagen HTML direct teruggeven.
Dat is extreem effectief voor pagina’s die voor vrijwel iedere bezoeker hetzelfde zijn.
Een object cache werkt dieper in WordPress. Redis bewaart geen complete pagina, maar bepaalde gegevens die WordPress tijdens het opbouwen ervan gebruikt.
Hierdoor blijft WordPress de pagina verwerken, maar een deel van de databasevragen kan sneller worden beantwoord.
Dat verschil verklaart waarom beide technieken naast elkaar gebruikt kunnen worden.
Wanneer is page caching beter dan Redis?
Stel dat je een bedrijfswebsite hebt met tien informatieve pagina’s.
De homepage is voor iedere bezoeker hetzelfde. De dienstenpagina verandert nauwelijks en bezoekers hoeven niet in te loggen.
Een goede full-page cache kan hier enorm veel werk wegnemen.
Wanneer de HTML van de pagina al gecachet is, hoeft WordPress voor veel bezoekers nauwelijks iets te berekenen. Daardoor krijgt Redis veel minder werk om te versnellen.
In zo’n situatie levert het toevoegen van Redis mogelijk maar een klein zichtbaar verschil op.
Daarom is het niet verstandig om bij iedere trage WordPress-site als eerste Redis te installeren.
Soms is een goede page cache, betere hosting of het optimaliseren van afbeeldingen veel effectiever.
Wanneer wordt Redis voor WordPress wél interessant?
Redis wordt interessanter zodra een website dynamischer wordt.
Dat betekent dat pagina’s niet voor iedere bezoeker volledig hetzelfde zijn of dat WordPress voortdurend databasegegevens moet verwerken.
Een goed voorbeeld is een webshop.
Een bezoeker kan producten in zijn winkelwagen hebben terwijl een andere bezoeker een lege winkelwagen ziet. Een ingelogde klant ziet zijn eigen accountinformatie. Productvoorraad kan veranderen en prijzen kunnen afhankelijk zijn van andere instellingen.
Je kunt zulke pagina’s niet altijd volledig als één statisch HTML-bestand aan iedere bezoeker serveren.
WordPress en WooCommerce moeten dus vaker echt aan het werk.
Juist dan kan WordPress object caching meer voordeel opleveren.
WooCommerce en Redis vormen daarom een interessante combinatie
WooCommerce Redis wordt vaak gebruikt omdat een webshop veel dynamische databaseprocessen heeft.
Iedere productpagina bevat bijvoorbeeld meer dan alleen een titel en afbeelding. WooCommerce kan informatie ophalen over prijzen, voorraad, attributen, categorieën, belastinginstellingen en andere productgegevens.
Daar komen plugins vaak nog bovenop.
Een meertalige webshop kan extra tabellen raadplegen. Een B2B-plugin kan prijzen per klant controleren. Een voorraadkoppeling kan continu gegevens verwerken.
Wanneer veel van deze gegevens regelmatig opnieuw nodig zijn, kan Redis voorkomen dat iedere aanvraag opnieuw dezelfde databasequeries uitvoert.
Dat betekent niet dat iedere WooCommerce-shop automatisch Redis nodig heeft.
Een webshop met twintig producten en weinig bezoekers kan op gewone goede hosting uitstekend werken.
Een webshop met tienduizenden producten en veel gelijktijdige bezoekers is een heel andere situatie.
Redis kan ook het WordPress-dashboard versnellen
Een interessant voordeel van object caching is dat het niet alleen de zichtbare website kan beïnvloeden.
Page caching helpt vooral bezoekers aan de voorkant van de website. Het WordPress-dashboard wordt meestal niet als gewone statische pagina gecachet.
Daarom kan een trage /wp-admin/ soms nauwelijks profiteren van een traditionele cacheplugin.
Redis kan daar anders werken.
Wanneer het dashboard veel dezelfde databasegegevens nodig heeft, kan een object cache bepaalde verzoeken versnellen.
Dit is vooral relevant bij grotere WooCommerce-sites. Het bestellingenoverzicht, productschermen en verschillende plugins kunnen veel databasewerk veroorzaken.
Toch moet je ook hier eerst meten.
Een trage admin kan bijvoorbeeld worden veroorzaakt door een externe API die tien seconden niet reageert. Redis maakt die externe server niet sneller.
Redis lost een slechte plugin niet op
Dit is misschien het belangrijkste punt bij Redis WordPress.
Caching kan inefficiënt databasewerk verminderen, maar het repareert geen slecht ontwikkelde software.
Stel dat een plugin bij iedere pagina-aanvraag een extreem zware query uitvoert. Redis kan die query soms cachen, waardoor het probleem minder zichtbaar wordt.
Toch blijft de plugin technisch inefficiënt.
Hetzelfde geldt voor een plugin die bij iedere aanvraag verbinding maakt met een externe server. Redis kan die netwerkverbinding niet zomaar versnellen.
Daarom moet performance-optimalisatie altijd beginnen met meten.
Je wilt weten waar WordPress tijd verliest voordat je een oplossing kiest.
Redis lost te weinig CPU of RAM ook niet op
Serverresources blijven eveneens belangrijk.
Redis gebruikt zelf werkgeheugen.
Op een VPS met zeer weinig RAM kan het toevoegen van een grote object cache daardoor juist extra druk veroorzaken.
Stel dat WordPress, PHP, MariaDB en het controlepaneel samen vrijwel al het beschikbare geheugen gebruiken.
Als je daar vervolgens Redis naast zet en honderden megabytes cache laat opbouwen, kan de server beginnen te swappen of processen beëindigen.
In zo’n situatie is het echte probleem niet het ontbreken van Redis.
De server heeft simpelweg onvoldoende capaciteit.
Daarom moet je vóór de configuratie bekijken hoeveel RAM beschikbaar is en hoeveel Redis maximaal mag gebruiken.
Hoe werkt een Redis cache hit?
Wanneer WordPress informatie nodig heeft, kan het eerst controleren of die informatie al in Redis staat.
Staat de waarde in de cache, dan spreken we van een cache hit.
Redis kan de informatie direct teruggeven.
Staat de informatie nog niet in Redis, dan ontstaat een cache miss.
WordPress moet de gegevens vervolgens alsnog uit de database halen. Daarna kan de waarde worden gecachet zodat een volgende aanvraag deze sneller kan gebruiken.
Dit principe maakt ook duidelijk waarom Redis niet iedere website automatisch sneller maakt.
Wanneer vrijwel iedere aanvraag unieke gegevens nodig heeft en de cache zelden wordt hergebruikt, heb je weinig cache hits.
Het echte voordeel ontstaat wanneer veel dezelfde gegevens opnieuw worden gebruikt.
Wat is een goede Redis hit rate?
Er bestaat geen universeel percentage waarbij je kunt zeggen dat Redis goed of slecht werkt.
Een hoge hit rate betekent in algemene zin dat veel gevraagde gegevens direct vanuit de cache worden geleverd.
Maar het type website blijft belangrijk.
Een dashboard met unieke gebruikersgegevens kan bijvoorbeeld een ander patroon hebben dan een productcatalogus waarin dezelfde productinformatie duizenden keren wordt bekeken.
Daarom moet je een hit rate altijd combineren met andere metingen.
Kijk bijvoorbeeld naar databasebelasting, responstijd en geheugengebruik.
Het uiteindelijke doel is niet om de hoogst mogelijke Redis-statistiek te krijgen.
Het doel is dat de website sneller en stabieler functioneert.
Redis en WordPress installeren: wat is ervoor nodig?
Voor een werkende Redis cache in WordPress zijn twee afzonderlijke onderdelen nodig.
Eerst moet Redis daadwerkelijk op serverniveau beschikbaar zijn.
Daarna moet WordPress weten hoe het ermee moet communiceren.
Dat tweede onderdeel wordt vaak via een WordPress-plugin geregeld.
De plugin installeert Redis zelf meestal niet. Hij maakt alleen de koppeling tussen WordPress en de reeds aanwezige Redis-service.
Dit onderscheid is belangrijk.
Wanneer een plugin meldt dat Redis niet bereikbaar is, betekent dat bijvoorbeeld dat de service niet draait, niet op het verwachte adres luistert of dat de verbinding verkeerd is geconfigureerd.
Op managed WordPress-hosting kan de provider Redis al voor je beschikbaar maken.
Op een eigen VPS moet je dit meestal zelf of via de serverbeheerder regelen.
Redis verbinden via TCP of een Unix socket
Wanneer WordPress en Redis op dezelfde server staan, kunnen ze op verschillende manieren communiceren.
De bekendste methode is een netwerkverbinding via TCP.
Redis luistert dan bijvoorbeeld op een lokaal IP-adres en een specifieke poort.
Een andere mogelijkheid is een Unix socket.
Daarbij communiceert WordPress via een lokaal socketbestand met Redis.
Een socket kan interessant zijn wanneer beide processen op dezelfde server draaien, omdat er geen gewone netwerkverbinding nodig is.
Voor de gebruiker van de website verandert er niets.
Dit is puur een technische keuze binnen de serverconfiguratie.
Welke methode het beste is, hangt af van de gebruikte hostingomgeving en beveiligingsconfiguratie.
Waarom Redis niet publiek bereikbaar moet zijn
Een Redis-server bevat tijdelijke informatie van applicaties en hoort daarom niet zonder noodzaak toegankelijk te zijn vanaf het openbare internet.
Wanneer WordPress en Redis op dezelfde server draaien, is er meestal geen reden om iedereen wereldwijd verbinding met de Redis-poort te laten maken.
De dienst kan lokaal worden gebonden of via een Unix socket werken.
Wanneer Redis over een netwerk tussen verschillende servers wordt gebruikt, is extra beveiliging noodzakelijk.
Denk daarbij aan firewallregels en andere toegangsbeperkingen.
Caching wordt soms puur als performanceonderwerp gezien, maar serverbeveiliging hoort altijd mee te wegen.
Een website die enkele milliseconden sneller is maar daardoor een extra publiek aanvalspunt krijgt, is geen goede optimalisatie.
Wat gebeurt er wanneer Redis uitvalt?
Een correcte WordPress-configuratie hoort niet te betekenen dat de volledige website permanent onbruikbaar wordt zodra de cache leeg is.
Redis bevat immers gecachte gegevens.
De oorspronkelijke informatie staat nog in WordPress en de database.
Toch kunnen foutieve configuraties problemen veroorzaken wanneer de Redis-service niet bereikbaar is.
Daarom is monitoring belangrijk.
Op een professionele server wil je weten of Redis draait, hoeveel geheugen de service gebruikt en of er verbindingsproblemen zijn.
Het is eveneens verstandig om na serverupdates te controleren of Redis automatisch opnieuw is gestart.
Een cachelaag moet de beschikbaarheid verbeteren, niet een nieuw onzichtbaar probleem creëren.
Wat gebeurt er wanneer de Redis-cache vol raakt?
Redis bewaart gegevens in RAM. Dat geheugen is eindig.
Daarom kan er een maximale hoeveelheid geheugen worden ingesteld.
Wanneer die grens bereikt wordt, bepaalt het zogenaamde eviction policy wat er met bestaande cachedata gebeurt.
Bepaalde oudere of minder relevante gegevens kunnen bijvoorbeeld uit de cache verdwijnen om ruimte te maken.
Dat is bij caching normaal.
De gegevens zijn niet definitief verloren, omdat de oorspronkelijke informatie nog in de database staat.
WordPress moet die informatie bij een volgende aanvraag alleen opnieuw ophalen en eventueel opnieuw cachen.
Daarom moet je Redis voldoende geheugen geven, maar niet onbeperkt al het RAM van de server laten gebruiken.
Redis en meerdere WordPress-websites op één server
Op een VPS kunnen meerdere WordPress-sites dezelfde Redis-installatie gebruiken.
Daarbij moet je wel voorkomen dat cachegegevens van verschillende websites op een verkeerde manier door elkaar lopen.
WordPress-integraties kunnen hiervoor bijvoorbeeld een uniek cacheprefix gebruiken.
Daardoor kan site A zijn eigen cache-objecten onderscheiden van site B.
Dit is vooral belangrijk bij hostingservers waarop veel klantwebsites draaien.
Een kleine configuratiefout kan anders vreemde problemen opleveren waarbij informatie uit verschillende omgevingen elkaar beïnvloedt.
Bij multisite- of multi-tenant hosting moet Redis daarom bewust worden ingericht.
Wat gebeurt er met Redis na een websiteverhuizing?
Een website migreren naar een andere server vraagt extra aandacht voor caching.
De Redis-cache zelf hoef je normaal gesproken niet als belangrijke permanente websitegegevens mee te verhuizen.
De cache kan opnieuw worden opgebouwd.
Wel moet op de nieuwe server de Redis-configuratie correct zijn.
Denk aan de host, poort, socket, prefix en eventuele authenticatie.
Na een migratie kan het verstandig zijn de object cache bewust opnieuw te laten opbouwen.
Zo voorkom je dat oude serverinstellingen of tijdelijke waarden voor problemen zorgen.
Ook moet je controleren of WordPress daadwerkelijk met de Redis-service op de nieuwe server verbonden is.
Redis en database-optimalisatie zijn niet hetzelfde
Een WordPress database optimaliseren blijft ook met Redis relevant.
Stel dat een database miljoenen onnodige rijen bevat of dat bepaalde tabellen slecht presteren.
Redis kan een deel van terugkerende queries cachen, maar de onderliggende database blijft bestaan.
Zodra een cache miss optreedt, moet WordPress alsnog naar die database.
Daarnaast zijn niet alle gegevens geschikt om langdurig te cachen.
Een gezonde WordPress-installatie heeft daarom zowel een goed ingerichte database als een verstandige cachingstrategie nodig.
Redis mag niet worden gebruikt om structurele databaseproblemen te verbergen.
Redis versus Memcached
Naast Redis wordt ook Memcached gebruikt voor object caching.
Beide technieken kunnen gegevens in het geheugen bewaren en daarmee databasewerk verminderen.
Redis biedt echter meer mogelijkheden als datastructuurserver en wordt tegenwoordig veel gebruikt in WordPress-omgevingen.
Voor een normale website-eigenaar is de exacte technische vergelijking meestal minder belangrijk dan de vraag welke oplossing de hostingprovider goed ondersteunt.
Een uitstekend onderhouden Memcached-configuratie kan nuttiger zijn dan een slecht ingestelde Redis-service.
Kies daarom niet uitsluitend op basis van welke naam vaker in blogs voorkomt.
Kijk naar de volledige hostingomgeving.
Heeft Redis invloed op Core Web Vitals?
Indirect kan dat.
Redis verandert bijvoorbeeld niet rechtstreeks de afmetingen van een afbeelding en voorkomt ook geen layout shift in de browser.
Wel kan een snellere backend ervoor zorgen dat de server sneller begint met het terugsturen van de pagina.
Daardoor kan de totale gebruikerservaring verbeteren.
Voor Core Web Vitals blijven echter ook frontendfactoren belangrijk.
Denk aan afbeeldingen, CSS, JavaScript, lettertypen en de opbouw van pagina’s.
Wie alleen Redis installeert maar ondertussen een hero-afbeelding van acht megabyte laadt, pakt slechts één deel van de performance aan.
WordPress sneller maken vraagt dus meer dan Redis
Wil je WordPress sneller maken, dan is het verstandig de website als geheel te bekijken.
Begin bij de serverreactietijd.
Controleer daarna welke processen veel tijd kosten.
Kijk vervolgens naar databasequeries, plugins en externe verzoeken.
Pas daarna bepaal je welke cachinglaag nodig is.
Bij de ene website is dat vooral full-page caching. Bij de andere website levert Redis meer op.
Een derde website heeft eigenlijk gewoon een grotere VPS nodig.
Daarom is performance-optimalisatie geen lijstje met plugins dat voor iedere website hetzelfde is.
De oorzaak bepaalt de oplossing.
Redis WordPress bij Elementor-websites
Elementor-sites kunnen Redis gebruiken, maar ook hier moet je realistische verwachtingen hebben.
Een zware Elementor-pagina kan veel HTML, CSS en JavaScript bevatten.
Redis vermindert dat frontendgewicht niet.
Wel kan WordPress tijdens het genereren van de pagina bepaalde databasegegevens sneller verkrijgen.
Wanneer de grootste vertraging echter ontstaat doordat de browser enorme afbeeldingen en scripts moet downloaden, zal Redis maar weinig verschil maken.
Daarom moet bij een trage Elementor-site zowel frontend als backend worden onderzocht.
Caching op één niveau is zelden het volledige antwoord.
Redis WordPress bij websites met veel ingelogde gebruikers
Hier wordt object caching vaak interessanter.
Bij een normale openbare pagina kan full-page caching veel werk overnemen.
Bij ingelogde gebruikers is dat lastiger. Iedere gebruiker kan namelijk andere informatie zien.
Denk aan een ledensite, leeromgeving, klantportaal of webshopaccount.
WordPress moet daar vaker dynamisch informatie opbouwen.
Een persistent object cache kan vervolgens herhaalde databasegegevens versnellen zonder dat je de volledige persoonlijke pagina voor iedereen hetzelfde maakt.
Daarom wordt Redis relatief interessanter naarmate een website meer dynamische en gepersonaliseerde functies krijgt.
Wanneer heeft Redis weinig nut?
Een kleine WordPress-site die al snel laadt en vrijwel volledig vanuit page cache wordt geleverd, hoeft Redis niet per se te gebruiken.
Ook wanneer de grootste vertraging buiten WordPress ligt, is het effect klein.
Een externe API die vijf seconden nodig heeft om te antwoorden wordt bijvoorbeeld niet sneller doordat je Redis installeert.
Hetzelfde geldt voor slecht geoptimaliseerde afbeeldingen of een server die voortdurend tegen zijn CPU-limiet loopt.
Daarnaast moet je rekening houden met extra beheer.
Iedere extra serverdienst moet worden geconfigureerd, beveiligd, gemonitord en bijgewerkt.
Techniek toevoegen zonder aantoonbaar voordeel maakt een hostingomgeving alleen maar complexer.
Hoe bepaal je of Redis echt voordeel oplevert?
De beste methode is meten vóór en na de wijziging.
Controleer eerst de huidige situatie.
Kijk bijvoorbeeld naar de serverrespons, databasebelasting en snelheid van dynamische pagina’s.
Activeer daarna Redis op een correct ingerichte manier.
Meet vervolgens opnieuw onder vergelijkbare omstandigheden.
Let daarbij niet alleen op één PageSpeed-score.
Interessanter zijn bijvoorbeeld responstijden van dynamische WordPress-pagina’s en belasting van de database tijdens meerdere gelijktijdige verzoeken.
Ook de WordPress-admin kan een goede vergelijking geven wanneer die voorheen traag was.
Als er nauwelijks verschil zichtbaar is, moet je jezelf afvragen of Redis in die omgeving überhaupt nodig is.
Redis kan vooral belangrijk worden bij schaal
Een verschil van enkele milliseconden lijkt voor één bezoeker misschien nauwelijks relevant.
Bij duizenden gelijktijdige aanvragen verandert het verhaal.
Wanneer Redis ervoor zorgt dat een groot deel van herhaalde databasequeries niet meer rechtstreeks naar MariaDB hoeft, wordt niet alleen de individuele aanvraag sneller.
De database krijgt ook minder belasting.
Daardoor kan de server meer gelijktijdige verzoeken verwerken voordat dezelfde hardware tegen zijn limiet aanloopt.
Dat maakt object caching vooral interessant bij schaal.
Redis draait dus niet alleen om “mijn pagina opent iets sneller”. Het kan ook helpen om de infrastructuur efficiënter met beschikbare resources te laten omgaan.
Redis voor WordPress of betere hosting?
Soms is de beste optimalisatie geen cachelaag, maar betere hosting.
Stel dat een VPS voortdurend op 100% CPU draait en nauwelijks vrij geheugen heeft.
Dan kan een upgrade noodzakelijk zijn.
Andersom is alleen een grotere VPS aanschaffen ook niet altijd slim.
Wanneer de website duizenden identieke databasequeries uitvoert die eenvoudig gecachet kunnen worden, betaal je misschien voor extra servercapaciteit terwijl optimalisatie efficiënter zou zijn.
Daarom moet je beide kanten bekijken.
Goede hosting en goede softwareconfiguratie vullen elkaar aan.
Redis kan een efficiënte server nog beter laten presteren, maar het verandert een slecht ontworpen omgeving niet automatisch in een goede.
Redis WordPress laten instellen door Sanum
Sanum kan bij WordPress- en WooCommerce-websites onderzoeken of een Redis object cache daadwerkelijk voordeel oplevert.
Daarbij kijken we niet alleen naar de vraag of Redis technisch geïnstalleerd kan worden.
Belangrijker is waarom de website langzaam is en welke onderdelen de meeste belasting veroorzaken.
Dat kan bijvoorbeeld de database zijn, maar ook PHP, plugins, cronjobs, externe API’s, WooCommerce of onvoldoende serverresources.
Wanneer Redis passend is, kan de object cache onderdeel worden van een bredere hosting- en performanceconfiguratie.
Daarbij moet ook worden gekeken naar beveiliging, geheugenlimieten, monitoring en samenwerking met andere cachinglagen.
Wil je weten of Redis jouw WordPress- of WooCommerce-website echt sneller kan maken? Sanum kan de hostingomgeving en databasebelasting analyseren en op basis daarvan bepalen welke optimalisatie het meeste resultaat oplevert.
Veelgestelde vragen over Redis WordPress
Maakt Redis WordPress altijd sneller?
Nee. Redis levert vooral voordeel op wanneer WordPress veel herhaalde databasegegevens gebruikt. Bij een kleine statische website die vrijwel volledig uit page cache wordt geleverd, kan het verschil beperkt zijn.
Wat is het verschil tussen Redis en een normale cacheplugin?
Een gewone cacheplugin richt zich vaak op complete pagina’s, CSS, JavaScript of browsercaching. Redis wordt binnen WordPress vooral gebruikt als persistente object cache en versnelt daarmee bepaalde databasegerelateerde processen.
Is Redis interessant voor WooCommerce?
Bij grotere WooCommerce-webshops kan Redis interessant zijn omdat veel pagina’s dynamisch zijn en regelmatig databasegegevens nodig hebben. Het werkelijke voordeel hangt echter af van de webshop en serverconfiguratie.
Kan Redis een trage WordPress-admin sneller maken?
Dat kan. De WordPress-admin profiteert meestal niet van normale full-page caching. Wanneer databasequeries een belangrijke oorzaak van de vertraging zijn, kan een persistent object cache verbetering opleveren.
Heb ik Redis nodig als mijn hosting al caching gebruikt?
Niet noodzakelijk. De hostingprovider kan al page caching of object caching aanbieden. Controleer daarom eerst welke technieken actief zijn voordat je extra cachinglagen toevoegt.
Gebruikt Redis veel RAM?
Redis bewaart gegevens voornamelijk in het geheugen en gebruikt dus RAM. Daarom moet een passende limiet worden ingesteld. Op een VPS met weinig geheugen kan een te grote Redis-cache juist extra druk op de server veroorzaken.
Is Redis een vervanging voor de WordPress-database?
Nee. Redis is in deze toepassing een tijdelijke cachelaag. WordPress blijft zijn permanente gegevens opslaan in MySQL of MariaDB.
Moet ik Redis back-uppen?
Voor normale WordPress object caching hoeft de Redis-cache meestal niet als kritieke websitegegevens te worden geback-upt. De cache kan opnieuw worden opgebouwd vanuit de oorspronkelijke gegevens.
Kan Redis samen met page caching worden gebruikt?
Ja. Dat is juist een veelgebruikte combinatie. Page caching voorkomt dat complete pagina’s steeds opnieuw worden opgebouwd, terwijl Redis bepaalde databasegegevens versnelt wanneer WordPress wel echt moet draaien.
Is Redis geschikt voor meerdere WordPress-sites op één VPS?
Ja, maar de configuratie moet ervoor zorgen dat de cachedata van verschillende websites correct van elkaar wordt gescheiden. Een unieke prefix of andere scheiding is daarbij belangrijk.
Wanneer moet ik Redis cache legen?
Dat kan bijvoorbeeld nodig zijn na bepaalde migraties, databaseherstel of grote configuratiewijzigingen. Als de cache voortdurend handmatig moet worden geleegd om fouten op te lossen, is er waarschijnlijk een ander probleem dat onderzocht moet worden.
Wat is beter: Redis installeren of mijn VPS upgraden?
Dat hangt af van de oorzaak van de traagheid. Bij zware databasequeries kan Redis efficiënter zijn. Bij structureel CPU- of RAM-tekort kan meer servercapaciteit nodig zijn. Meten is daarom de eerste stap.
