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 jij geen zorgen hoeft te maken over welke caching plugin je het beste kunt gebruiken? Wij bij Kinsta zorgen voor jou voor de caching. Jij kunt je dus focussen op het uitbreiden van je onderneming.
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
Dat lees je goed! Wanneer je jouw WordPress website host bij Kinsta hoef je geen zorgen te maken over ingewikkelde of verwarrende caching plugins. Dat is omdat wij al verschillende caching types hebben geimplementeerd. Je kunt dus stoppen met googlen voor de “beste caching plugin van 2024” en je focussen op productievere taken.
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.
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
@TheSportReview's new @Googlecloud based @kinsta environment handled the post-match @ManUtd v @ChelseaFC traffic spike in style 👌⚽ pic.twitter.com/kJewykSqaV
— Martin Caparrotta (@MartinCap) April 16, 2017
60%+ drop in @pingdom load times for @voompla after move to @kinsta + @CloudFlare CDN + site optimization! support by @tomzur @MarkGavalda
— Palash Bakshi (@ppbakshi) September 11, 2016
Laten we nu eens kijken naar alle types van WordPress caching die je op reguliere basis tegen kunt komen hier bij Kinsta. Begrijpen wat elke laag caching doet helpt jou om problemen met caching op te lossen en zorgt ervoor dat jouw website als een zonnetje loopt.
Bytecode Cache
Bytecode Cache slaat gecompileerde PHP-code op zodat het de volgende verzoek het compileren kan overslaan. Bij Kinsta hebben we OPcache ingeschakeld voor PHP 7.3 en 7.4 (en zullen die blijven inschakelen voor nieuwere versies van PHP wanneer ze beschikbaar komen op ons platform).
Update: PHP 8.1 (officiële release) is nu beschikbaar voor alle Kinsta klanten. PHP 7.4 wordt niet meer ondersteund door Kinsta. Wij ondersteunen PHP versies 8.1, 8.2 en 8.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 paginacaching, waarbij het verlopen ervan is ingesteld op elk uur. Klanten kunnen echter zelf het verlopen van de paginacache op elk moment wijzigen in het MyKinsta dashboard. Om de vervaltijd van je paginacache te wijzigen, ga je naar de “Tools” pagina van je site, klik je op de dropdown “Bewerken” onder “Sitecache” en vervolgens op “Verander de vervaldatum van de cache“.
In het scherm dat nu verschijnt in selecteer je de vervaltijd die je wil en klik je op Verander de vervaldatum. We bieden opties van 1 uur tot 7 dagen. Voor sites die niet vaak veranderen, kan het qua prestaties gunstig zijn als de cache een langere tijd heeft. Vervalopties voor paginacache in MyKinsta.
De paginacache is geconfigureerd om meteen te werken met standaard WordPress, BuddyPress, WooCommerce en Easy Digital Download sites. Dit betekent dat pagina’s als het WordPress dashboard, WooCommerce shopping carts, BuddyPress forums voor ingelogde gebruikers 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: Stackpath, 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
Als je gebruik maakt van een proxy server CDN zoals Cloudflare of Sucuri dan heb je de mogelijkheid om volledige pagina’s te cachen op de CDN. Het gebruik van een CDN als Cloudflare of Sucuri om HTML van volledige pagina’s te cachen ontlast al het werk van onze servers en is een uitstekende oplossing voor een site die een enorme toename van het 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:
- Schakel compressie in (Kinsta heeft standaard Gzip ingeschakeld op alle servers, jij hoeft niets te doen).
- 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
Om handmatig jouw complete pagina cache te legen dan kun je dit doen vanuit het MyKinsta dashboard. Navigeer naar jouw website, klik op tools en klik daarna op de “Verwijder Cache” knop.
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.
De plugin maakt het ook mogelijk om de cache te verwijderen vanuit de WordPress admin bar. Dit is waarschijnlijk een van de grootste redenen om de plugin te gebruiken aangezien je niet hoeft te navigeren naar het MyKinsta dashboard. Je kunt het gewoon vanaf jouw website regelen.
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.
Om paginacaching in een testomgeving in te schakelen, navigeer je naar Sites > Tools in MyKinsta en klik je op de knop “Cache inschakelen”. Als caching is ingeschakeld binnen je staging-omgeving, kan je de knop “Cache wissen” gebruiken om de cache te 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.
Met de cache-componentdiagram kan je snel je caching-ratio inzien. Hoe meer verzoeken je vanuit de cache kan leveren, des te 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 zat om met die standaard WordPress caching plugins te rommelen en wil je gewoon een snelle website vanaf het begin, dan raden wij aan het eens te proberen bij Kinsta! Er is een reden waarom wij de “Topniveau” status in WordPress prestaties 4 jaar op rij hebben gekregen van ReviewSignal. Dat is omdat onze servers zijn geconfigureerd boven op het Google Cloud Platform voor supersnelle laadtijden. Je zult niet teleurgesteld worden door onze prestaties.
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.
Laat een reactie achter