Betere performance voor je WP site met cache warming

Betere performance voor je WordPress Website

In mijn diverse blogposts over WordPress en de performance, heb ik meer dan eens aangegeven, dat je voor een betere performance voor je WordPress website niet ontkomt aan caching, het opslaan van de door WordPress gegenereerde pagina’s. Over het hoe en waarom verwijs ik je graag naar één van de vele andere artikelen in mijn blog over caching.

Het nadeel van caching is echter, dat je pagina’s pas worden versneld nadat ze een keer door een bezoeker zijn bezocht. De eerste bezoeker aan een pagina na het verlopen van een cache zal dus altijd een ‘langzame’ versie van die pagina krijgen. Dat wil je natuurlijk voorkomen.

Daarom heeft een groot aantal caching plugins voor WordPress een functie die ze ‘preloading’ of ‘cache warming’ noemen.

En voor de plugins die niet over een dergelijke functie beschikken, zijn er speciale ‘cache warming‘ plugins beschikbaar.

Wat doet zo’n cache warmer? In de ‘verloren tijd’, waarop de website bijna niets te doen heeft, zorgt een ‘WP Cron‘ job ervoor, dat een aantal verlopen pagina’s automatisch opnieuw zullen worden gegenereerd. Dat is aan de ene kant gunstig, maar aan de andere kant, kleeft hier ook een groot nadeel aan. Jouw server wordt extra aan het werk gezet. Wat op zich ook weer een negatieve invloed op de cache heeft.

Externe programma’s voor cache warming

Het is ook mogelijk om een betere performance voor je website te krijgen door gebruik te maken van ‘externe manieren’ om de cache van je website ‘op te warmen’.

Er zijn in principe drie mogelijke methoden beschikbaar. Want wanneer wordt een website cache ‘opgewarmd’? Wanneer de pagina van een site -met caching- wordt bezocht. Van de mogelijkheden die er zijn ken ik er twee -of eigenlijk drie- die ik graag met je wil bespreken.

HTTrack Website Copier

De eerste manier is een ‘webspider’. Een programma dat jouw website bezoekt en binnen die website iedere link volgt, die in de pagina’s voorkomt. Een programma wat je hiervoor kunt gebruiken is HTTrack Website Copier‘. Dit is een programma wat letterlijk iedere link die voorkomt in de homepage van een website volgt en opslaat. Hierbij kan je de te volgen links beperken tot -bijvoorbeeld- alleen de links binnen hetzelfde domein.

Zelf gebruik ik dit programma wanneer een klant die een ‘niet WordPress website’ heeft mij vraagt een nieuwe website te bouwen. Om een vergelijk tussen de oude en de nieuwe website te kunnen maken zelfs wanneer de website offline is omdat deze door een nieuwe is vervangen maak ik dan vaak een kopie met behulp van dit programma.

Omdat dit programma -wat overigens voor Windows, MacOS en Linux beschikbaar is- ook automatisch periodiek opgestart kan worden, is dit ook goed geschikt om een cache ‘op te warmen’. Hier zijn echter een aantal dingen van groot belang om rekening mee te houden:

• De andere cache warmers die ik hier bespreek doen dit door alleen te vragen om de content van een pagina, zonder deze te downloaden. Dus relatief weinig verkeer. Deze plugin zal alle pagina’s downloaden, dus ‘meer verkeer’.
• Vergeet niet om ‘bijlage bestanden’ (PDF, webp, jpg, png, mp3, mp4 en meer) uit te sluiten van de downloads. Voor de cache warming dragen ze niets bij, maar wanneer je dit vergeet, zullen ze het leeuwendeel van je download uitmaken.

Optimus Cache Prime

Zelf heb ik tot voor kort Optimus Cache Prime (OCP) jarenlang met veel plezier gebruikt. De nadelen zijn dat het installeren voor ‘automatische cache warming’ behoorlijk complex is en -nog veel vervelender- steeds meer hosting partijen de snelheid waarmee vanuit één IP adres de requests worden verstuurd niet meer accepteren.

Wat OCP doet is eigenlijk heel eenvoudig. OCP vraagt de XML Sitemap van je website op en volgt vervolgens iedere url die voorkomt in je sitemap. Dit geeft een aantal voordelen ten opzichte van een webspider. Een webspider zal iedere link volgen, OCP zal alleen de links volgen die voorkomen in je XML Sitemap. Dus je hebt meer controle over wat er wel en niet gevolgd zal worden.

Een tweede voordeel is, dat OCP alleen om de header informatie zal vragen. Dus de tekst in de (onzichtbare) header van de pagina. Maar omdat WordPress om deze header te produceren het hele paginascript zal moeten doorlopen zal wel de hele pagina opnieuw worden gegenereerd, maar niet gedownload.

Dat scheelt dus in de download tijd en het verkeer.

Het derde voordeel is mogelijk ook een nadeel. Omdat OCP geen pagina’s hoeft te analyseren, alle URL’s zijn in de sitemap aanwezig, is OCP ook veel sneller. En steeds meer hosting partijen zijn eigenlijk helemaal niet zo blij met al dat kunstmatige verkeer. Wanneer van eenzelfde IP meerdere request binnen een korte tijd aankomen, dan zal het verkeer van deze site (tijdelijk) geblokkeerd worden.

Gelukkig is er een derde alternatief.

Een ‘cache warming service’ gebruiken

Natuurlijk willen we allemaal een betere performance voor onze website. En dat is ons heel wat waard. Want betere performance wil ook zeggen, een betere positionering in de resultaten van zoekmachines en als een afgeleid resultaat… meer omzet.

Een goede manier om je cache warm te houden is dus best een paar centen waard, nietwaar?

Eén manier om dit te doen is door gebruik te maken van ‘cache warming services’. Dat zijn in principe sites die exact doen, wat in één van de twee eerdere opties is beschreven, maar met één gigantisch verschil. Een goede cache warming service doet dit niet vanuit één IP adres maar vanuit meerdere. Hierdoor zal je hoster dit niet zo snel als ‘ongewenst verkeer’ beschouwen. Een tweede voordeel is, dat ze geen gebruik maken van jouw resources. Je site wordt er dus niet extra door vertraagd.

De laatste paar maanden heb ik een drietal ‘cache warming services’ met elkaar vergeleken en voor mij is er één toch helemaal als beste uit de bus gekomen. Dit op grond van drie simpele kenmerken:

• Prijsstelling
• Gebruiksgemak
• Integratiemogelijkheden

En de winnaar is… cache-warmer.com.

Wanneer je deze site uit wilt proberen, dan hebben ze een 7 dagen trial waarin je maximaal 10.000 pagina’s kunt cachen voor je ter beschikking. En wanneer je besluit dit voor je site te willen gebruiken, ben je slechts 10 euro per maand kwijt voor het meest ‘lichte’ programma, wat je toestaat 50.000 pagina’s per maand te downloaden.

De tweede optie in de lijst kwam uit op 50 dollar per maand voor 100.000 pagina’s per maand. Maar aangezien ik geloof, dat weinig lezers van mijn blog 100.000 pagina’s per maand nodig hebben, is het niet de moeite waard deze te bespreken. Bovendien, in het onwaarschijnlijke geval, dat je toch meer dan 50.000 pagina’s per maand nodig hebt, het tweede niveau bij Cache Warmer kost 40 euro per maand voor 200.000 pagina’s.

Ook de configuratie is kinderlijk eenvoudig.

Je hebt de keuze tussen het gebruik maken van een webspider, of de XML Sitemap. Wanneer je een XML sitemap hebt, heeft dit sterk de voorkeur.

Daarna kan je een schema opstellen met betrekking tot de frequentie van het ‘opwarmen van je cache’. Om hier een goede keuze in ter maken verwijs ik je graag naar de volgende paragraaf.

En tenslotte kan je naast de ‘opwarmers’ volgens schema zo vaak als je wilt het proces met de hand opstarten.

Dat is eigenlijk alles. Simpel toch?

Tips om te werken met cache-warmer.com

Met de Cache Warmer site betaal je dus in principe per ‘opgewarmde’ pagina. Om de kosten binnen de perken te houden is het dus van belang, dat je ook nadenkt over hoe vaak deze cache warming echt nodig is. Dat kan per site verschillen.

Heb je een blogsite zonder noemenswaardig commentaar, of een site met slechts enkele pagina’s en sta je helemaal geen commentaar toe, dan is het de vraag of je zelfs een cache warmer wilt gebruiken. Waarom bezoek je niet zelf even alle pagina’s nadat de cache niet meer geldig is.

In welke situaties is een ‘cache pagina’ niet meer up to date?

De eerste situatie waarin een pagina niet meer ‘up to date’ is, is natuurlijk de meest voor de hand liggende. De pagina is zelf veranderd. Deze verandering kan echter een aantal oorzaken hebben.

• Jij hebt de pagina op de één of andere manier aangepast.
• De pagina is aangepast door het toevoegen van een commentaar door een gebruiker. Bij sommige plugins zal direct na goedkeuring van een commentaar -automatisch of door een moderator- de cache van die pagina ‘ongeldig’ gemaakt worden. De pagina zal dus opnieuw ‘opgewarmd’ moeten worden. Andere caching plugins zullen de gecachte pagina ongemoeid laten. In dat geval zal het commentaar pas zichtbaar worden na het verlopen van de cache voor die pagina.
• In een webshop is de voorraad aangepast door een aankoop (voorraad verlaagd), het verlopen van de timeout voor een winkelwagen (bij het plaatsen in de winkelwagen werd de voorraad verlaagd, bij het verlopen opnieuw verhoogd) of bij het aanpassen van de voorraad, omdat er nieuwe voorraad bij is gekomen. De cache plugins die ik ken reageren hier niet op. Je krijgt dus altijd een outdated voorraad te zien.
• Door een widget die andere informatie toont. Bijvoorbeeld, je hebt op de pagina een widget met de laatste blogposts, of de meest recente commentaren. Door een nieuwe blogpost toe te voegen, zal deze widget niet automatisch worden geupdate, aan de pagina zelf is immers niets veranderd. De informatie zal dus ‘de oude informatie’ blijven tot er daadwerkelijk iets is veranderd aan de pagina zelf.

Een tweede situatie is wanneer je iets aan de templates van je site hebt aangepast. Wanneer je een template builder als Elementor, Beaver Builder of Thrive gebruikt, en je hebt iets aangepast aan een post-template (of hoe het ook in jouw theme builder wordt genoemd) dan zullen de aanpassingen voor jou als ingelogde gebruiker wel direct zichtbaar zijn, maar niet voor de niet-ingelogde gebruikers, die zien nog de gecachte pagina’s. Is het een grote of een dringende verandering, dan kan het goed zijn om de cache handmatig te invalideren. De meeste cache plugins hebben ergens een ‘Delete cache’ of ‘Wis cache’ knop.

Een derde situatie is wanneer de plugins of hun instellingen zijn bijgewerkt. Wanneer je instellingen van een plugin hebt aangepast of de plugins -handmatig of automatisch- zijn geupdate dan kan het zijn dat door de aanpassing de pagina’s er ineens heel anders uit zouden gaan zien. In de meeste caching plugins is er een instelling, waarin je aan kunt geven dat de cache leeggemaakt moet worden, nadat plugins of hun instellingen zijn bijgewerkt. Het is verstandig om dit ook daadwerkelijk te doen, want met sommige plugins kan het leiden tot een complete chaos aan de voorkant van je website, wanneer je dit niet doet (bijvoorbeeld omdat CSS bestanden zijn aangepast, hernoemd of verplaatst in laad volgorde)

Enkele scenarios

In het geval van een grotere site komt de vraag hoe vaak de site daadwerkelijk geupdate dient te worden. Hier is een aantal scenarios in denkbaar

1. Je hebt een site zoals WordXPression. Een site met een groot aantal blogposts, relatief weinig commentaar. Je ‘knutselt’ regelmatig aan je site om zaken te optimaliseren en je plaatst periodiek een blog.
   In dit geval ‘weet’ je wanneer er iets aan je site veranderd, en welke pagina’s dat zijn. Natuurlijk wil je na het aanpassen van een pagina deze even bekijken. Nu zullen de meeste WordPress caching plugins geen nieuwe pagina in de cache aanmaken, wanneer je bent ingelogd. Maar wanneer je de pagina even in een ‘Incognito’ venster bekijkt (of wat de naam ook in jouw browser is) zal er wel een nieuwe pagina in de cache worden aangemaakt.
   Bij aanpassingen aan de instellingen van plugins of aanpassingen aan de templates, maak je de cache leeg, en start je de cache-warmer. Voor de rest zet je de ‘verlooptijd’ op 168 uur (zeven dagen) en start je éénmaal per week de cache-warmer automatisch.
   Af en toe zal er een pagina tussendoor slippen, maar die wordt bij het eerste bezoek gecachet.
2. Je hebt een forum met regelmatige bijdragen van leden van het forum.
   Omdat een cache alleen werkt wanneer gebruikers niet zijn ingelogd, en het idee van een forum juist is, dat ze wel moeten zijn ingelogd, zal caching alleen werken, indien het aantal passieve bezoekers -de mensen die alleen het forum lezen- veel groter is dan het aantal actieve bezoekers -de mensen die in het forum schrijven. Stel de tijdsduur van de cache in op de gemiddelde tijd tussen twee nieuwe posts. Post er gemiddeld ieder uur iemand iets nieuws, stel de tijd in op 1 uur, gemiddeld dagelijks een nieuwe post, 24 uur etc. Cache warming is in deze situatie niet actief in te zetten.
3. Je hebt een webshop. Hierbij is een bepalende factor of je wel of geen voorraadbeheer actief hebt en of er bij geen voorraad wel of geen bestellingen kunnen worden geplaatst. Heb je geen voorraadbeheer, of heb je korte voorraad-routes waardoor ook bij gebrek aan voorraad snel geleverd kan worden, dan kan je gebruik maken van de strategie zoals onder punt 1. genoemd. Ben je afhankelijk van een voorraadbeheer waarbij bij ‘geen voorraad’ ook geen bestellingen mogen worden geplaats, of aangegeven moet worden, dat er een langere levertermijn is, heb je twee mogelijkheden.
   De ene mogelijkheid is om bij iedere voorraad update van het product de cache te invalideren. De tweede mogelijkheid is om de informatie over de prijs via de WooCommerce rest interface en JavaScript op te halen.
   Die tweede methode, die qua performance de betere is, ga ik niet verder op in, omdat bij variabele producten de code extreem complex wordt.
   Voor de eerste methode vind je een code snippet in de snippet base. Let op: Deze code is getest op WooCommerce 9+ en PHP 8+, ik geef geen enkele garantie dat het werkt op oudere versies.

Wat neem je wel of niet op in je sitemap?

Cache warmer werkt met projecten. Bij de trial- en voordeligste versie heb je één project en mijn intentie is om binnen dit éne project (10 euro per maand ex BTW) te blijven. Binnen het project configureer je de manier waarop je gegevens op wilt halen.

Cache warmer werkt op drie manieren. Je kan Cache warmer als een ‘Spider’ laten werken, waarbij hij je site ‘doorloopt’ en alle links binnen het domein volgt. Je kan gebruik maken van je Sitemap XML of je kan een CSV bestand uploaden met de URL’s die je wilt cachen.

Zelf vind ik de XML Sitemap de handigste optie, maar dan wel op de ‘meest voordelige manier’. Tenslotte met een betaald account mag ik 50.000 pagina’s per maand ‘opwarmen’. Wanneer je bedenkt dat ik ongeveer 800 blogposts heb en een 80 tal pagina’s, is dat 880 pagina’s per ‘opwarming’. Maar neem ik alle tag en categorie pagina’s ook mee, dan kom ik al snel aan 2000 pagina’s per opwarming. Zou ik dagelijks de cache willen laten verversen, houd ik aan het einde van de pagina’s nog een stukje maand over.

Voor een betere performance van de site hoef ik overigens de site helemaal niet ‘dagelijks op te warmen’, maar het aantal url’s in de sitemap verminderen is altijd het overwegen waard. Dus ik ging eens kijken hoe vaak nu eigenlijk ’tags’ en ‘categorieën’ als Google zoekresultaat worden geklikt (de reden waarom ze voorkomen in de sitemap) en hoe vaak mensen sowieso tags of categorieën binnen de site zelf klikken (een goede reden om ze ‘op te warmen’).

Ik merkte dat in mijn geval ’tags’ in de sitemap geen noemenswaardige rol speelden, maar wel voor 500 extra pagina’s zorgden. Categorieën daarentegen worden wel vaak geklikt. Dus ik heb de tags uit de sitemap verwijderd. Voor je eigen site zal je zelf het onderzoek moeten doen, maar je kan dus heel wat ‘paginas’ besparen, wanneer je weinig geklikte taxonomieën uit de sitemap haalt.

Hoe vaak warm je de cache op?

Om de frequentie van je ‘opwarmen’ te bepalen, is het goed om nog eens te begrijpen hoe de cache werkt. Wanneer een pagina wordt aangeroepen, en de cache is verlopen, wordt hij opnieuw aangemaakt. Is de cache nog niet verlopen, wordt de pagina vanuit de cache gepresenteerd. Het is belangrijk te realiseren. Wanneer jouw cache warmer ook start, er bestaat dus altijd een kans, dat een pagina ‘nog niet opgewarmd’ is, en je bezoeker toch een ‘langzame’ pagina krijgt voorgeschoteld. Daar is verder niets aan te doen.

De ‘Schedule’ optie voor de geautomatiseerde job biedt je vier opties: Dagelijks, iedere werkdag, wekelijks of ‘Custom’.

Met de ‘Custom optie’ kan je in ‘crontab formaat‘ opgeven wanneer en hoe vaak de cache warming gestart moet worden. Hoe dit werkt, gaat buiten de scope van deze blogpost.

Zelf heb ik op dit moment de ‘cache warming’ op iedere zondag gezet. Zondag, omdat het site bezoek dan het laagst is. En wekelijks, omdat dagelijks net iets te vaak is. Dan heeft een maand net iets meer dagen dan ik pagina’s kan ‘opwarmen’.

We gaan het verder automatiseren

De rest van dit artikel is voor de echte ‘knutselaars’, the WordPress PowerUsers die het niet erg vinden om af en toe ook eens een code snippet te schrijven.

Want de Cache warmer site biedt ook de mogelijkheid om via een unieke url een cache warming job op te starten. Zo’n url ziet er ongeveer als volgt uit:

https://app.cache-warmer.com/webhook/cachewarmer/1234/AbC_dEfgHoJklMno_loRGXc_8ThFvjVVWIkSAt28

Door deze URL naar de Cache Warmer site te versturen, zal een job gestart worden om jouw site ‘op te warmen’. Maar waar heb je dat voor nodig?

Eén van de mogelijke situaties waarbij je dit zou willen is bij een update van je plugins, een upgrade van WordPress of een update van je thema. Dat zijn vaak situaties waarbij je cache leeg wordt gegooid door je caching plugin.

En -afhankelijk van je instellingen- zaken die zomaar automatisch kunnen gebeuren, indien je dat hebt ingesteld, of betaalt voor een dienst die dat voor je doet.

In de code snippets vind je daarom een code snippet die dat allemaal voor je gaat doen. Plus een bespreking in detail.

Tenslotte

Wanneer je een wat grotere site hebt, en jouw caching plugin geen ‘preloading’ of ‘cache warming’ ondersteunt, is de Cache Warming service een voordelig alternatief om een betere performance voor je website te krijgen. En met een paar tweaks die je in de snippet base vindt, kan je hem ook nog eens helemaal naar je hand zetten.

Voel je jezelf wat onzeker met het zelf invoeren van code in je website? Dan is de WordXPression Support Strippenkaart wellicht het antwoord voor je.