Wat is caching in WordPress?

Caching slaat een kopie van gegenereerde inhoud op, zodat deze sneller kan worden geleverd bij volgende verzoeken, zonder dat alles opnieuw hoeft te worden gegenereerd. Voor WordPress betekent dit dat PHP-uitvoering en databasequery's voor herhaalde paginaweergaven worden overgeslagen. Een WordPress-pagina die 800 ms nodig heeft om vanaf nul te worden gegenereerd, kan in minder dan 50 ms worden geleverd wanneer deze in de cache staat. Caching is een van de meest impactvolle optimalisaties die u voor elke WordPress-site kunt doorvoeren.

De vijf typen WordPress-caching

Caching in WordPress is geen op zichzelf staand iets. Er zijn vijf afzonderlijke lagen, die elk op een ander punt in de verzoekcyclus actief zijn. Begrijpen wat elke laag doet, helpt u de juiste cachingstrategie voor uw site te kiezen.

Browsercache

De browsercache is de eerste laag en werkt volledig op het apparaat van de bezoeker. Wanneer een browser een CSS-bestand, een afbeelding of een JavaScript-bestand downloadt, slaat hij hiervan een lokale kopie op. Bij de volgende paginalading controleert de browser of de cachekopie nog geldig is (op basis van Cache-Control-, Expires- en ETag-koptekstwaarden) en slaat de download volledig over als dat zo is. Dit elimineert netwerkverzoeken en zorgt ervoor dat volgende paginaweergaven voor terugkerende bezoekers vrijwel onmiddellijk aanvoelen.

U bestuurt browsercaching via HTTP-responskopteksten. De belangrijkste zijn:

• Cache-Control: max-age=31536000: vertelt de browser het bestand een jaar (31.536.000 seconden) in de cache te bewaren. Wordt gebruikt voor versiegebonden statische assets die een nieuwe bestandsnaam krijgen wanneer ze veranderen.
• Cache-Control: no-cache: de browser moet bij de server controleren voordat hij de cachekopie gebruikt. De server kan reageren met "304 Not Modified" als het bestand niet is gewijzigd, wat bandbreedte bespaart.
• Cache-Control: no-store: de browser mag deze respons nooit cachen. Wordt gebruikt voor gevoelige of zeer dynamische inhoud.

Paginacache

Paginacaching is de grootste prestatiewinst voor de meeste WordPress-sites. Dit is het probleem dat het oplost: bij elk paginaverzoek laadt WordPress zijn kern, initialiseert de databaseverbinding, voert tientallen databasequery's uit, verwerkt plug-inhooks en rendert thema-templates. Deze PHP/MySQL-cyclus duurt 200 ms tot meerdere seconden, afhankelijk van uw server en de complexiteit van uw site. Hij produceert dezelfde HTML-uitvoer voor elke anonieme bezoeker.

Een paginacache slaat die HTML-uitvoer op na het eerste verzoek. Wanneer de volgende bezoeker dezelfde pagina opvraagt, wordt het gecachete HTML-bestand rechtstreeks door de webserver geleverd (of zelfs door een reverse proxy ervoor), waarbij WordPress, PHP en de database volledig worden omzeild. Het verschil is dramatisch. In plaats van 50-200 databasequery's uit te voeren en duizenden regels PHP uit te voeren, leest de server eenvoudig een bestand en verstuurt het.

Objectcache

De objectcache bevindt zich tussen WordPress en de database. WordPress vraagt vaak dezelfde gegevens herhaaldelijk op binnen een enkele paginalading en over paginaladingen heen: opties, gebruikersmetagegevens, postgegevens, transients. De objectcache slaat deze queryresultaten op in het geheugen (met Redis of Memcached) zodat ze niet elke keer de database raken.

WordPress heeft een ingebouwde objectcache, maar standaard werkt deze alleen binnen één verzoek (hij blijft niet bestaan tussen verzoeken). Voor persistente objectcaching hebt u een drop-in plug-in nodig die WordPress verbindt met Redis of Memcached. Populaire opties zijn Redis Object Cache en Object Cache Pro.

Objectcaching is bijzonder waardevol voor sites die geen volledige paginacaching kunnen gebruiken, zoals WooCommerce-winkels met gepersonaliseerde inhoud, lidmaatschapssites of fora waar inhoud vaak verandert.

Opcode-cache (OPcache)

Telkens wanneer PHP een script verwerkt, compileert het eerst de menselijk leesbare PHP-code in bytecode (machineleesbare instructies). Deze compilatiestap wordt bij elk verzoek herhaald, tenzij opcode-caching is ingeschakeld. De ingebouwde OPcache-extensie van PHP slaat de gecompileerde bytecode op in gedeeld geheugen, waardoor de compilatiestap voor volgende verzoeken wordt geëlimineerd.

OPcache is een instelling op serverniveau, niet iets dat u via WordPress configureert. De meeste moderne hostingomgevingen hebben OPcache standaard ingeschakeld. U kunt dit verifiëren door uw PHP-configuratie (phpinfo) te controleren of door dit aan uw hostingprovider te vragen. Alleen al OPcache kan de PHP-uitvoeringssnelheid met 30-50% verbeteren.

CDN-cache

Een CDN (Content Delivery Network) cachet uw statische assets op edgeservers verspreid over de hele wereld. Wanneer een bezoeker in Tokio een afbeelding opvraagt van uw WordPress-site die in Amsterdam wordt gehost, levert het CDN deze vanaf een nabijgelegen edgeserver in plaats van het verzoek helemaal naar Amsterdam te routeren. Dit vermindert de latentie voor statische assets aanzienlijk. Sommige CDN-aanbieders zoals Cloudflare bieden ook volledige paginacaching voor WordPress via hun APO-functie. Zie voor meer details ons artikel over Content Delivery Networks.

Hoe paginacaching stap voor stap werkt

Aangezien paginacaching de grootste impact heeft, hier een nadere blik op hoe het in de praktijk werkt:

1. Een bezoeker vraagt uwdomein.com/over/ voor het eerst op.
2. WordPress verwerkt het verzoek normaal: PHP draait, de database wordt bevraagd, het thema-template wordt gerenderd en de HTML wordt gegenereerd.
3. De cachingplug-in slaat een kopie van de voltooide HTML op in het bestandssysteem (meestal in wp-content/cache/) of in het geheugen.
4. Een tweede bezoeker vraagt uwdomein.com/over/ op.
5. De cachingplug-in onderschept het verzoek voordat WordPress laadt. Hij vindt het gecachete HTML-bestand en levert het rechtstreeks. PHP wordt nauwelijks uitgevoerd en de database wordt niet aangeraakt.
6. Wanneer de pagina-inhoud verandert (een bericht wordt bijgewerkt, een reactie wordt goedgekeurd), wordt de cache voor die specifieke pagina ongeldig gemaakt en genereert het volgende verzoek een nieuwe kopie.

Vergelijking van populaire WordPress-cachingplug-ins

Er zijn veel cachingplug-ins beschikbaar voor WordPress. Hier zijn de meest gebruikte en hoe ze zich verhouden:

• WP Rocket: een premium plug-in (vanaf $59/jaar) die algemeen wordt beschouwd als de meest gebruiksvriendelijke cachingoplossing. Het schakelt paginacaching, browsercaching, GZIP-compressie en lazy loading direct in met minimale configuratie. WP Rocket verzorgt ook CSS/JS-minificatie, databaseoptimalisatie en integreert met Cloudflare voor het wissen van CDN-cache. Het is de beste keuze voor site-eigenaren die uitstekende prestaties willen zonder uren aan configuratie te besteden.
• W3 Total Cache: een gratis plug-in met een enorm scala aan functies. Het ondersteunt paginacaching, objectcaching (Redis, Memcached, APCu), browsercaching, CDN-integratie en minificatie. Het nadeel is complexiteit. W3 Total Cache heeft tientallen instellingenpagina's en een verkeerde configuratie kan uw site stuk maken. Het is krachtig, maar beter geschikt voor ontwikkelaars of gevorderde gebruikers.
• WP Super Cache: een gratis plug-in ontwikkeld door Automattic (het bedrijf achter WordPress.com). Het richt zich op paginacaching en houdt het simpel. WP Super Cache genereert statische HTML-bestanden en kan deze leveren met mod_rewrite-regels, wat zeer snel is. Het mist de geavanceerde functies van WP Rocket en W3 Total Cache, maar is betrouwbaar en eenvoudig te configureren.
• LiteSpeed Cache: een gratis plug-in die uitzonderlijke prestaties levert wanneer deze wordt gebruikt met LiteSpeed-webservers. Het ondersteunt paginacaching, objectcaching, beeldoptimalisatie, CSS/JS-minificatie en CDN-integratie. Als uw hosting LiteSpeed gebruikt (wat veel shared hosts doen), profiteert deze plug-in van caching op serverniveau die sneller is dan PHP-gebaseerde caching. Het werkt ook op Apache en Nginx, maar met beperkte functionaliteit.

Cachingoplossingen op serverniveau

Naast WordPress-plug-ins kan caching ook op serverniveau plaatsvinden, wat vaak sneller is omdat het verzoeken onderschept voordat PHP er zelfs maar bij betrokken is:

• Varnish: een reverse proxy-cache die zich vóór uw webserver bevindt. Varnish slaat volledige paginaresponsen op in het geheugen en levert ze rechtstreeks voor gecachete verzoeken. Het is extreem snel (sub-milliseconde responstijden) en wordt gebruikt door WordPress-sites met veel verkeer. Configuratie vereist VCL (Varnish Configuration Language), wat een leercurve heeft.
• Nginx FastCGI Cache: als uw server Nginx gebruikt (wat veel moderne WordPress-hosts doen), slaat FastCGI-caching de volledige PHP-uitvoer op en levert deze rechtstreeks vanuit Nginx voor volgende verzoeken. Dit is sneller dan elke PHP-gebaseerde cachingplug-in omdat Nginx het verzoek volledig afhandelt zonder PHP aan te roepen. Veel managed WordPress-hosts (Kinsta, GridPane, SpinupWP) gebruiken deze aanpak.
• Redis Full-Page Cache: sommige opstellingen gebruiken Redis niet alleen voor objectcaching, maar ook voor volledige paginacaching. De gecachete HTML wordt opgeslagen in het Redis-geheugen en een klein PHP-script of Nginx-module levert het rechtstreeks. Dit combineert de snelheid van in-memory opslag met de flexibiliteit van op sleutels gebaseerde cache-invalidatie.

Objectcaching met Redis en Memcached

Voor WordPress-sites die te maken hebben met zware databasebelastingen kan persistente objectcaching transformerend zijn. Hier is hoe de twee belangrijkste opties zich verhouden:

• Redis: de populairste keuze voor WordPress. Redis slaat gegevens op in het geheugen en ondersteunt complexe gegevenstypen (strings, hashes, lijsten, sets). Het kan gegevens persisteren naar schijf, ondersteunt replicatie en kan worden gebruikt voor zowel objectcaching als sessieopslag. De plug-in Redis Object Cache is de meest gebruikelijke manier om WordPress te verbinden met Redis.
• Memcached: een ouder, eenvoudiger in-memory cachingsysteem. Memcached is snel en lichtgewicht, maar mist de gegevenspersistentie en geavanceerde functies van Redis. Het wordt nog steeds gebruikt in sommige hostingomgevingen, met name oudere.

Persistente objectcaching maakt het grootste verschil op sites met complexe query's: WooCommerce-winkels met duizenden producten, BuddyPress-gemeenschappen, multisite-netwerken of elke site waarop het WordPress-beheerdashboard traag aanvoelt.

Wanneer caching problemen veroorzaakt

Caching is niet altijd eenvoudig. Er zijn situaties waarin agressieve caching problemen veroorzaakt:

• Ingelogde gebruikers: paginacaching mag geen gecachete pagina's leveren aan ingelogde gebruikers, omdat elke gebruiker andere inhoud ziet (hun naam in de koptekst, beheerbalk, persoonlijk dashboard). Alle grote cachingplug-ins handelen dit standaard correct af, maar aangepaste implementaties doen dit soms verkeerd.
• WooCommerce en e-commerce: winkelwagentjes, afrekenpagina's en "mijn account"-pagina's zijn dynamisch en gebruikersspecifiek. Ze moeten worden uitgesloten van paginacaching. WP Rocket en LiteSpeed Cache sluiten WooCommerce-pagina's automatisch uit. Bij andere plug-ins moet u uitsluitingen mogelijk handmatig configureren.
• Dynamische inhoud en AJAX: als uw site sterk vertrouwt op AJAX-geladen inhoud, realtime gegevens of gepersonaliseerde elementen (recent bekeken producten, gebruikersspecifieke aanbevelingen), kan volledige paginacaching verouderde inhoud leveren. Oplossingen zijn onder meer fragmentcaching (alles cachen behalve dynamische delen) of dynamische inhoud laden via JavaScript nadat de gecachete pagina is geladen.
• Lidmaatschapssites: sites met meerdere lidmaatschapsniveaus tonen verschillende inhoud aan verschillende gebruikersgroepen. Paginacaching moet rekening houden met deze variaties, ofwel door de cache over te slaan voor ingelogde gebruikers, ofwel door afzonderlijke gecachete versies per gebruikersrol bij te houden (wat de meeste plug-ins niet ondersteunen).
• Formulieren en nonces: WordPress gebruikt nonces (number-used-once-tokens) voor beveiliging in formulieren. Als een pagina met een formulier wordt gecachet, krijgen alle bezoekers dezelfde nonce, die kan verlopen en formulierverzendingsfouten kan veroorzaken. Cachingplug-ins handelen dit meestal af, maar het is een veelvoorkomende bron van problemen met aangepaste formulieren.

Cache-invalidatie: het moeilijke deel

Er bestaat een beroemd gezegde in de informatica: "Er zijn slechts twee moeilijke dingen in de informatica: cache-invalidatie en het benoemen van dingen." Cache-invalidatie is het proces van het wissen of bijwerken van gecachete inhoud wanneer de onderliggende gegevens veranderen. In WordPress betekent dit:

• Wanneer u een bericht publiceert of bijwerkt, moet de cache voor dat bericht, de categorie-archieven, tag-archieven, de homepage en elke pagina die recente berichten weergeeft, worden gewist.
• Wanneer u thema-instellingen wijzigt, moet de volledige paginacache worden gewist, omdat elke pagina er anders uit kan zien.
• Wanneer een nieuwe reactie wordt goedgekeurd, moet de gecachete versie van dat bericht worden bijgewerkt om de nieuwe reactie weer te geven.

Goede cachingplug-ins handelen de meeste van deze scenario's automatisch af via WordPress-hooks. Ze luisteren naar gebeurtenissen zoals save_post, switch_theme en wp_update_comment_count en wissen de relevante cache-items. Als u echter aangepaste code hebt die inhoud wijzigt zonder de standaardfuncties van WordPress te doorlopen, wordt de cache mogelijk niet correct ongeldig gemaakt.

In geval van twijfel bieden de meeste cachingplug-ins een knop "Alle cache wissen" in de WordPress-beheerbalk. Gebruik deze nadat u belangrijke wijzigingen hebt aangebracht als gecachete pagina's uw updates niet weerspiegelen.

Wat InspectWP controleert

InspectWP detecteert of een WordPress-cachingplug-in actief is door te zoeken naar cachegerelateerde HTML-opmerkingen (veel plug-ins voegen een opmerking toe zoals <!-- Cached by WP Rocket --> onderaan de pagina), responskopteksten (zoals X-Cache, X-Cache-Enabled of X-LiteSpeed-Cache) en bekende plug-inhandtekeningen in de paginabron. Het rapport identificeert welke cachingplug-in in gebruik is, zodat u kunt verifiëren dat uw cachingopzet correct werkt. Als er geen caching wordt gedetecteerd, markeert InspectWP dit als een mogelijkheid voor prestatieverbetering, aangezien caching een van de meest effectieve manieren is om elke WordPress-site sneller te maken.