Toevoegen als voorkeursbron op Google
Wanneer het aankomt op web prestaties, dan is WordPress cache een van de dingen waarmee elke websitehouder hoe dan ook te maken krijgt. Wij houden van WordPress maar het is zeker niet het snelste platform, zeker wanneer je het vergelijkt met een compleet statische website. Wij zagen enorme verbeteringen met PHP 8.0 en 8.1 maar als je jouw website niet op de juiste manier cached dan wordt je website alsnog langzaam.
Zou het niet fijn zijn als je niet hoefde uit te zoeken welke cachingplugin de beste is? Nou, bij Kinsta regelen we caching voor je, zodat jij je kunt richten op het laten groeien van je bedrijf.
Wat is WordPress Cache?
Caching is het proces van het opslaan van resources bij 1 verzoek en ze daarna hergebruiken bij vervolgverzoeken. Simpel gezegd: het verminderd het benodigde werk dat nodig is om een pagina te genereren.
Waarom je gebruik zou moeten maken van caching? Caching maakt WordPress websites sneller en verminderd de last op webservers. Dit is waarom elke website ernaar zou moeten streven om zoveel als mogelijk te cachen. Nog een toevoeging, in geval van CDN caching verminderd het ook de bandbreedte die nodig is voor genereren van een pagina door het opslaan van statische resources op een andere host dan jouw WordPress host.
Geen WordPress Cache plugins nodig bij Kinsta
Precies! Host je je WordPress site bij Kinsta, dan hoef je niet te rommelen met ingewikkelde en verwarrende cachingplugins. We hebben namelijk al verschillende vormen van caching ingesteld. Je kunt eindelijk stoppen met googelen op “beste cachingplugins van 2026” en je tijd aan nuttigere dingen besteden.
Bij Kinsta maken wij gebruik van de volgende vier types van caching, welke allemaal automatisch op software of server niveau gebeuren.
Veel van onze klanten melden een enorme vermindering van de laadtijden door simpelweg te migreren naar Kinsta. Hieronder ziet u een voorbeeld van een site die 212,5% meer prestaties heeft laten zien. En dit is zonder caching plugin geïnstalleerd.
Er zijn ook andere factoren die meespelen bij het verminderen van de laadtijd maar caching is een groot deel ervan. We zeggen niet dat alle caching plugins slecht zijn, het is vaak zelfs zo dat ze niet goed werken door het foutief configureren van de gebruiker, waardoor hun WordPress website langzaam wordt. Heb je ooit geprobeerd de W3 Total Cache plugin te configureren? Die wordt heel snel heel verwarrend.
Geloof ons niet op ons woord
Wat prestaties betreft, geloof ons niet zomaar op ons woord maar lees een aantal van de onderstaande verklaringen van mensen die naar Kinsta zijn verhuisd. Geen van alle gebruikt nog caching plugins.
Bytecode Cache
Bytecodecache slaat gecompileerde PHP code op, zodat de compilatiestap de volgende keer kan worden overgeslagen. Bij Kinsta staat OPcache aan voor alle PHP releases vanaf 7.3.
Wanneer een PHP-bestand wordt verwerkt dan moet het eerst gecompileerd worden naar opcode die gelezen kan worden door de machine. Wat OPcache doet is deze omgezette code opslaan zodat PHP deze conversie stap kan overslaan de eerstvolgende keer dat dit bestand of script wordt opgevraagd. Door gebruik te maken van OPcache wordt de prestatie van PHP drastisch verbetert. Dit betekend tegelijkertijd ook dat wijzigingen in PHP-bestanden niet meteen zichtbaar zijn. Dit is de reden dat OPcache is uitgeschakeld op de Kinsta WordPress staging omgevingen.
Lees meer hoe OPcache PHP applicaties versnelt.
Object Cache
Object cache slaat de resultaten van database queries op zodat de eerstvolgende keer dat het specifieke stukje data nodig is het geleverd kan worden vanuit de cache zonder dat de database geraadpleegd hoeft te worden. Dit verkort de tijd waarin de PHP kan worden uitgevoerd en reduceert de belasting van jouw WordPress database.
WordPress heeft een ingebouwde object cache: WP_Object_Cache. Deze object cache slaat de objecten op voor een enkele pagina. Het doel is ervoor te zorgen dat de database niet meerdere keren op exact dezelfde manier geraadpleegd wordt voor een enkele pagina. Na die enkele pagina worden de opgeslagen objecten niet meer gebruikt. Ondanks dat dit een bruikbare feature is in WordPress is object caching een stuk krachtiger wanneer de objecten tussen meerdere pagina’s gebruikt worden.
Je kunt dit gedrag veranderen en de gecachede objecten hergebruiken voor meerdere pagina’s door over te stappen van de ingebouwde object cache naar een externe oplossing. Dit kan gedaan worden door een script te plaatsen in de /wp-content/ folder. Er zijn plugin gebaseerde object cache opties zoals W3 Total Cache.
Bij Kinsta kunnen klanten ook onze Redis add-on aanschaffen en installeren naast PHP 8.0 of 8.1. Redis is een open source, in-memory data-structuur opslag die gebruikt wordt als database, cache en berichten broker. Lees ons artikel hoe je gebruik maakt van Redis als een blijvende object cache als je hier meer te weten over wilt komen.
Pagina Cache
Pagina caching is het opslaan van de gehele HTML pagina zodat volgende pageviews kunnen worden gegenereerd zonder dat WordPress die pagina hoeft te genereren.
Wanneer je een WordPress website laad, dan verwerkt WordPress een groot aantal PHP bestanden en voert een aantal queries op de database uit. Voor pagina’s die niet constant worden geupdate is dit verspilde moeite. Het is veel efficiënter om de pagina een keer te genereren en dan op te slaan en te laten zien aan volgende bezoekers. Dit is wat pagina caching doet.
De voordelen van pagina caching zijn:
- Pagina’s laden veel sneller
- Enorme vermindering in belasting voor de server en daarmee ook de mogelijkheid om veel meer verkeer aan te kunnen
Onze servers gebruiken de nginx fastcgi cache module voor paginacache, met standaard een vervalmoment van 1 uur. Je kunt dat vervalmoment op elk moment aanpassen in MyKinsta. Ga naar de pagina Caching van je site, klik op het tabblad Servercaching en klik op de knop Vervalmoment wijzigen.
Kies in het venster Vervalmoment wijzigen de gewenste periode en klik op Vervalmoment wijzigen. Je kunt kiezen tussen één uur en één jaar. Voor sites die weinig veranderen kan een langer vervalmoment gunstig zijn voor de prestaties.
De paginacache is geconfigureerd om meteen te werken met standaard WordPress, WooCommerce en Easy Digital Download sites. Dit betekent dat pagina’s als het WordPress dashboard, WooCommerce shopping carts, en meer, automatisch worden overgeslagen van de paginacache. Als je een erg aangepaste WordPress setup hebt, dan is het mogelijk dat er de nodige wijzigingen moeten worden gedaan om te zorgen dat de paginacache werkt, en ons supportteam kan je hiermee helpen.
Net als Bytecode caching (OPcache) is pagina caching uitgeschakeld in de Kinsta staging omgevingen.
CDN Cache
CDN caching slaat websitebestanden (Javascript, CSS en media bestanden) op een content delivery netwerk op voor een snellere levering wanneer gebruikers zich geografisch ver van de host server bevinden. Wanneer iemand de website probeert te bereiken worden deze bestanden geleverd door het CDN in plaats van via de server die de website host. Lees hier meer waarom jij gebruik zou moeten maken van een CDN.
Een content delivery netwerk (CDN) bied 2 primaire voordelen:
- Het reduceert de server resources die nodig zijn om een website te laden. Het CDN doet het werk, de server hoeft dat dus niet te doen
- Het is hierdoor mogelijk dat resources afgeleverd worden vanaf locaties over heel de wereld, waardoor het sneller wordt voor gebruikers die geografisch gezien verder van de host server af zijn.
Er zijn 2 basis types CDN: de simpele CDNs en de CDNs die ook veiligheidsmaatregelen aanbieden. Een aantal voorbeelden hiervan zijn:
- Standard CDN: CloudFront.
- CDN plus security: Kinsta CDN (Cloudflare), Sucuri, Akamai (optionally).
Het eerste type CDN wordt ingesteld door CDN URL’s te maken die worden gebruikt om toegang te krijgen tot de bronnen op je website. De exacte manier waarop je dit in kan schakelen, verschilt per CDN. Het basisidee is dat URL’s voor statische resources worden gewijzigd naar die van de CDN URL, zodat de resources vanuit de CDN worden geladen. Een standaard CDN slaat meestal alleen statische bestanden op in de cache, zoals JS, CS en mediabestanden.
Het tweede type CDN dient als een volledige proxyserver. Dit betekent dat elk verzoek via de servers van de provider moet gaan voordat het bij de servers van Kinsta aankomt. Dit wordt mogelijk gemaakt door de naamservers van de CDN provider te gebruiken, zodat de CDN provider volledige controle heeft over de DNS van de website. Hierdoor kan de provider veel dingen doen die bij een eenvoudige CDN niet mogelijk zijn, zoals het filteren van verkeer van slechte IP’s, DoS/DDoS bescherming bieden of zelfs een volledige paginacache opslaan op de CDN. Onze Kinsta CDN wordt mogelijk gemaakt door Cloudflare, een proxy prestatie-/beveiligingsservice.
Advanced CDN Caching
Gebruik je een proxyserver-CDN zoals Cloudflare of Sucuri, dan kun je de volledige paginacache op het CDN opbouwen. Met een CDN als Cloudflare of Sucuri de volledige HTML cachen haalt al het werk bij onze servers weg, en dat is een uitstekende oplossing voor een site die een enorme piek in verkeer verwacht.
- Sucuri vereist dat er pagina regels zijn ingesteld om complete pagina caching te laten werken. Deze regels moeten gebruik maken van een “Cache alles” cache niveau.
- Cloudflare vereist dat paginaregels worden ingesteld om volledige paginacache te laten werken. De regels moeten een “Cache Everything” cacheniveau gebruiken.
Kinsta Cache Reactie Header
Je kunt testen om te zien of jouw pagina wordt geleverd vanuit de Kinsta cache door te kijken naar de http-response headers. Kinsta voegt een X-Kinsta-Cache header toe. Bij het eerste verzoek naar een pagina die niet gecached is zal het een MISS weergeven, zoals hieronder te zien is
Bij het tweede verzoek naar de volgende pagina zal de X-Kinsta-Cache header HIT weergeven. Dat betekend dat de pagina wordt geserveerd vanuit de cache.
Als je ons artikel over het scoren van 100/100 op Google PageSpeed Insights hebt gelezen dan weet je dat Kinsta ook nog extra optimalisaties heeft op server niveau om automatisch de onderstaande waarschuwingen op te lossen:
- Compressie inschakelen (bij Kinsta staat Brotli al aan via Cloudflare. Gzip is beschikbaar als terugvaloptie.)
- Server reactietijd verminderen (Kinsta is standaard al supersnel, ver binnen Google’s parameters zonder optimalisaties)
- Headers die verlopen (Die hoef je niet in te schakelen omdat Kinsta de caching van headers op server niveau regelt).
Onze test site scoort bijvoorbeeld een 100/100 op de PageSpeed Insight pagina zonder dat er een cache plugin ingeschakeld is. De caching van WordPress wordt allemaal geregeld door Kinsta op server-niveau.
Kinsta Cache instellingen
Je vraagt je nu misschien af, Hoe kan ik de cache beheren bij Kinsta? Uiteraard komen er momenten dat je de cache wil verwijderen, zeker wanneer je aan het debuggen bent. Je hebt bij Kinsta een aantal gemakkelijke opties. Je kunt de cache verwijderen vanaf het MyKinsta dashboard of je kunt gebruik maken van een Kinsta MU plugin.
WordPress Cache verwijderen
Je volledige paginacache handmatig legen doe je in MyKinsta. Selecteer je site, klik op Caching en dan op de knop Cache wissen onder Servercaching.
Alle knoppen op de pagina Caching zijn uitgeschakeld zolang de cache wordt gewist.
Standaard staat caching uitgeschakeld in de WordPress staging omgevingen van Kinsta. Als je deze paginacaching-functionaliteit wil testen op een staging site, dan kan je cache inschakelen in het MyKinsta dashboard door naar de tool “Site cache” te gaan. Nadat je caching hebt ingeschakeld voor een staging omgeving, kan je de knop “Cache wissen” gebruiken om de cache te wissen, net als in een live omgeving.
Kinsta MU Plugin
De tweede optie die je hebt is het gebruik maken van de Kinsta MU plugin. Wat? Ja, technisch gezien is dit een cache plugin, maar het is niet een typische cache plugin aangezien de caching nog steeds op server niveau geregeld wordt.
Standaard is de Kinsta MU plugin geïnstalleerd op alle websites die gehost worden door ons en zijn beschikbaar aan de linkerkant van jouw WordPress Admin dashboard. De plugin wordt gebruikt om de cache op een slimme manier te verwijderen. De plugin is vereist om ervoor te zorgen dat jouw website goed draait in onze omgeving. Ook moet je niet vergeten dat de pagina cache standaard elk uur verloopt.
Met de plugin kun je caches ook rechtstreeks vanaf je WordPress adminbalk legen.
De plugin maakt het ook mogelijk om aangepaste caching regels in te stellen. Afhankelijk hoe jouw website is geconfigureerd kunnen extra caching regels gewenst zijn. Je kan aangepaste paden aangeven om te verwijderen wanneer jouw website wordt geupdate.
U kunt ook contact opnemen met ons support team als u een bepaalde pagina of URL uit de cache wilt verwijderen.
Kinsta staging omgeving
In staging-omgevingen op Kinsta is paginacaching standaard uitgeschakeld. Dit het je gemakkelijker om je WordPress site te ontwikkelen en te debuggen zonder dat je de cache na elke bewerking handmatig hoeft te wissen. In sommige gevallen wil je paginacaching juist inschakelen om een nauwkeurige snelheidstest uit te voeren voor een gecachte pagina zonder je site live te pushen.
Wil je paginacache inschakelen op een testomgeving, ga dan in MyKinsta naar het cachemenu van je testomgeving en klik op de knop Inschakelen onder Servercaching. Zodra caching op de testomgeving aanstaat, kun je met de knop Cache wissen de cache legen.
Kinsta Cache Analytics
In MyKinsta Analytics krijg je een gedetailleerd beeld van hoe goed de caching op je WordPress-site werkt. Met de cache-component-stack kan je de status zien van elk verzoek, of dit nu HIT, BYPASS, MISS of EXPIRED was. Je kan gegevens filteren van de afgelopen 24 uur, 7 dagen of 30 dagen.
De grafiek met cachecomponenten laat je in één oogopslag je cacheratio zien. Hoe meer verzoeken je vanuit de cache serveert, hoe beter.
In het bovenste gedeelte van de cache-bypass kun je zien welke aanvragen niet vanuit het cachegeheugen worden geleverd. Meestal zijn dit CRON-jobs, admin-ajax-aanvragen, e-commerce checkout-pagina’s, query-strings, UTM-parameters, enzovoort.
404-pagina’s cachen
404-pagina’s kunnen erg drukken op de prestaties van je server, omdat ze erg resource-intensief zijn. Veel WordPress-sites generen meer 404-foutmeldingen dan je aanvankelijk zou denken en dit geldt helemaal voor grote membershipsites. Misschien heb je de locatie van een pagina gewijzigd en vergeten een redirect in te stellen of wellicht heb je per ongeluk een foutieve link geplaatst op social media. Een ongeluk zit in een klein hoekje en een 404-pagina is dus zo gemaakt. Wat ook niet meehelpt is dat deze pagina’s vaak gerelateerde zoekresultaten laten zien die uit je database moeten komen en voor verdere belasting zorgen.
Om te zorgen voor de beste prestaties van je WordPress-site, cachet Kinsta 404-pagina’s elke 15 minuten. De waarde van de header X-Kinsta-Cache laat HIT zien, wat betekent dat deze vanuit de cache wordt geleverd. Als je een pagina maakt die voorheen een 404 was, wordt de cache onmiddellijk verwijderd.
Onze MyKinsta-analyticstool kan je helpen om achter het exacte aantal 404-foutmeldingen van je site te komen.
We willen echter benadrukken dat we niet alle 404-verzoeken cachen. Er zijn twee verschillende soorten caching: eentje die komt van PHP-pagina’s die op je 404-pagina terechtkomen en die van ontbrekende bestanden of afbeeldingen die niet meer bestaan of zijn verplaatst. Wij cachen de 404-pagina’s, de 404-verzoeken voor ontbrekende bestanden en afbeeldingen volgen een ander proces.
Om die reden kan je de “Top 404-foutmeldingen” gebruiken om beter te bepalen waar ze voorkomen en wat ze veroorzaakt.
Je kan 404-foutmeldingen ook controleren in Google Search Console of een externe plugin installeren, zoals Redirection, die 404-foutmeldingen registreert. Vergeet echter niet dat deze plugins de prestaties van je site negatief beïnvloeden. Het is daarom beter om een tool te gebruiken die werkt op serverniveau.
Indien mogelijk, maak een eenvoudig 404-sjabloon aan die belasting van de database voorkomt.
POST verzoekt bypass van de cache
We willen dat onze analyse- en cachingstatistieken zo nauwkeurig mogelijk zijn. Dit is belangrijk, omdat je bij het oplossen van prestatieproblemen meestal kijkt naar de totale ratio van cache HIT, die je zo hoog mogelijk wilt houden. Daarom hebben we POST-verzoeken opgenomen in de rapportage.
POST-aanvragen kunnen niet in de cache worden opgeslagen, behalve bij zeer gespecialiseerde setups. De headerwaarde van X-Kinsta-Cache toont een BYPASS voor deze aanvragen. Deze moet niet worden verward met blogposts of een ander type WordPress-artikel (die wél te cachen zijn) Een POST-verzoek wordt gebruikt om gegevens naar de server te sturen. De gegevens die worden verzonden wanneer je bijvoorbeeld een webformulier verzendt, worden dus opgeslagen in de hoofdtekst van het HTTP-verzoek.
Samenvatting
Hopelijk begrijp je nu iets meer van WordPress cache en de 4 verschillende types die je regelmatig tegenkomt hier bij Kinsta: Bytecode caching, Object caching, Pagina caching en CDN caching.
Ben je het gerommel met de gebruikelijke WordPress caching plugins zat en wil je simpelweg een snelle site vanaf dag één? Probeer Kinsta dan eens! Er is een reden waarom ReviewSignal ons vijf jaar op rij de status “top tier” toekende voor WordPress prestaties. Onze servers zijn tot in detail afgestemd op een krachtig cloudplatform, voor bliksemsnelle laadtijden. Onze prestaties zullen je niet tegenvallen.
Brian heeft een enorme passie voor WordPress, gebruikt het al meer dan tien jaar en heeft zelfs al aantal premium plugins ontwikkeld. Brian houdt van bloggen, films en hikes. Kom in contact met Brian op Twitter.
