Edge-caching in de praktijk: hoe elke pagina uit een Europees datacenter dichtbij komt

In een eerder artikel legden we uit waarom onze sites pure HTML zijn. Vandaag de tweede helft van het snelheidsverhaal: waar die HTML vandaan komt. Spoiler: meestal niet van onze server.

Foto: "Racks line" door kewl, CC BY 2.0, via Openverse. Verkleind.

De reis van één paginabezoek

Stel: iemand in Gent tikt de site van een klant van ons aan. Wat gebeurt er?

1. De browser zoekt het adres op en komt uit bij het CDN — een netwerk van datacenters verspreid over Europa. De bezoeker wordt automatisch naar de dichtstbijzijnde edge-node geleid; voor Gent is dat een node in de buurt.
2. Die edge-node heeft de pagina vrijwel altijd al klaarliggen in zijn cache, als afgewerkte HTML. Hij levert ze meteen af, samen met de afbeeldingen en stylesheet. Zonder omweg via onze server.
3. Alleen als de pagina er nog niet ligt (de eerste bezoeker na een wijziging, of een zelden bezochte pagina), haalt de edge ze één keer op bij onze oorsprongsserver en onthoudt ze daarna.

Onze applicatieserver merkt van de meeste bezoeken dus niets. Dat is het punt: de machine die je paneel draait en je content beheert, staat niet in de kritieke lijn van je bezoekersverkeer.

Waarom dit meer is dan snelheidswinst

Pieken worden opgevangen. Wordt een klant vermeld in een krant of gaat een post viraal, dan vangt het CDN die duizenden extra bezoekers op vanuit cache. De oorsprongsserver ziet er nauwelijks iets van; de site vertraagt niet.

Storingen worden kleiner. Ook als onze oorsprong even onbereikbaar is (een deploy die tegenzit, een netwerkprobleem), blijft de gecachte versie van je site gewoon geserveerd worden. Bezoekers merken niets van het spannendste kwartier van onze week.

Afstand doet ertoe, ook binnen Europa. Een pagina die van een nabije node komt in plaats van uit een ver datacenter, scheelt wachttijd bij elk bestand. Op een site die toch al licht is, helpt dat bij precies wat Google's Core Web Vitals meten.

Waarom Bunny.net

We kozen bewust voor Bunny.net, een CDN in Europese handen (Slovenië), met edge-locaties over heel Europa. De gebruikelijke keuzes in onze sector zijn Amerikaans, en dan geldt de CLOUD Act — ook op hun Europese servers. Onze belofte "je website verlaat Europa nooit" moet ook voor de bezorging gelden, niet alleen voor de opslag. Eerlijke bijvangst: Bunny is bovendien opvallend betaalbaar, wat meespeelt in waarom onze abonnementen kosten wat ze kosten.

De moeilijke vraag: en als er iets wijzigt?

Caching heeft één klassieke valkuil: een pagina die overal klaarligt, moet ook overal wég kunnen. Niemand wil dat zijn aangepaste menukaart pas "ergens vandaag" zichtbaar wordt. Daarom stuurt het platform bij elke publicatie gerichte purge-opdrachten naar het CDN voor precies de pagina's die veranderden. Publiceren in je paneel betekent: binnen enkele seconden vers op elke edge-node in Europa. Hoe dat invalidatiemechanisme precies werkt — en wat er misging toen we het bouwden — lees je in Publiceren en binnen seconden live.

Het resultaat van dit alles zie je niet, en dat is de bedoeling: een site die overal in Europa aanvoelt alsof hij bij de bezoeker om de hoek draait. Omdat hij dat, technisch gezien, ook doet.