Een ‘Warm Cache’ gebruiken om je website te versnellen

Natuurlijk willen we allemaal onze website versnellen. En één methode om je website te versnellen is caching te gebruiken. In het verleden heb ik meer dan eens mogen ervaren hoe verraderlijk caching kan zijn. Want door een verkeerde caching plugin te gebruiken, of je caching plugin verkeerd te gebruiken, wordt je website al snel trager in plaats van sneller.

Warm cache: Je pagina wordt ‘voorbewerkt’.

De twee caching plugins voor WordPress die voor mij de beste resultaten bereikten, te weten Breeze en Cache Enabler (update: Cache Enabler is na de meest recente update weer op het oude niveau) hebben één groot nadeel. Het zijn ‘Cold Caching’ plugins. Ofwel, er wordt pas een gecachte versie van je pagina opgeslagen wanneer de pagina bezocht wordt. De eerste bezoeker van je pagina krijgt dus een ‘langzame versie’ te zien, iedere volgende bezoeker een snelle versie.

Maar pagina’s kunnen veranderen. En daarom kan je een caching plugin dusdanig instellen, dat bij het veranderen van die pagina de gecachte versie wordt gewist.

Dus de eerstvolgende bezoeker krijgt weer een langzame pagina. Maar een verandering in een pagina kan ook directe gevolgen hebben voor andere pagina’s.

Daarom hebben de meeste caching plugins de mogelijkheid om aan te geven, wat er moet gebeuren wanneer een pagina wordt toegevoegd of veranderd. Wil je dat alleen de cache van die ene pagina geleegd wordt, of wil je dat de complete pagina cache leeg wordt gegooid. Beide benaderingen hebben echter de eigen voor en nadelen.

Laat me je deze eens beschrijven.

De cache van de bewerkte pagina verwijderen

Stel, je hebt een bestaande blogpost gewijzigd en je slaat hem op. Eén van de wijzigingen is dat je er een aantal nieuwe tags aan hebt toegevoegd. Wanneer alleen de opgeslagen pagina uit de cache wordt verwijderd, dan zullen de tags netjes op de pagina voorkomen.

Klik je echter op die tag, dan zal die pagina niet voorkomen in de lijst van de blogpagina’s met die specifieke tag. Want die blogpagina is nog niet ververst.

Voeg je een compleet nieuwe blogpost toe, dan wordt het nog veel vervelender. De pagina met de blogpost zal onzichtbaar blijven, tot de cache wordt vernieuwd.

De complete cache verwijderen

Maar waarom zou je dan niet direct de complete cache verwijderen? Dan worden de pagina’s allemaal weer opnieuw aangemaakt.

Inderdaad. Maar dat aanmaken van die pagina’s zorgt er wel voor, dat de pagina’s initieel weer traag geladen zullen worden. Verander je vaak genoeg dingen aan je website -iets wat eigenlijk wel aan te bevelen is- dan doe je eigenlijk het hele effect van het cachen van je pagina’s teniet.

De expiration time

Om een tussenweg tussen beide ‘problemen’ te vinden heeft iedere cache een ‘expiration time’ voor de gecachte bestanden. Wanneer een pagina wordt opgevraagd kijkt een caching plugin eerst of er een gecachte pagina aanwezig is.

Is die pagina aanwezig, dan zal de plugin vervolgens controleren, wat de ‘expiration date time’ van die pagina is.

Stel, je hebt ingesteld, dat jouw paginas een expiration time van 24 uur hebben. Wanneer op 1 januari 2021 om 13:01 een pagina wordt aangemaakt, dan zal op 2 januari 2021 om 13:00.999 de expiration datum tijd verstrijken. En op 2 januari 2021 om 13:01 wordt de pagina opnieuw aangemaakt.

Dus éénmaal in de 24 uur heeft iemand de pech de trage pagina te krijgen.

Een prachtig idee natuurlijk. Maar wel met één belangrijke randvoorwaarde: Die pagina moet wel vaker dan éénmaal in de 24 uur worden opgevraagd. Anders heeft het cachen helemaal geen zin!

Een evenwicht vinden

Wanneer je een weinig bezochte site hebt, zal je dus het evenwicht moeten vinden tussen het aantal keren dat je pagina’s bezocht worden en hoe actueel je de inhoud wilt hebben.

Als je een veelbezochte site met een groot aantal pagina’s hebt, heb je eenzelfde probleem.

Want laten we eens naar de WordXPression site kijken. Ik heb op het moment van dit schrijven zo’n 600 blogposts. Van die 600 worden er zo’n 100 dagelijks tientallen malen bezocht, zo’n 200 worden dagelijks een aantal keren bezocht en de rest wordt af en toe eens bekeken.

Wanneer ik mijn cache een expiratie van 24 uur zou geven, dan zou voor de helft van de paginas (dus niet de helft van de bezoeken) caching zinloos zijn. Voor die blogposts die enkele malen per dag bezocht worden, zou de tijdswinst minimaal zijn.

Warm Cache

En dat is precies het probleem wat we met een ‘Warm Cache’ op gaan lossen. Want een ‘Warm Cache’ wil zeggen, dat er ‘automatisch’ voor gezorgd gaat worden, dat de cache wordt gevuld… en ook gevuld blijft.

In sommige caching plugins wordt de ‘warm cache’ ook wel ‘preloading’ genoemd.

Nu is het wel triest, dat de twee snelste caching plugins die ik heb kunnen vinden allebei niet beschikken over zo’n ‘warm cache’. Maar WordPress zou WordPress niet zijn als er niet voor (bijna) ieder probleem ook een oplossing bestaat. En die oplossing is een plugin die ook gewoon ‘Warm Cache‘ heet… en nog gratis is ook.

Probleem dus opgelost. Nou… nee, niet helemaal.

Het probleem met de ‘Warm Cache’ plugin

Die Warm Cache plugin heeft namelijk een paar kleine problemen… nou ja… kleine…

Het eerste probleem is dat de plugin standaard gewoon helemaal niets zal doen. Alleen wanneer iemand je site bezoekt, dan zal de plugin aan het werk gezet worden. Maar dat is een bekend probleem en jaren geleden heb ik er al over geschreven hoe je dit op kan lossen. Met een CRON job natuurlijk.

Geen cron jobs hier!

Maar daarmee introduceer je gelijk een nieuw probleem. Er zijn steeds meer hostingpartijen die ‘WordPress Managed hosting’ aanbieden. Jouw WordPress site komt dus op een server te staan die op alle manieren is voorbereid op alleen WordPress sites. Maar één van de dingen, die men wil voorkomen, is dat al die WordPress sites op zo’n server elkaar gaan lopen vertragen door de server te overbelasten met cron jobs… en dus zijn op dat soort platforms cron jobs verboden of aan banden gelegd.

Geen curl loopback

Een ander probleem is van een wat meer technische aard. Maar het is mogelijk om bestanden op afstand te ‘lezen en schrijven’ alsof het lokale bestanden zouden zijn. De technologie die hiervoor wordt gebruikt wordt ‘curl’ genoemd, naar het Unix commando wat hiervoor gebruikt wordt.

Wat de ‘Warm Cache’ plugin doet, is gebruik maken van die technologie om uit bestanden binnen de eigen omgeving te kunnen lezen. En dat is nu net iets, wat veel hosters om -voor mij overigens onduidelijke- veiligheidsredenen verbieden.

Time out!

En een derde serieus probleem is de grootte van het XML bestand. Ik heb zoals gezegd 600 blogposts, een 150 tal pagina’s en nog een groot aantal andere ‘virtuele paginas’ die gemaakt worden door op een tag of categorie te klikken. Mijn sitemap zoals ik die naar Google doorgeef heeft meer dan 4000 entries!

En ‘Warm Cache’ weigert dit te lezen in 20 seconden, te maximale tijd voor er een time out gegenereerd wordt. Standaard staat deze tijd trouwens op 5 seconden en je moet heel wat kunst en vliegwerk verrichten om dit op 20 seconden te zetten.

Dus genereerde ik met een tweede ‘XML Sitemap’ plugin een tweede sitemap, waar ik alleen de blogposts en de pagina’s opnam… om daarna met een nieuw probleem geconfronteerd te worden.

Out of memory!

Je kan een programma een sitemap in principe op twee manieren laten lezen. De -voor de programmeur- makkelijke en de -voor de programmeur- moeilijke manier.

En de programmeur van de Warm Cache plugin had voor de voor de programmeur makkelijke manier gekozen. Met als nadeel, dat de hele XML sitemap in het geheugen wordt geladen. En dat legt een vrij zwaar beslag op de resources van de server. Met als gevolg dat het proces soms wel , maar vaker ook soms niet wilde lopen.

Kortom, zelf liep ik niet warm voor de ‘Warm Cache’ plugin op de WordXPression website, hoewel ik deze op een aantal andere sites van mezelf en een groot aantal sites van klanten wel succesvol heb lopen. Maar voor een site van het formaat van WordXPression is het geen echte oplossing.

Zoekt… en gij zult vinden

De manier om het probleem op te lossen was mij duidelijk. Ik wist precies wat ik moest doen… de XML sitemap inlezen en daarna een proces de URL’s in die sitemap stuk voor stuk aan laten roepen.

Wanneer ik dit niet binnen WordPress maar als een compleet zelfstandig proces zou laten doen, zou ik bovendien weinig te maken hebben met de ‘out of memory’ problemen.

Bovendien, als een zichzelf respecterend programmeur zou ik natuurlijk voor de moeilijke manier kiezen. Waardoor ‘memory’ al helemaal geen issue zou zijn. Als ik er maar de tijd voor zou hebben.

En die tijd had ik niet. Maar geheel toevallig liep ik tegen een andere oplossing aan, die prima voor mij werkt! En die oplossing deel ik graag met jou.

Dus ben jij één van die mensen die mijn eerdere blogartikel over de ‘Warm Cache‘ plugin hebt gelezen, maar liep jij tegen één van bovenstaande problemen aan, dan heb ik goed nieuws voor je.

Optimus Cache Prime

Het klinkt een beetje als een ‘Transformer‘, maar het is feitelijk een heel eenvoudig programma wat je van je Windows of Linux commando regel uit kan voeren. Optimus Cache Prime kan je gratis downloaden en na het uitpakken uit het zip bestand zet je het bijvoorbeeld neer in de map c:\ocp.

Het volgende wat je moet weten is de naam van je sitemap. Die kan je meestal vinden in je favoriete SEO plugin. Wanneer je in je Windows commandoregel nu iets als het volgende in zou tikken :

c:\ocp\ocp https://mijnwebsite.tld/mysitemap.xml

dan zal OCP jouw sitemap downloaden, de inhoud lezen en url na url aanroepen om ervoor te zorgen, dat die pagina’s gecached zullen worden.

En nu met losse handjes!

Dat is natuurlijk leuk, maar wat je natuurlijk niet wilt is iedere keer een regel in moeten tikken, wanneer je jouw ‘warm cache’ ook warm wilt houden.

Gelukkig kan je dat ook automatiseren.

En in Windows doe je dat met de ‘Taakplanner’ app.

Je begint in de Windows zoekbalk ’taakplanner’ in te tikken en klik vervolgens op de icoon.

Daarna wordt de Windows Taakplanner opgestart. Een scherm wat er ongeveer als hieronder uit zal zien.

In de rechter kolom klik je op ‘Taak Maken’. Je krijgt nu een dialoog met een aantal tabs te zien. Laten we eerst naar de eerste tab kijken.

Wat hier belangrijk is om in te geven is dat deze taak uitgevoerd moet worden, ongeacht of de gebruiker wel of niet is aangemeld, en dat de taak met ‘de meeste bevoegdheden’ uitgevoerd moet worden.

Bovendien is het wel handig om ‘verborgen’ aan te klikken. In ‘Configureren voor’ geef je jouw versie van Windows aan. Waarschijnlijk ‘Windows 10’.

Je gaat nu naar de tweede tab ‘Triggers’. En daar klik je op ‘Nieuw’. Dan krijg je de volgende dialoog te zien:

Je zal deze taak waarschijnlijk een aantal malen per dag uit willen voeren. In de volgende sectie van dit artikel ga ik verder in op de planning. Wanneer je de taak ieder uur of korter uit wilt voeren, dan vink je ‘Taak herhalen elke…’ aan en kies je de juiste periode.

Wil je het over een langere periode herhalen, bijvoorbeeld iedere 6 uur, dan plan je meerdere taken in door op verschillende tijdstippen een taak te laten starten. Je kan voor één geplande actie meerdere taken opgeven.

Na het invoeren van de planning voor de taken gaan we de taakplanner vertellen wat hij moet doen.

Hier vullen we het programma en de parameters in. Let op dat je het volledige pad naar het uitvoerbare programma ingeeft, inclusief extensie. Dus wanneer je het in de folder ocp op de c:\ schijf hebt staan wordt het c:\ocp\ocp.exe

In het veld parameters vul je de volledige url naar je sitemap in. Dus iets als https://mijngeweldigewebsite.nl/mijnsupersitemap.xml

En na dit opgeslagen te hebben gaan we naar de laatste stap. We vertellen de taakmanager wat hij moet doen, wanneer hij de taak om wat voor reden dan ook niet uit kan voeren.

We klikken aan, dat we de taak zo snel mogelijk uit willen voeren, wanneer een geplande activering is gemist en -minstens net zo belangrijk- geven we aan dat ‘Als de taak al wordt uitgevoerd, geldt deze regel: Geen nieuw exemplaar starten’. Ofwel, mochten we om welke reden dan ook de taak nog niet hebben uitgevoerd, dan willen we niet, dat er twee taken naast elkaar gaan lopen.

Wanneer we dit allemaal hebben ingevuld, klikken we op OK, en voortaan worden de taken in de achtergrond voor ons uitgevoerd.

Hoe plan je de taken in?

Maar hoe vaak wil je jouw taak laten draaien? Dat is eigenlijk nog zo eenvoudig niet om te beslissen. Laten we er even vanuit gaan, dat we hem niet onnodig willen laten draaien.

Het eerste wat je zal moeten doen is uitzoeken hoe lang de taak onder normale omstandigheden zal duren. En dat is sterk afhankelijk van twee factoren.

Een berekening

Als eerste natuurlijk hoeveel urls er zijn om in de ‘warm cache’ te plaatsen. Een site met zo’n 10 pagina’s zal er minder lang over doen dan een site met 10.000 pagina’s.

Een tweede niet onbelangrijke factor is hoe lang er normaliter over gedaan wordt om een pagina te genereren. Dus zonder cache. Laten voor ons voorbeeld zeggen, dat de maker van de site is gaan cachen omdat een pagina er gemiddeld 4 seconden over deed, en dit voor hem niet acceptabel was.

En laten we voor het voorbeeld stellen, dat de site 1000 pagina’s heeft. Dus 1000 x 4 is 4000 seconden, oftewel 1 uur en 10 minuten.

Dit is echter hoe lang het zou duren als er totaal geen ‘overhead’ zou zijn, de realiteit is dat dit er wel is. Want voordat er een pagina wordt aangeboden vind er ook enige dialoog tussen de client (het OCP programma) en server (de website) plaats.

Je kan redelijkerwijs verwachten dat dit ongeveer de helft van de berekende tijd is. Dus de taak zal onder ideale omstandigheden 1 uur en 45 minuten duren. Zeg dus maar rustig 2 uur, omdat er geen ideale omstandigheden bestaan.

Hoe staat de cache zelf ingesteld?

Een tweede belangrijke factor is de tijd die je zelf voor caching hebt ingesteld. Wanneer ik mijn caching op 24 uur heb ingesteld, is het onzinnig om direct nadat het proces klaar is -in ons voorbeeld 2 uur- opnieuw te starten. Alles zal nog gecached zijn. Er wordt immers pas een nieuwe cache pagina aangemaakt nadat de expiry time is verlopen.

Je wilt dus de warm cache pas opnieuw gaan opbouwen, wanneer je redelijkerwijs mag verwachten dat het ook iets uitmaakt, kortom wanneer een pagina in de cache ‘verouderd’ zou zijn geworden.

Hoe vaak is het wenselijk?

Laten we eens kijken welke acties een gecachte pagina ‘verouderd’ maken.

• Het veranderen van iets in de content van de pagina.
• Het updaten of installeren van een plugin die invloed heeft op de presentatie van de pagina.
• Het veranderen van instellingen van je thema, of van de templates in Elementor Pro of een andere theme builder. De content is niet aangepast, maar de presentatie wel.
• Het toevoegen van commentaren door bezoekers.
• Het aanpassen van menu’s of widgets

Ok, genoeg factoren waardoor dit kan veranderen. Nu ligt een groot aantal van deze factoren helemaal bij onszelf. Want plugins updaten, instellingen veranderen van het theme, menu’s en widgets aanpassen… dat gebeurt als het goed is allemaal met mijn medeweten als beheerder.

Wanneer er commentaren geplaatst worden, daar heb ik minder invloed op. Dat kan dag en nacht gebeuren. Hoe relevant het is dat -behalve op de specifieke pagina met commentaar- die commentaren ook direct zichtbaar worden in bijvoorbeeld een widget ‘recente reacties’ kan ik wel bepalen.

Wanneer ik normaliter om 4 uur ’s nachts gemiddeld 2 bezoekers heb dan hoeft niet direct de hele cache opnieuw opgebouwd te worden.

Bovendien, wanneer je -zoals ik- WordPress zo hebt ingesteld dat alle commentaren handmatig moeten worden goedgekeurd, is het niet van belang wanneer een commentaar wordt geplaatst, maar wanneer het wordt goedgekeurd.

Kortom, wanneer ik ervoor zorg, dat op het moment dat ik normaliter stop met werken de cache voor de laatste keer van de dag opnieuw wordt aangemaakt en pas weer gaat lopen enkele uren nadat ik normaliter begin met werken, dan heb ik een aardig ‘gemiddelde’ te pakken.

Wanneer ik bovendien grote aanpassingen die ervoor zorgen dat de hele cache wordt geleegd (plugins updaten, thema instellingen wijzigen etc) pas doe op een moment dat ik normaal weinig bezoekers heb, dan maak ik zo optimaal mogelijk gebruik van mijn ‘warm cache’.

Nu is het alleen nog zaak een goed ‘evenwicht’ te vinden om te bepalen, hoe lang de expirytime moet zijn.

Enkele tijden…

In ons voorbeeld duurt het maken van de warm cache twee uur. Wanneer ik er nu vanuit ga, dat ik normaliter tussen 8 en 20 werk (dus niet van 8 tot 20, maar mijn werktijd is tussen die tijden), dan wil ik eigenlijk dat om 20 uur -nadat ik mogelijk grote aanpassingen heb gedaan- de warm cache opnieuw opgebouwd gaat worden. Het laatste bestand zal dan een expiry time van ongeveer 22 uur de volgende dag krijgen.

Dit laatste bestand zal dus mogelijk niet ververst worden bij de volgende cache run.

En daarom wil ik eigenlijk op het moment dat ik al aan de slag ben gegaan ook de cache verversen. Dus als ik om 8 uur begin wil ik dat enkele uren -laten we zeggen 2 uur- nadat ik aan de slag ben gegaan de warm cache opnieuw bijgewerkt wordt. Dus om 10 uur. Dan zal hij om 12 uur klaar zijn.

Ik wil dat mijn bezoekers zo min mogelijk te maken krijgen met cache bestanden die verlopen zijn. Wanneer ik dit op 24 uur zet, dan krijg ik de volgende situatie :

Om 20 uur wordt de cache opgebouwd. Deze zal rond 22 uur klaar zijn.

De eerste bestanden ‘verlopen’ dus om 20 uur de volgende dag. De job van de volgende ochtend heeft dus de eerste keer eigenlijk niets te doen.

Rond 20 uur wordt de cache opnieuw opgebouwd. Omdat het niet altijd even snel gaat, is het mogelijk dat het bestand van wat op dag 1 op 20:13 werd aangemaakt de volgende dag om 20:10 al bekeken wordt. De ‘expiry time’ is nog niet verstreken. Dus het bestand wordt niet opnieuw aangemaakt. Bij de run voor de volgende morgen dus wel.

Als een vuistregel kan je aanhouden, dat binnen jouw ‘expiry time’ minimaal twee runs moeten zijn om een nieuwe warm cache aan te maken.

Zou ik weinig of geen controle hebben over het vernieuwen van de content op de site, zou ik mijn expiry time op 2x de tijd zetten die er nodig is om de hele cache opnieuw te maken, met een kleine reserve voor eventuele uitloop. Ik zou waarschijnlijk dus 2 uur plus 30 minuten uitloop nemen, dat maal 2, dus een expirytime van 5 uur.

Warm Caching onder Linux

Zoals aangegeven, is het ook mogelijk om het OCP programma onder Linux te gebruiken. En dat is eigenlijk een stuk eenvoudiger dan al dat ingewikkelde gedoe voor Windows.

Daar zit bovendien nog een extra aardigheid aan. Want wanneer jij OCP op dezelfde server plaatst waar je website staat, dan worden die opdrachten om een warm cache te maken niet over het trage internet verstuurd, maar razendsnel in de machine zelf afgehandeld.

Toen ik eenmaal besloot om niet langer het Windows programma meer te gebruiken, maar OCP op mijn VPS installeerde, werd de tijd om een compleet nieuwe cache op te bouwen wel heel ernstig ingekort. In plaats van zo’n twee uur, is het programma nu nog geen tien minuten bezig.

Voorwaarde voor zo’n oplossing is wel, dat je site op een VPS staat waar jij ook ‘root’ rechten op hebt. Heb je dat niet, dan is een ‘warm cache op afstand’ het enige alternatief.

Nog een uitdaging… de sitemap

De warm cache van OCP werkt op basis van de XML sitemap. Nu is de sitemap ook een bestand wat wordt gecached door de meeste caching plugins.

Een nieuw toegevoegde pagina zal dus nog niet voorkomen in de gecachte sitemap. Ik heb daarom de gewoonte om na het toevoegen (of significant wijzigen) van een blogpost of pagina deze even ‘op te vragen’ in een incognito venster (niet ingelogd, wanneer ik ben ingelogd, wordt er geen pagina gecached) van mijn browser.

Hetzelfde doe ik met een gewijzigde pagina.

Het is beter dat ik de ‘vertraagde pagina’ te zien krijg, dan dat mijn bezoekers deze krijgen.

Warm Cache plugin en Optimus Cache Prime met elkaar vergeleken…

Wanneer ik de Warm Cache plugin vergelijk met Optimus Cache Prime, dan gaat mijn voorkeur toch eigenlijk heel sterk uit naar OCP. Hoewel de Warm Cache een prima plugin is, is deze slechts toepasbaar in een beperkt aantal situaties. Optimus Cache Prime is eigenlijk altijd inzetbaar. Tenminste wanneer je over een Windows of een Linux computer beschikt (sorry, Mac users!).

Denk er wel aan, dat het alleen werkt wanneer je computer aan staat en verbinding heeft met het internet. Staat jouw computer normaliter uit rond de tijden dat je de cache opnieuw aan zou willen maken, dan heb je wellicht nog wel ergens een oude desk- of laptop staan, die je hiervoor in kan zetten. OCP vergt heel weinig van je systeem. Een werkende internet verbinding en wat vrije schijfruimte is voldoende.

Ten slotte

Soms kom je op de WordXPression blog de meest verrassende artikelen tegen. Zoals dit artikel. Informatie waar je wellicht niet naar op zoek zou zijn gegaan, maar nu je het eenmaal weet wel heel waardevol voor je is.

Een goede manier om op de hoogte te blijven is te zorgen dat je geen informatie mist! En dat is eenvoudig. Door op de rode bel linksonder op deze pagina te klikken, en de instructies te volgen, kan je je inschrijven voor browser berichten. Is er een nieuw blogartikel, dan ontvang je hierover vanzelf bericht door een push bericht in je browser.