Voor een perfect presterende website is de cache je grote vriend. Die zorgt er namelijk voor dat je site razendsnel laadt en dat heeft weer zeer positieve effecten op de gebruikservaring.

De cache is een tijdelijk geheugen dat de laadtijd van je website kan verkleinen.  De werking lijkt een beetje op ons eigen geheugen. Als je je iets probeert te herinneren van lang geleden duurt het even voordat je alles weer precies weet. Wanneer je vervolgens kort daarna weer aan die gebeurtenis denkt, kun je je alles veel sneller voor de geest halen: simpelweg omdat je er al een keer aan gedacht hebt.

Zo'n snellere laadtijd is online erg belangrijk. Een te trage laadtijd van een website is vaak een belangrijke reden voor bezoekers om af te haken. Die zorgt zelfs voor een fysieke reactie: neurologisch onderzoek laat zien dat bij een laadtijd van meer dan 2 seconden het stressniveau en de frustratie toenemen.

Er zijn veel verschillende soorten caches waar websitebouwers dankbaar gebruik van maken. In deze blog focus ik me op de webcache en de applicatiecache.

De Webcache

Met webcaching probeer je onderdelen van de site dichter bij de gebruiker op te slaan. De webcache maakt gebruik van het gegeven dat bijvoorbeeld afbeeldingen in artikelen en stukken code op een website niet vaak veranderen.

Dat zit zo: met behulp van de webcache kun jij de 'asset', dus die code of afbeelding, alvast verspreiden over het web. Door de asset zo dicht mogelijk bij de bezoeker op te slaan, zorg je ervoor dat laadtijd voor bijvoorbeeld een mooie afbeelding toch binnen de perken blijft.

Tegen verschillende 'knooppunten' zeg je dan: serveer dit maar meteen aan iedereen die deze url bezoekt. Zo'n knooppunt kan de browser van de bezoeker zijn, wat dus effectief is bij een herhaalbezoek. Maar het kan ook een server zijn van een geografisch nabij Content Delivery Network (CDN) of de server van je Internet Service Provider (ISP). Ook een andere derde partij kun je gebruiken als webcache, net als de proxy van je back-end server.

Om de webcache goed te benutten is het wel zaak dat de applicatiebouwer goed aan de verschillende knooppunten vertelt welke assets gecachet mogen worden, hoe lang en onder welke voorwaarden. Met name die voorwaarden zijn belangrijk, want als je de afbeelding toch wijzigt, wil je natuurlijk wel dat alle bezoekers zo snel mogelijk die nieuwe afbeelding te zien krijgen. Het is dus de kunst om de webcache zo slim mogelijk in te richten. Dit doe je door hier samen met de technische mensen uit je organisatie en de mensen die verantwoordelijk zijn voor de hosting goed over na te denken. Betrek daar ook eventueel technische experts van je CMS leverancier bij.

tips & tricks - nieuw CMS selecteren

De Applicatiecache

De server waarop je website staat heeft ook een tijdelijk geheugen waarmee je de laadtijd kunt beïnvloeden. Deze werkt net iets anders. Vanaf de server wordt de website als een geheel naar de browser van de bezoeker gestuurd. Je server brengt daarvoor alle losse stukjes van je website — het menu, het weerbericht, een stukje tekst en een advertentie — zelf samen.

Als je site uit veel verschillende onderdelen is opgebouwd en je ‘berekent’ bij elk verzoek alle losse onderdelen opnieuw dan duurt dat onnodig lang. Je kunt van elk stukje website namelijk afzonderlijk bepalen hoe lang dat stukje relevant is.

Neem de beurskoersen en de fileberichten: die moeten altijd up-to-date zijn en die sla je dus niet op in de cache. Dat geldt ook voor andere dynamische content: het laatste nieuws en een liveblog.

Maar als het menu van je website verandert is het niet zo heel erg als een bezoeker dat niet direct te zien krijgt: je kunt daarvan aangeven dat de site best nog tien minuten dat oude menu mag tonen. Hetzelfde geldt wellicht voor een archief of zoekfunctionaliteit.

Vervolgens verzamel je bij het samenstellen van de pagina de blokjes uit de cache die nog relevant zijn en die combineer je met de dynamische content. Op deze manier kun je ook binnen de applicatie slim gebruik maken van een vorm van caching. Het is hiervoor wel essentieel dat je goed weet welke strategie je toepast op welk deel van de website.

Personalisatie en caching

Gepersonaliseerde content is ook dynamische content. Die content in de cache opslaan is lastig omdat daarmee automatisch de mate van personalisatie afneemt. Om toch een snelle laadtijd te kunnen bewerkstelligen ga je op zoek naar dat wat wél in de cache kan. Welke onderdelen van de site zijn wél te cachen met behoud van personalisatie en op welk niveau?

Wat je wel en niet in de cache opslaat is dus een kwestie van de balans zoeken tussen de prestatie van je site en de gewenste mate van up-to-date zijn en personalisatie.

 

Kortom: de vriendschap met je cache vergt weliswaar wat onderhoud, maar daar krijg je heel wat moois voor terug. Een perfect presterende website en dus de optimale customer experience.

<< Back

Posts containing: