Elk snelheidsadvies zegt “installeer een cachingplugin”, maar welke, en wat doet die eigenlijk? WordPress kent vier cachinglagen: browsercaching, paginacaching, object caching voor databasequery’s en servercaching zoals LiteSpeed. Paginacaching levert de grootste winst, object caching is vooral zinvol voor webshops en ingelogde gebruikers. Hieronder lees je welke lagen je nodig hebt en hoe je caching instelt zonder je webshop te breken. Caching is een van de stappen uit WordPress sneller maken: de complete gids.
Wat is caching?
Caching is het bewaren van een kant-en-klaar resultaat, zodat het niet bij elk bezoek opnieuw berekend hoeft te worden. Zonder cache bouwt WordPress elke pagina voor elke bezoeker vanaf nul op. De server draait de PHP-code, haalt de inhoud uit de MySQL-database, plakt alles aan elkaar en stuurt pas dan de HTML terug. Met caching gebeurt dat werk één keer, en krijgen volgende bezoekers een opgeslagen HTML-kopie. Dat scheelt rekenwerk, dus de server houdt het bij drukte langer vol en de TTFB, de tijd tot het eerste antwoord van de server, wordt korter.
Ik leg het altijd uit met een bakker. Die legt zijn best verkochte broden ’s ochtends al klaar, in plaats van elk brood pas te bakken als de klant binnenstapt. Een taart op bestelling maakt hij wél vers, en in WordPress zijn dat de winkelwagen en de checkout. Daar kom ik verderop op terug. Het nadeel van klaarliggend brood is dat het niet vanzelf ververst. Pas je iets aan en zie je nog de oude versie, dan moet de cache worden geleegd. Hoe dat werkt, lees je bij cache legen in WordPress.
De vier cachinglagen op een rij
De vier lagen bewaren elk iets anders op een andere plek, en ze vullen elkaar aan in plaats van elkaar te vervangen.
| Laag | Wat wordt bewaard | Waar | Wie stelt het in |
|---|---|---|---|
| Browsercaching | Afbeeldingen, CSS, JavaScript | Browser van de bezoeker | Cachingplugin of server |
| Paginacaching | Complete HTML-pagina’s | Server | Cachingplugin |
| Object caching | Resultaten van databasequery’s | Werkgeheugen (Redis, Memcached) | Hosting plus plugin |
| Servercaching | Pagina’s, nog vóór WordPress start | Webserver (LiteSpeed) | Hosting |
Browsercaching bewaart statische bestanden in de browser van je bezoeker, met een vervaltijd. De server geeft dat mee in headers als Cache-Control met max-age, Expires en ETag. Komt iemand terug en is een bestand niet veranderd, dan antwoordt de server met statuscode 304 in plaats van alles opnieuw te versturen. Dat merk je vooral bij terugkerende bezoekers.
Paginacaching bewaart hele HTML-pagina’s, zodat de server ze niet voor elke bezoeker opnieuw opbouwt. Dit levert de grootste winst op voor bezoekers die niet zijn ingelogd, en dat is op de meeste sites vrijwel iedereen. Mijn advies is dan ook om hier te beginnen. Daarnaast bestaan nog OPcache, die gecompileerde PHP-code bewaart, en CDN-caching op servers verspreid over de wereld. Die eerste regelt je hostingpartij, bij Surver staat OPcache standaard aan.
Object caching en servercaching: wanneer heb je ze nodig?
Object caching bewaart de resultaten van databasequery’s in het werkgeheugen, meestal via Redis of Memcached, en helpt juist waar paginacaching niet kan. Een WooCommerce-webshop, een ledensite of je eigen dashboard laat zich slecht als HTML-kopie bewaren, omdat de inhoud per bezoeker verschilt. Dan scheelt het als de database niet steeds dezelfde vraag hoeft te beantwoorden. In Sitediagnose raadt WordPress soms een persistente objectcache aan. Dat vraagt Redis of Memcached op de server, en bij Surver zit Redis alleen op Surver Cloud. Op shared hosting kun je die melding gerust laten staan zolang je paginacaching goed is ingesteld. Meer achtergrond vind je in object caching en Redis uitgelegd.
Servercaching is caching die de webserver zelf doet, zoals LiteSpeed of Varnish. Dat is sneller dan caching via een PHP-plugin, omdat WordPress niet eens hoeft te starten. Het vereist wel dat je hostingpartij de juiste webserver draait. Op een LiteSpeed-server werkt de plugin LiteSpeed Cache rechtstreeks samen met de servercache, wat je met een andere plugin niet krijgt. Meer daarover in waaruit snelle WordPress hosting bestaat.
Wat heb je dan nodig? Voor een bedrijfssite of blog is paginacaching plus browsercaching genoeg, met servercaching als je host die heeft. Een drukbezochte contentsite met veel internationaal verkeer heeft daarnaast baat bij een CDN voor WordPress. Pas bij een webshop of ledensite met veel ingelogde gebruikers wordt object caching interessant.
Caching instellen en controleren
Caching stel je in met één cachingplugin die past bij je webserver, en daarna controleer je of hij echt werkt. Zo pak ik het zelf aan.
- Check welke webserver je hostingpartij gebruikt.
- Kies de plugin die daarbij past. Op een LiteSpeed-server is dat LiteSpeed Cache, elders bijvoorbeeld WP Super Cache, W3 Total Cache of WP Rocket.
- Gebruik maar één cachingplugin, en geen plugin naast de cache van je host als die dezelfde laag doet.
- Zet paginacaching en browsercaching aan.
- Stel een vervaltijd in en laat de cache voorladen (preload, bij LiteSpeed Cache heet dat de crawler), zodat de eerste bezoeker niet op een lege cache wacht.
- Controleer de standaarduitsluitingen en test uitgelogd in een privévenster.
Die derde stap is belangrijker dan hij lijkt. Twee caches die dezelfde laag doen, maken je site niet sneller maar onvoorspelbaar, met verouderde pagina’s en kapotte lay-outs als gevolg. Of het werkt, zie je in de ontwikkelaarstools van je browser. Open de Netwerk-tab, laad de pagina uitgelogd twee keer en bekijk de response-header. Op een LiteSpeed-server staat bij het tweede verzoek x-litespeed-cache: hit, andere plugins sturen een vergelijkbare header. Wil je caching niet zelf instellen en bijhouden, dan hoort het bij WordPress beheer.
Pagina’s die je nooit moet cachen
Pagina’s met persoonlijke of steeds wisselende inhoud horen nooit in de paginacache, omdat de ene bezoeker anders de gegevens van de andere te zien krijgt. Dit zijn ze.
- De winkelwagen, de checkout en Mijn account.
- Pagina’s voor ingelogde gebruikers. WordPress herkent die aan een cookie, en de cachingplugin laat ze daardoor buiten de paginacache.
- Pagina’s met formulieren of inhoud die per bezoeker verschilt.
Gaat dit mis, dan ziet een klant ineens de winkelwagen van een ander of werkt je contactformulier niet meer. De meeste cachingplugins sluiten de kernpagina’s van WooCommerce automatisch uit, maar ik controleer het altijd even. Een webshop draait het best op hosting die daarop is ingericht, zoals managed WooCommerce hosting. Blijft je shop traag, lees dan WooCommerce-webshop traag.
Wat we bij Surver standaard regelen, scheelt je een flink deel van dit werk. Alle shared pakketten van onze managed WordPress hosting draaien op LiteSpeed-servers met NVMe-opslag, en LiteSpeed Cache is daar de plugin die past. Bij een nieuw pakket installeren we WordPress via Installatron met LiteSpeed Cache erbij. Installeer je zelf, dan voeg je de plugin zelf toe. Staat caching goed en is je site nog traag, dan ligt de oorzaak ergens anders. Volg dan de complete gids of laat ons kijken met WordPress snelheid optimalisatie.
Veelgestelde vragen
Is WP Rocket of LiteSpeed Cache beter?
Dat hangt af van je webserver. Op een LiteSpeed-server gebruik je LiteSpeed Cache, omdat die met de servercache samenwerkt. Elders is WP Rocket (betaald) een prima keuze, net als het gratis WP Super Cache.
Kan caching mijn site kapotmaken?
Niet blijvend, maar verkeerd ingestelde caching kan oude pagina’s tonen, de lay-out breken of de winkelwagen laten mislopen. Een kapotte lay-out komt vaak door minificatie of lazy loading, functies die cachingplugins er vaak bij doen. Leeg eerst de cache en draai daarna instellingen één voor één terug.
Heeft Surver caching ingebouwd?
Ja. Alle shared pakketten van Surver draaien op LiteSpeed-servers met LiteSpeed Cache, en OPcache staat standaard aan. Object caching met Redis biedt Surver op Surver Cloud.
