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 7 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 2019” 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.

WordPress Laadtijden Kinsta

WordPress Laadtijden Kinsta

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.

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.2, 7.3  en 7.4 (en zullen die blijven inschakelen voor nieuwere versies van PHP wanneer ze beschikbaar komen op ons platform).

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 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 7.2, 7.3 of 7.4. 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

Hier bij Kinsta gebruiken onze servers de nginx_fastcgi_cache_module voor pagina caching en het verloop ervan is standaard op 1 uur ingesteld. Klanten kunnen contact met ons opnemen indien ze deze verlooptijd willen verlengen. Voor sites die niet vaak veranderen, kan het in termen van prestaties nuttig zijn om een langere cache vervaldatum te hebben.

Pagina caching is zo geconfigureerd dat hij standaard werkt met WordPress, BuddyPress, WooCommerce en Easy Digital Download sites. Jij hoeft niets te doen! Simpelweg jouw WordPress website lanceren en pagina caching zal automatisch werken. Soms zijn er wel aanpassingen nodig mocht je gebruik maken van een aangepaste URL structuur of indien er gebruikt wordt gemaakt van een compleet andere WordPress setup.

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:

  • Standaard CDN: Kinsta CDN (KeyCDN), Stackpath, Cloudfront
  • CDN plus Security: Cloudflare, Sucuri, Akamai (Optionally)

De eerste type CDN is opgezet door het maken van CDN URLs welke gebruikt worden om de website resources te benaderen. De exacte manier varieert van CDN tot CDN. Het idee hierachter is dat de URLs voor statische resources veranderen in de CDN URL waardoor ze van de CDN afgehaald worden. Een standaard CDN cached typisch gezien alleen maar statische bestanden zoals JS, CSS en mediabestanden. Onze Kinsta CDN is een standaard CDN aangedreven door KeyCDN.

Het tweede type CDN is een complete proxyserver. Dit betekent dat elk verzoek naar de servers van de provider gaat voordat het verzoek aankomt bij Kinsta. Dit wordt ingeschakeld door gebruik te maken van de Nameservers van de CDN-provider, zodat de CDN-provider complete controle heeft over de DNS. Dit staat de provider toe om dingen te doen die een simpele CDN niet kan. Dit is bijvoorbeeld het filteren van slecht IP-adressen, DoS/DDoS bescherming bieden of complete pagina’s cachen op de CDN.

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. Door dit te doen verplaats je de complete server belasting van onze servers naar die van de CDN en dit is een perfecte oplossing als je plotselinge verkeerspieken 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 pagina regels om volledige pagina caching te laten werken. Deze regels moeten gebruik maken van een “Cache alles” cache niveau.

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

Miss cache header

Miss cache header

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.

Hit cache header

Hit cache header

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.

pagespeed insights

PageSpeed Insights

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.

Downtime en WordPress problemen? Kinsta is de hosting oplossing speciaal ontworpen om jou tijd te besparen! Bekijk onze kenmerken
Leeg WordPress cache

Leeg WordPress cache

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.

Kinsta MU plugin

Kinsta MU plugin

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.

Leeg de wordpress cache vanaf de admin bar

Leeg de wordpress cache vanaf de admin bar

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 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.

Kinsta cache-component-stack

Kinsta cache-component-stack

Met de cache-componentdiagram kan je snel je caching-ratio inzien. Hoe meer verzoeken je vanuit de cache kan leveren, des te beter.

Kinsta cache-componentdiagram

Kinsta cache-componentdiagram

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.

WordPress top cache-bypass

WordPress top cache-bypass

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.

Analyse 404-foutmeldingen

Analyse 404-foutmeldingen

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.

404-pagina uit cache

404-pagina uit cache

Je kan 404-foutmeldingen ook controleren in Google Search Console of een externe plug-in installeren, zoals Redirection, die 404-foutmeldingen registreert. Vergeet echter niet dat deze plug-ins 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.

3.1K
keer gedeeld