Websites, webshops, applicaties … eigenlijk zowat alles moet hedendaags als het kan binnen een halve seconde geladen en volledig vertoond worden (400ms is een streven wat veel tools hanteren). Er komt een heleboel kijken om dit voor elkaar te krijgen ‘onder de kap’ als het een wat complexer geheel betreft. Vaak wordt er dan ingezet op een cache oplossing.
Wat is cache?
Voordat ik inga op wanneer je nu eigenlijk wel en niet caching moet inzetten. Laten we eerst maar eens duidelijk maken wat caching nu daadwerkelijk is.
Caching ook wel cache, is een alternatieve vorm van gegevensopslag, die het opnieuw downloaden van dezelfde informatie of het opnieuw moeten uitvoeren van complexe berekeningen kan voorkomen.
Veel browsers werken van nature al met een eigen caching. Afbeeldingen, stylesheets en statische webpagina’s worden als tijdelijke internet-bestanden opgeslagen op het systeem van de gebruiker.
Dat is tot op het moment dat er wijzigingen optreden, tot dan hoeven deze bestanden niet opnieuw te worden opgevraagd van het internet.
Vormen van caching
Maar er is caching op allerlei verschillende vlakken mogelijk. Het gaat niet alleen om de browser. Denk bijvoorbeeld ook aan cache aan de server kant.
Binnen caching heb je allerlei verschillende vormen, om je een voorbeeld te geven;
- Client-Side Caching
- Browser Caching
- Server-Side Caching
- Database Caching
- Object Cachimg
- Opcode Caching
- Page Caching
- Content Delivery Network (CDN) Caching
En dan vergeet ik er vast nog wel een paar maar kortom er is ontzettend veel mogelijk met het oog op caching. Ik kies er daarnaast in dit item voor om expres niet te diep op iedere vorm in te gaan, dat zou anders echt te technisch worden.
Voordelen van cache
Iedere vorm van cache heeft zijn eigen vorm van voordeel. Maar in essentie komt het neer op het volgende voor alle vormen; Doordat informatie sneller beschikbaar is, vaak in de vorm waarin deze ook gebruikt wordt in de applicatie, wordt het programma sneller in gebruik.
Snelheid
Hoe sneller het te gebruiken is, hoe blijer de gebruiker, hoe beter de ervaring, hoe groter dat de kans is dat de gebruiker een bepaalde actie zal doorvoeren (conversie).
Dus denk bij cache vooral aan het winnen op gebied van snelheid. Onderschat daarbij niet hoe zwaar snelheid voortaan weegt bij gebruikers. Reageert een website niet binnen 2-3 seconden, dan is de ervaring slecht en je potentiële klant weg.
Iedereen heeft bijna wel gehoord van de studie van Amazon uit 2012 (https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales) waarbij ze tot de conclusie kwamen dat 1 seconde langer laden ze 1.6 miljard dollar aan omzet zou schelen.
Meer hedendaags
Amazon heeft daar een stuk recenter nog een gradatie aan toegevoegd. Want ook Amazon zit natuurlijk niet stil; maar iedere 100ms die Amazon langzamer laad scheelt ze 1% aan sales (https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/)
Kortom snelheid en caching zijn belangrijk als het om bereikbaarheid en omzet gaan.
Nadelen van cache
Zoals John Cruijff het zo passend kon zeggen;
Ieder voordeel heb z’n nadeel
En waar cache heel veel voordelen heeft, heeft ook een paar zaken die je kan zien als een nadeel.
Cache kan verwarrend zijn
Caching moet op een goede manier ingericht worden en daarmee bedoel ik dat ook het invalideren (het opschonen) van de cache op een goede manier moet gebeuren. Als je bijvoorbeeld een Wordpress website hebt en je voegt een nieuwe post toe of je update een post dan moet alles wat er gerelateerd is aan die post wellicht geleegd worden qua cache.
Afhankelijk van het platform wat je gebruikt is daar wel of niet al de nodige logica voor.
Maar caching is ook verwarrend omdat ook buiten de server en applicatie bestaat. Daarmee bedoel ik voornamelijk de client-side en browser caching. Vooral omdat deze in het afgelopen jaren een stuk hardnekkiger is geworden (je moet veel vaker dan vroeger je cache HARD leegmaken om het echt weg te krijgen)
Cache is voor developers … niet handig
Als developer weet ik maar al te goed dat het werken op een omgeving met cache best uitdagend kan zijn. Vooral als je scenario’s moet nagaan waarbij niet ingelogde gebruikers een cache geserveerd krijgen en (wellicht) als ingelogde gebruiker je dit niet krijgt.
Daarom is cache heel erg aan te raden als iets na uitvoerig testen en finalizen op een productie platform is terecht gekomen.
Echter is voor het door kunnen ontwikkelen aan een omgeving die op productie caching gebruikt het veel praktischer om een testing / staging / acceptatie omgeving te hebben waar cache geen factor is.
Want je wilt je developers ook niet gek maken van cache …
Is cache altijd een oplossing?
Maar moet je altijd een cache oplossing inzetten om problemen met bereikbaarheid / snelheid te ondervangen? Ik ben persoonlijk van mening dat dit niet het geval hoeft te zijn
Cache wordt vaak ook te pas en te onpas ingezet om een achterliggend probleem te ontzien. Ik noem dat doorgaans een ‘pleister-oplossing’. Daarmee bedoel ik dat je een pleister over de wond heen plakt maar niet de wond zelf hebt behandeld. Je lost dus in feite niet het achterliggende probleem op.
Ik ben van mening dat je eerst moet zorgen dat het thema, systeem, server etc. goed draait alvorens je naar de toevoeging van caching gaat grijpen. Alleen zo krijg je een echt optimaal / efficient werkend geheel.
Als je die andere aspecten eerst goed aanpakt, dan kan het zelfs zo zijn dat je geheel geen caching nodig hebt voor een goed en snel functionerend platform.
Vriend of vijand?
Dus vriend of vijand, cache is nuttig en in veel gevallen een welkom gegeven. Maar behandel het net als een vriend goed of het kan uiteindelijk een vijand worden.
Laat daarom de caching inrichten door experts die weten hoe goed met cache om te gaan.
Ik denk dat ik daar met het oog op mijn ervaring uit de hosting, support en ontwikkel sectoren best het nodige van weet. Per slot van rekening doe ik het nu nog steeds voor eigen grote projecten zoals NintendoReporters (https://www.nintendoreporters.com/).
