“Ik heb de tekst aangepast, maar op mijn telefoon staat de oude versie er nog.” Van alle meldingen die wij krijgen, is dit misschien wel de meest voorkomende. En bijna altijd is het antwoord hetzelfde: er staat ergens nog iets in het geheugen. Alleen is “ergens” het probleem, want caching in WordPress speelt zich af op vier verschillende plekken tegelijk.

Zodra u weet welke lagen er zijn en wat elke laag bewaart, houdt caching op een mysterie te zijn. U begrijpt dan waarom sommige wijzigingen direct zichtbaar zijn en andere niet, waarom uw collega iets anders ziet dan u, en waarom “cache legen” bij de een wel werkt en bij de ander niet. In dit artikel loopt u de vier lagen langs, van dichtbij de bezoeker tot diep in de server.

Wat cache eigenlijk is

Een WordPress-pagina bestaat niet als bestand. Bij elk bezoek voert de server PHP-code uit, haalt gegevens uit de database, laat het thema er opmaak omheen bouwen en stuurt het resultaat op. Dat kost rekentijd, elke keer opnieuw, ook als er niets veranderd is.

Caching slaat het resultaat van dat werk op, zodat de volgende bezoeker het kant-en-klaar krijgt. Dat is de kern. De prijs die u ervoor betaalt, is dat een bewaarde versie per definitie iets ouder is dan de werkelijkheid. Al het gedoe rond caching komt voort uit die ene spanning: snelheid tegenover actualiteit.

Laag 1: de browsercache

De eerste laag zit niet op uw server, maar op de computer of telefoon van de bezoeker. De browser bewaart afbeeldingen, stijlbestanden en scripts lokaal, zodat hij ze bij een volgend bezoek niet opnieuw hoeft op te halen. Uw server geeft daarbij aan hoe lang die bestanden geldig blijven.

Voor terugkerende bezoekers scheelt dit enorm. Het verklaart ook waarom uw site voor uzelf snel voelt terwijl een nieuwe bezoeker een trager beeld krijgt: u hebt alles al staan. Test daarom altijd in een privévenster.

Het nadeel: als u de stijl aanpast, kan een terugkerende bezoeker nog dagen de oude opmaak zien. Goede thema’s en plugins lossen dat op door een versienummer aan de bestandsnaam te hangen. Verandert dat nummer, dan haalt de browser het bestand opnieuw op. Gaat het bij u mis, dan is dat vaak omdat een aanpassing rechtstreeks in een bestand is gedaan zonder dat versienummer te verhogen.

Laag 2: de paginacache

Dit is de laag waar de meeste snelheidswinst zit en waar de meeste verwarring ontstaat. Een paginacache bewaart de complete HTML van een pagina, zodat de server bij het volgende bezoek geen PHP hoeft uit te voeren en de database met rust laat.

Paginacache kan op drie plekken zitten: in een plugin, bij uw hostingpartij op serverniveau, of bij een extern netwerk. In de praktijk zit hij vaak op twee van die plekken tegelijk, zonder dat de eigenaar dat doorheeft. Dat is de klassieke oorzaak van “ik heb de cache geleegd maar ik zie het nog steeds”: u leegde de plugincache, terwijl de server er nog een bewaarde versie boven had liggen.

Let daarbij op drie uitzonderingen die altijd buiten de paginacache moeten blijven:

  • Ingelogde gebruikers, want die horen persoonlijke informatie te zien.
  • De winkelwagen en afrekenpagina van een webshop, anders ziet de ene klant de bestelling van de andere.
  • Pagina’s met formulieren die een beveiligingssleutel gebruiken, want die sleutel verloopt.

Bijna elke fatsoenlijke cacheoplossing regelt dit standaard, maar bij een zelfgebouwde of sterk aangepaste site is het het eerste dat u controleert.

Laag 3: objectcache

De derde laag zit dieper en is minder zichtbaar. WordPress stelt tijdens het opbouwen van een pagina tientallen tot honderden vragen aan de database: welke instellingen, welke menu-items, welke producten. Een objectcache bewaart de antwoorden op die vragen in het werkgeheugen, zodat ze niet telkens opnieuw opgezocht hoeven te worden.

Standaard doet WordPress dit alleen binnen één paginaverzoek. Met een aanvulling als Redis of Memcached blijft het bewaard tussen verzoeken door. Voor een eenvoudige bedrijfssite met paginacache merkt u daar weinig van. Voor een webshop of ledensite, waar veel bezoekers ingelogd zijn en de paginacache dus niets doet, is dit vaak de grootste winst die er te halen valt. Wij schreven daar apart over in ons stuk over objectcaching met Redis.

Laag 4: de opcodecache

De vierde laag ligt op serverniveau en u hoeft er zelden iets aan te doen. PHP moet code eerst vertalen naar iets wat de processor begrijpt. OPcache bewaart die vertaling, zodat dat werk niet bij elk bezoek opnieuw gebeurt.

Vrijwel elke serieuze hostingpartij heeft dit aanstaan. U merkt het pas als het misgaat: na een update van een plugin ziet u soms nog even oude code draaien, of krijgt u een foutmelding die nergens op slaat. Een herstart van PHP of het legen van OPcache lost dat op. Staat het bij uw hostingpartij uit, dan is dat een reden om daar vragen over te stellen.

De juiste volgorde bij het legen

Als een wijziging niet zichtbaar wordt, werk dan van binnen naar buiten. Deze volgorde bespaart u veel zoekwerk:

  1. Leeg de objectcache, als u die hebt.
  2. Leeg de paginacache in uw plugin.
  3. Leeg de servercache in het hostingpaneel.
  4. Leeg de cache bij uw CDN of netwerkdienst.
  5. Ververs uw eigen browser hard, met Ctrl en Shift en R tegelijk.
  6. Controleer in een privévenster, niet in het venster waar u al ingelogd bent.

Moet u dit vaker dan eens per week doen, dan klopt er iets niet in de instellingen. Meestal staat de bewaartijd te lang, of ontbreekt de koppeling die de cache automatisch leegt bij het opslaan van een pagina.

Een praktijkvoorbeeld

Een cateringbedrijf uit Apeldoorn paste elke maandag het weekmenu aan. Klanten belden regelmatig over gerechten die er niet meer waren. De eigenaar leegde trouw de cache in zijn plugin, en toch bleef het gebeuren.

Wat er speelde: het hostingpakket had zelf ook een paginacache met een bewaartijd van 24 uur, waar de plugin niets van wist. De oplossing was niet ingewikkeld: de plugincache uit, de servercache aan met een koppeling die hem leegt zodra een pagina wordt opgeslagen. Sindsdien is het menu binnen een minuut actueel en is de site bovendien iets sneller, omdat er één laag minder werk gedaan wordt.

Wanneer u er iemand bij haalt

Caching zelf instellen kan prima, zeker als u één plugin gebruikt en verder niets. Het wordt lastiger zodra er meerdere lagen naast elkaar staan, of als u een webshop draait waar de winkelwagen zich vreemd gedraagt. Dan bent u niet aan het instellen maar aan het gokken.

In dat geval loont het om de lagen één keer goed op elkaar af te stemmen, bijvoorbeeld als onderdeel van een gerichte snelheidsoptimalisatie. Daarna is caching iets waar u niet meer aan hoeft te denken, en dat is precies wat het hoort te zijn.

Tot besluit

Vier lagen, elk met een eigen taak: de browser bewaart bestanden, de paginacache bewaart complete pagina’s, de objectcache bewaart databasegegevens en de opcodecache bewaart vertaalde code. Uw eerstvolgende stap is een inventarisatie: kijk in uw pluginlijst en in uw hostingpaneel welke lagen er op dit moment actief zijn. In veel gevallen zijn dat er één te veel.