Caching in WordPress: pagina, object en browser uitgelegd
Paginacache, objectcache en browsercache uitgelegd: wat elke laag doet, wanneer je hem nodig hebt en waarom je winkelwagen er nooit in mag.
Je past een tekst aan, slaat op, ververst de pagina, en de oude tekst staat er nog. Of je hebt net een cacheplugin geïnstalleerd, en ineens loopt je winkelwagen niet meer. Allebei hebben met hetzelfde te maken: caching.
Caching is de grootste snelheidswinst die een WordPress-site kan halen. Maar het woord wordt voor drie heel verschillende dingen gebruikt. In dit artikel lees je wat elke laag doet, hoe je ze inzet en waar het misgaat.
Waarom WordPress caching nodig heeft
Een WordPress-pagina bestaat niet als bestand op de server. Bij elk bezoek start PHP, laadt WordPress alle actieve plugins en je thema, haalt de inhoud uit de database en bouwt daar een HTML-pagina van. Dat kost tijd, en bij elke bezoeker weer evenveel.
Terwijl je homepage voor de meeste bezoekers precies hetzelfde is. Caching betekent: het resultaat van dat werk bewaren en de volgende keer opnieuw gebruiken. De vraag is alleen welk resultaat, en waar je het bewaart.
Laag 1: de paginacache
De paginacache bewaart de volledige HTML van een pagina. Komt de volgende bezoeker, dan stuurt de server die kopie terug zonder dat WordPress hoeft te draaien. Daar zit de grootste winst, omdat het al het werk in één keer overslaat.
Die cache kan op twee plekken zitten:
- Op de server. De webserver bewaart de pagina’s zelf, nog voordat PHP in beeld komt. Dat is het snelst. Veel hosters die op WordPress gericht zijn, doen dit standaard. Ook op de servers waar ik sites op host, regelt de server de paginacache.
- In een plugin. Een cacheplugin schrijft de pagina’s als bestand weg en stuurt die terug. Dat werkt op vrijwel elke hosting, maar hangt meer af van hoe de server is ingericht. WP Rocket, WP Super Cache en LiteSpeed Cache werken zo. LiteSpeed Cache werkt alleen op een LiteSpeed-server echt goed.
Heeft je hoster al een paginacache, dan heb je geen cacheplugin nodig voor dat deel. Twee paginacaches over elkaar heen leveren niets op, behalve verwarring over welke je moet legen.
Of er een paginacache actief is, zie je in WordPress onder Gereedschap, Sitestatus. Je kunt het ook in de headers zien. Open in je browser de ontwikkelaarstools, tabblad Netwerk, laad de pagina twee keer en klik op het eerste verzoek. Staat er iets als x-cache: HIT of cf-cache-status: HIT, dan kwam de pagina uit de cache.
Wat er niet in de cache mag
Een paginacache is alleen goed voor pagina’s die voor iedereen hetzelfde zijn. Alles wat per bezoeker verschilt, moet erbuiten blijven:
- Ingelogde gebruikers. Die krijgen bijna altijd de echte pagina, ook jij als beheerder.
- De winkelwagen, de afrekenpagina en Mijn account in een webshop.
- Pagina’s met een formulier dat een beveiligingscode per bezoeker gebruikt, zoals een nonce. Een verouderde code in een gecachte pagina geeft een foutmelding bij het versturen.
Goede cacheplugins en hosters slaan WooCommerce-pagina’s automatisch over. Bij een eigen opzet of een minder bekende plugin moet je het zelf instellen.
Laag 2: de objectcache
De paginacache helpt niet voor alles. Een ingelogde redacteur, een zoekopdracht, een gefilterd productoverzicht: die pagina’s moet WordPress toch zelf bouwen. Daar helpt de objectcache.
WordPress stelt bij het opbouwen van een pagina tientallen tot honderden vragen aan de database. Veel daarvan zijn bij elk verzoek hetzelfde. De objectcache onthoudt de antwoorden, zodat de database niet elke keer opnieuw hoeft te zoeken.
Standaard onthoudt WordPress die antwoorden alleen tijdens één verzoek. Daarna is alles weer weg. Met een blijvende objectcache, meestal Redis, blijven ze bewaard tussen verzoeken door. Daarvoor heb je twee dingen nodig: Redis op de server, wat je hoster moet aanbieden, en een plugin die WordPress ermee verbindt, zoals Redis Object Cache.
Het verschil merk je vooral bij webshops, sites met veel ingelogde gebruikers en een trage beheeromgeving. Bij een kleine bedrijfssite waar bijna alles uit de paginacache komt, merk je er weinig van. Sitestatus raadt het aan zodra er geen blijvende objectcache is, maar voor een kleine site is dat geen probleem.
Laag 3: de browsercache
De derde laag zit niet op de server, maar bij de bezoeker. Een browser kan afbeeldingen, lettertypes, CSS en JavaScript bewaren. Opent iemand een tweede pagina op je site, dan hoeven die niet opnieuw te worden opgehaald.
Hoe lang de browser iets bewaart, bepaalt de server met een header, Cache-Control. Voor afbeeldingen en lettertypes mag dat lang, een maand of zelfs een jaar. Voor de HTML van je pagina’s juist kort, anders zien terugkerende bezoekers je wijzigingen niet.
Maar als de browser je CSS een jaar bewaart, hoe krijgen bezoekers dan je nieuwe stijl? Door de bestandsnaam te laten veranderen. WordPress zet een versienummer achter elk bestand, zoals style.css?ver=1.4. Verandert dat nummer, dan ziet de browser een nieuw bestand en haalt het op. Een goed thema verhoogt dat nummer zelf bij elke wijziging.
Deze headers stel je in bij je hoster, in een cacheplugin, of via een CDN zoals Cloudflare. Of ze goed staan, zie je in PageSpeed Insights bij “statische items weergeven met een efficiënt cachebeleid”.
Waar Cloudflare in past
Een CDN zit tussen je bezoeker en je server, en bewaart kopieën van je bestanden op servers overal ter wereld. Standaard cachet Cloudflare alleen bestanden als afbeeldingen, CSS en JavaScript, niet je pagina’s. Dat kan wel, maar dan moet je goed instellen wat er wel en niet in mag, om de redenen hierboven. Voor een site met vooral Nederlandse bezoekers op een snelle Nederlandse of Duitse server is de winst van een CDN kleiner dan vaak gedacht.
Je cache legen als je iets aanpast
Zie je een wijziging niet terug, werk dan van buiten naar binnen:
- Je eigen browser. Open de pagina in een privévenster. Zie je het daar wel, dan is het je browsercache.
- De paginacache. Leeg die in je cacheplugin of in het paneel van je hoster. De meeste caches legen een pagina automatisch zodra je hem opslaat, maar niet altijd de overzichten waar hij in voorkomt.
- Het CDN. Gebruik je Cloudflare, leeg daar dan ook de cache, of alleen de URL van die pagina.
- De objectcache. Gaat het om instellingen of menu’s die niet veranderen, leeg dan de objectcache. Met WP-CLI is dat
wp cache flush.
Waar het meestal misgaat
- Twee caches die hetzelfde doen. Een cacheplugin bovenop de servercache van je hoster. Je weet niet meer welke je moet legen, en ze kunnen elkaar in de weg zitten.
- De winkelwagen in de cache. Bezoekers zien de winkelwagen van iemand anders, of hun product verdwijnt. Sluit winkelwagen, afrekenen en account altijd uit.
- Formulieren die na een dag niet meer werken. Een gecachte pagina met een verlopen beveiligingscode. Sluit de pagina uit van de cache, of zorg dat de cache vaker ververst wordt dan de code verloopt.
- Testen terwijl je bent ingelogd. Ingelogd krijg je geen cache, dus je ziet niet wat een bezoeker ziet. Test altijd in een privévenster.
- Alle optimalisaties aanzetten. Cacheplugins kunnen ook CSS en JavaScript samenvoegen en uitstellen. Dat breekt vaker iets dan het cachen zelf. Zet die opties een voor een aan en test na elke stap.
Tot slot
Begin bij de paginacache, want daar zit de grootste winst. Zet er een objectcache bij als je een webshop of veel ingelogde gebruikers hebt. En zorg dat de browsercache goed staat, zodat terugkerende bezoekers niets dubbel hoeven op te halen. Wat caching verder voor je snelheid doet, lees je in WordPress-site traag? Zo vind je waar de tijd zit.
Loopt er iets vast door je cache, of wil je dat iemand het goed instelt? Als WordPress specialist zoek ik uit welke laag het probleem geeft.