Wat is een object cache? Redis en Memcached voor WordPress uitgelegd

Een object cache bewaart de resultaten van databasequery's in het werkgeheugen, zodat WordPress ze de volgende keer niet opnieuw uit de database hoeft te halen. Dat klinkt niet bepaald spectaculair. Bij webshops, ledensites en alles waar veel gebruikers ingelogd zijn, maakt het voor de laadtijd toch vaak het grootste verschil. WordPress heeft wel een eigen object cache aan boord, maar die vergeet na elke paginaweergave alles weer. Pas met Redis of Memcached op de achtergrond wordt het een persistente object cache, die gegevens over veel verzoeken heen vasthoudt. In dit artikel lees je hoe dat precies werkt, waarin Redis en Memcached verschillen, wanneer de moeite loont en welke fouten je bij het instellen beter kunt vermijden.

Wat is een object cache in WordPress?

Elke keer dat iemand een pagina van je website opent, zet WordPress die in elkaar uit een heleboel losse onderdelen. Het laadt de instellingen van de site, de menu's, de widgets, het bericht zelf, de gegevens van de auteur, categorieën, tags en alles wat je plugins daarnaast nog nodig hebben. Vrijwel al die gegevens staan in de database (MySQL of MariaDB). Op een gewone pagina kom je zo al snel op 50 tot 150 databasequery's, met WooCommerce en een paar grotere plugins ook flink meer. Veel daarvan vragen bij elk verzoek precies hetzelfde: hoe heet de website? Welke plugins zijn actief? Hoe ziet het hoofdmenu eruit?

Een object cache onthoudt de antwoorden op zulke vragen. WordPress kijkt eerst in de cache, en alleen als daar niets ligt, gaat de vraag naar de database. Het resultaat komt daarna in de cache terecht en staat de volgende keer meteen klaar. De naam komt doordat WordPress daar geen complete pagina's opslaat, maar losse gegevensobjecten: een bericht, een lijst met opties, de metadata van een gebruiker.

Zie het als een geeltje naast je toetsenbord. In plaats van elke keer in de archiefkast te zoeken, kijk je eerst op het briefje. Bij één enkele vraag scheelt dat nauwelijks tijd. Wordt dezelfde vraag duizend keer per dag gesteld, dan scheelt het enorm.

Hoe werkt de object cache van WordPress?

WordPress heeft al vele jaren een eigen klasse voor de object cache, WP_Object_Cache. De kern van WordPress en veel plugins spreken die aan via functies als wp_cache_get() en wp_cache_set(). Er zit wel een addertje onder het gras: zonder extra software leeft deze cache maar zo lang als één paginaweergave. Zodra de pagina is afgeleverd, is het geheugen weer leeg en begint bij de volgende bezoeker alles opnieuw.

Toch is deze tijdelijke cache niet nutteloos, want hij voorkomt dubbele query's binnen één verzoek. Echt interessant wordt het pas met een persistente object cache. Daarvoor staat er een bestand object-cache.php in de map wp-content. WordPress herkent het bij het opstarten automatisch en gebruikt dan in plaats van zijn eigen tijdelijke opslag een externe dienst zoals Redis of Memcached. De gegevens blijven daar over veel paginaweergaven heen bewaard, tot ze verlopen, veranderen of het geheugen vol is. Dat bestand hoef je niet zelf te schrijven. Plugins als Redis Object Cache brengen het mee en zetten het bij het activeren op de juiste plek.

Een bijeffect waar veel mensen niets van weten, heeft te maken met de zogeheten transients. Dat zijn tijdelijk opgeslagen waarden met een vervaldatum, die plugins graag gebruiken, bijvoorbeeld voor antwoorden van externe API's. Zonder persistente object cache belanden transients in de tabel wp_options, en die dijt daardoor langzaam uit. Met Redis of Memcached verhuizen ze naar het werkgeheugen en blijft de database slanker.

Object cache, paginacache en OPcache: wat is het verschil?

Zodra het over WordPress en caching gaat, vallen al snel drie termen die makkelijk door elkaar lopen. Ze werken op verschillende niveaus en vullen elkaar aan in plaats van elkaar te vervangen.

• Paginacache: slaat de complete, afgewerkte pagina op als HTML en levert die uit zonder WordPress überhaupt te starten. Zo werken bijvoorbeeld WP Rocket, LiteSpeed Cache en WP Super Cache. Sneller kan niet, maar alleen zolang alle bezoekers dezelfde pagina te zien krijgen.
• Object cache: slaat losse resultaten uit de database op. WordPress draait nog steeds bij elk verzoek, maar hoeft de database veel minder vaak te raadplegen.
• OPcache: heeft helemaal niets met je gegevens te maken. Het zorgt ervoor dat PHP de bestanden van WordPress niet bij elk verzoek opnieuw hoeft in te lezen en te compileren. Op bijna elk hostingpakket staat het tegenwoordig al aan.

Het belangrijkste punt: een paginacache helpt alleen bij pagina's die er voor iedereen hetzelfde uitzien. Zodra iemand is ingelogd, iets in de winkelwagen legt of in de backend werkt, wordt hij omzeild. Precies daar springt de object cache bij. Voor een blog met bijna alleen anonieme lezers levert een goede paginacache dus meer op. Bij een webshop, een leerplatform of een forum zit de grootste winst vaak in de object cache.

Redis vs Memcached: welke object cache past bij WordPress?

Beide systemen houden gegevens in het werkgeheugen en slaan ze op als eenvoudige paren van sleutel en waarde. Als object cache zijn ze allebei snel genoeg. De verschillen zitten in de details.

Redis is tegenwoordig de gebruikelijke keuze voor WordPress. Het kan meer opslaan dan alleen sleutels en waarden, bijvoorbeeld lijsten, hashes en sets, en als je wilt schrijft het zijn inhoud naar schijf, zodat de cache een herstart overleeft. Daar komen replicatie, fijnmaziger toegangsbeheer en een groot ecosysteem bij. Voor WordPress is er bovendien Redis Object Cache, een zeer veelgebruikte en goed onderhouden plugin. Na een licentiewijziging bij Redis in 2024 is daarnaast Valkey ontstaan, een vrije fork onder de vleugels van de Linux Foundation, die inmiddels door veel hostingproviders wordt gebruikt. Voor WordPress gedraagt Valkey zich precies zoals Redis, en in de regel merk je er niets van.

Memcached is ouder en bewust eenvoudig gehouden. Het kent alleen sleutels en waarden, bewaart niets blijvend en verliest bij elke herstart zijn volledige inhoud. Daar staat tegenover dat het meerdere processorkernen tegelijk benut en heel eenvoudig over meerdere servers te verdelen is. Eén grens waar je bij WordPress af en toe tegenaan loopt: een enkel item mag standaard hooguit 1 MB groot zijn. Bij heel grote opties, zoals de opgeblazen instellingen van sommige page builders, kan dat problemen geven.

Ons advies: biedt je hostingprovider allebei aan, kies dan Redis. Is alleen Memcached beschikbaar, dan hoef je je geen zorgen te maken, want als object cache volstaat het prima. Veel belangrijker dan de keuze tussen die twee is dat er überhaupt een persistente object cache draait en dat die verstandig is ingesteld. Een derde kandidaat is trouwens APCu, een cache die direct in PHP zit. Die heeft geen aparte dienst nodig, maar werkt alleen op één server en speelt in de praktijk een kleinere rol.

Wanneer is een persistente object cache de moeite waard?

Een object cache is geen wondermiddel. Hoeveel hij oplevert, hangt ervan af hoeveel verzoeken langs de paginacache heen rechtstreeks bij WordPress terechtkomen en hoeveel werk de database daarbij heeft. Het effect is vooral merkbaar bij:

• Webshops met WooCommerce, want winkelwagen, afrekenpagina en klantaccount komen nooit uit de paginacache.
• Ledensites, leerplatforms en forums met veel ingelogde gebruikers.
• Redacties waar meerdere mensen tegelijk in de backend werken.
• Websites met veel plugins die hun gegevens in opties en transients opslaan.
• Grote websites met duizenden berichten, termen of gebruikers.

WordPress zelf geeft je hier een hint. Sinds versie 6.1 raadt de Sitediagnose onder Gereedschap een persistente object cache aan zodra je website bepaalde groottes overschrijdt, bijvoorbeeld meer dan 1.000 berichten, reacties of gebruikers.

Weinig zin heeft een object cache daarentegen bij een kleine bedrijfssite met tien pagina's, die bijna alleen anonieme bezoekers trekt en al een goede paginacache gebruikt. Daar beantwoordt de paginacache sowieso bijna elk verzoek, nog voordat WordPress opstart.

Hoe zet ik een object cache met Redis op in WordPress?

Hoe je dat precies doet, hangt af van je hosting. Bij veel aanbieders van managed hosting is Redis al aanwezig en zet je het met één schakelaar in het klantenpaneel aan, sommige regelen zelfs alles voor je. Vraag bij twijfel even na bij de helpdesk voordat je zelf iets installeert. Op een eigen server gaat het meestal zo:

1. Installeer en start Redis, op Debian of Ubuntu bijvoorbeeld met het pakket redis-server.
2. Installeer de extensie phpredis voor PHP (pakket php-redis), zodat PHP met Redis kan praten. De plugin heeft met Predis ook een variant aan boord die helemaal geen extensie nodig heeft, maar die is merkbaar trager.
3. Zet de verbindingsgegevens in wp-config.php, boven de regel die het einde van het bewerken markeert.
4. Installeer de plugin Redis Object Cache en activeer de object cache in de instellingen ervan. Daarbij maakt de plugin het bestand object-cache.php aan.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Een prefix stel je altijd in zodra meerdere websites dezelfde instantie van Redis delen. Zonder prefix kunnen twee installaties elkaars gegevens overschrijven, en dat levert heel vreemde fouten op. Werk je liever op de commandoregel, dan doe je de laatste stap met wp plugin install redis-cache --activate en daarna wp redis enable. Voor grote webshops bestaat er ook nog de betaalde oplossing Object Cache Pro.

Wat zijn de meest gemaakte fouten met een object cache?

Een object cache is snel ingesteld, maar een paar valkuilen duiken steeds weer op.

• Geen geheugenlimiet: zonder maxmemory groeit Redis door tot de server geen geheugen meer over heeft. Met een limiet maar met het standaardbeleid noeviction weigert Redis nieuwe items zodra het geheugen vol is, en WordPress geeft ineens foutmeldingen. Voor een cache is allkeys-lru de juiste keuze: Redis gooit dan gewoon de items eruit die het langst niet zijn gebruikt.
• Redis open op internet: Redis hoort alleen bereikbaar te zijn op 127.0.0.1 of in een privénetwerk en moet een wachtwoord hebben. Open instanties op poort 6379 worden op het net gericht opgespoord en misbruikt.
• Verouderde gegevens na directe wijzigingen: wie gegevens rechtstreeks in de database aanpast, bijvoorbeeld met phpMyAdmin of tijdens een import, gaat langs de cache heen. WordPress blijft dan de oude waarden tonen. Leeg de cache daarna, in de instellingen van de plugin of met wp cache flush.
• Een vergeten object-cache.php na een verhuizing: verhuis je naar een server zonder Redis, dan blijft het bestand soms in de map wp-content achter. In het onschuldige geval zie je alleen een melding in de beheeromgeving, in het ergste geval stopt WordPress met een fatale fout. Verwijder het bestand dan via FTP.
• Redis op een externe server: elke keer dat WordPress iets uit de cache haalt, gaat dat dan over het netwerk. Bij honderden van zulke opvragingen per paginaweergave vreet de vertraging een deel van de winst weer op. Redis hoort daarom bij voorkeur op dezelfde server, of op zijn minst in hetzelfde datacenter.

maxmemory 256mb
maxmemory-policy allkeys-lru

Deze twee regels in redis.conf zijn voor de meeste websites genoeg. Hoeveel geheugen je nodig hebt, hangt af van de grootte van de website. Voor een doorsnee webshop is 256 MB een goed startpunt.

Hoe controleer ik of de object cache werkt?

Of de cache echt zijn werk doet, kun je op verschillende manieren zien:

• In de plugin: Redis Object Cache laat in zijn instellingen zien of er verbinding is en geeft een kleine statistiek van hits en misses.
• Op de commandoregel: wp cache type vertelt je welke object cache actief is. Staat daar Default, dan draait er geen persistente cache.
• Met Query Monitor: de gratis plugin toont voor elke paginaweergave de hitrate van de object cache en het aantal databasequery's. Vergelijk de waarden eens met en zonder cache, het verschil is vaak groter dan je denkt.
• Direct in Redis: redis-cli info stats geeft onder andere keyspace_hits en keyspace_misses. Blijft de hitrate na een paar uur draaien laag, dan klopt er meestal iets niet aan de configuratie, bijvoorbeeld een te krappe geheugenlimiet.

Zo helpt InspectWP je de caching van je website te beoordelen

Een object cache werkt op de server, van buitenaf zie je hem dus niet rechtstreeks. Het effect wel. Het rapport van InspectWP meet onder meer de Time to First Byte, oftewel hoe lang de server nodig heeft voordat de eerste byte van de pagina binnenkomt. Waarden boven 800 milliseconden markeert InspectWP als waarschuwing, en precies daar helpt een object cache wanneer de pagina niet uit de paginacache komt. Daarnaast ziet InspectWP welke plugins voor caching worden ingezet, ook Redis Object Cache, dat het herkent aan het korte commentaar dat de plugin standaard in de broncode achterlaat. Samen met de gegevens over de hostingprovider, de server en de versie van PHP krijg je zo snel een gevoel voor de vraag of er bij de caching van een website nog winst te halen valt.