Content optimaliseren voor Varnish

In onze eerste twee Chalk Talk video’s legden we uit wat Varnish is en hoe het werkt. In deze derde Chalk Talk video bekijken we “Content optimaliseren voor Varnish”. Hoe zorg je ervoor dat de juiste pagina’s gecached worden en dat de pagina’s juist gecached worden? Want enkel op die manier bezorg je de bezoekers van je website een optimale ervaring. (tip: je kan onderaan eenvoudig Nederlandstalige of Engelstalige ondertitels aanzetten)

De uitgeschreven tekst van deze Chalk Talk “Hoe optimaliseer je content voor Varnish?”

Welkom bij Chalk Talk, een reeks video’s waarin we  complexe technologie uitleggen met één krijtbord. In deze video kijken we onder de motorkap van Varnish, naar het hart, de caching-engine.

Content optimaliseren voor Varnish

In een vorige video heb je kunnen zien dat er een cachegedeelte is midden in de hele workflow. Dit is waar de magie van Varnish gebeurt. Om te kijken hoe dit precies gebeurt,

doen we alsof we surfen naar deze URL. Dus we surfen naar nucleus.be/varnish. Als je dat in een browser typt, zie je een pagina over Varnish. Hoe ziet dit eruit voor Varnish?

Om te beginnen zal de gebruiker een browser request doen met een heleboel metadata over die specifieke pagina. Metadata zoals “Met welke host wil je contact opnemen?” Wat is de URL van de pagina? Welk protocol ga je gebruiken om toegang te krijgen?

In het http-protocol lijkt dit een simpele key value scheiding van sleutel en data. Je hebt een sleutel: de host-header. Dat is nucleus.be. Deze. Mogelijk heb je cookies omdat je bent ingelogd en al je cookies worden meegestuurd.

Je vraagt ​​om een ​​GET-methode van Varnish. Je voegt ook extra headers toe zoals een ACCEPT-header, bijvoorbeeld omdat je json responses wil in plaats van een html response. Dat alles, meestal iets meer dan 10 headers, gaat naar Varnish

De hashing-engine

Varnish zal alles ontvangen en deze headers in een soort van hashing-engine steken. Daaruit komt een unieke hash voor die request. Die hash zal worden opgezocht in de cache.

Dat is een enorme database van records, waar elk record een naam heeft, de hash. En als die te vinden is zal Varnish die eruit halen en terugsturen naar de gebruiker. Als die niet te vinden is moeten we een request doen naar de webserver of de backend. Wat er eigenlijk gaat gebeuren is dat je browser iets meer dan tien verschillende headers stuurt. Maar wij, en Varnish, kunnen bepalen welke headers onderscheid maken tussen mij en een collega.

Andere cookies, andere cache

Ik ga misschien naar nucleus.be met een bepaald aantal cookies. Wanneer iemand met exact dezelfde cookies en host-header die pagina bezoekt zal Varnish antwoorden. Als er een verschil is in de waarden van de host header of cookies, in plaats van nucleus.be bezoek je www.nucleus.be, gaat Varnish dit door zijn hashing-engine sturen en krijg je een andere hash, omdat de input anders was.

Hetzelfde als we Varnish zouden bezoeken met Google Analytics-campagneparameters. Die typische UTM-parameters in de URL. Het wordt een andere URL en daar komt een andere hash uit. Dit betekent dat deze pagina waarschijnlijk bereikt kan worden via tien of twintig verschillende URL’s door een ? of andere parameters toe te voegen.

Tips voor developers

Dat zorgt voor allerlei permutaties: veranderingen in de cache. Wat is belangrijk voor jou als developer of websitebeheerder? Probeer je URL zo proper mogelijk te houden. Uniformiseer je host-header. Maak er overal www.nucleus.be van of laat www overal weg. Doe dit consistent op de hele site.  Herschrijf ook pagina’s die een andere header hebben naar deze header.

Hetzelfde geldt voor de URL die je bezoekt. In jouw code is die misschien niet hoofdlettergevoelig, maar voor Varnish is dat wel zo. Ga ook niet zomaar parameters toevoegen. Hou alles zo proper mogelijk.

Vervelende cookies

Maar het echte lastige deel zijn de cookies. Als je session ID’s gebruikt, PHP of Ruby, het maakt niet uit, zullen de session ID’s van mij en mijn collega op het einde toch anders en uniek zijn.

Mijn sessie-ID zal mij identificeren als een unieke bezoeker. De sessie-ID van mijn collega doet hetzelfde voor hem. Daardoor zullen session ID’s die opgeslagen zijn in cookies zorgen voor unieke hashing resultaten in Varnish. Maar heb je altijd een sessie-ID nodig? Misschien heb je die enkel nodig als er een winkelmandje is of je bent ingelogd? Maar als je een session ID genereert voor elke bezoeker van je site, dan gaat elke bezoeker voor Varnish een unieke bezoeker lijken.

Genereer alleen session ID’s als het nodig is, houd je cookies zo proper en zo beperkt  mogelijk, omdat elke cookie die je toevoegt (een taalcookie, een voorkeurscookie, enz.) zorgt voor een andere versie van de hash en de Varnish cache. Dit deel kan heel snel groeien omdat elke versie wordt opgeslagen. In het ideale geval is dit ook zo klein mogelijk.

Een korte samenvatting

Als je een website hebt met een URL gebruikt die een protocol. Dit kan HTTP of HTTPS zijn. Voor Varnish doet dat er niet echt toe omdat Varnish zelf geen HTTPS afhandelt. Er zal iets voor Varnish staan voor HTTPS. Technisch is het een andere proxy die voor Varnish staat.

Alles wat Varnish ziet zijn HTTP requests. Dan heb je je host-header: welke website probeer je te bereiken? En je URL met een set cookies. En van alle extra headers die worden verzonden, kunnen we kiezen welke we goed vinden en welke we niet goed vinden. Als je toepassing extra headers heeft die erg belangrijk zijn om de hash en uniciteit te bepalen, kunnen we die ook toevoegen of verwijderen.

Houd dit zo proper mogelijk! Houd je cookies zo proper mogelijk! Dan zou je dezelfde hash moeten krijgen voor dezelfde pagina die je wil bereiken.

De volgende keer in Chalk Talk?

In de volgende video kijken we hoe je hier dieper in kunt duiken en hoe je problemen oplost of bepaalt waarom een ​​bepaalde pagina wordt opgeslagen en een andere pagina niet. Tot binnenkort voor een nieuwe episode van Chalk Talk!

Wil je nu al meer weten, kan je meteen ons Varnish eBook downloaden.

 

Gerelateerde berichten
GDPR voor developers

GDPR voor developers: praktische tips

Er bestaat al gigantisch veel informatie over GDPR. Informatie voor CEO’s, CIO’s, marketing managers… maar GDPR voor developers? Amper. Daar willen we met deze blogpost verandering in brengen. Wat moet je als developer weten over GDPR? En welke praktische tips kunnen we je geven?

Lees meer

DevOps Mythes

6 DevOps mythes die we graag uit de wereld helpen

DevOps is een hot topic. Je vindt er dan ook heel veel informatie over. Helaas is niet al die informatie even zinvol of correct. […]

Lees meer

Persoonlijke data

Betaal je binnenkort met persoonlijke data?

Betere privacy betekent niet noodzakelijk minder gedeelde persoonlijke data, eerder het omgekeerde. We willen een toevloed van (relevant) dataverkeer, maar met waardecreatie voor hen die er slim in investeren. Zo worden persoonsgegevens hotter dan de Bitcoin.

Lees meer