CDN (innehållsleveransnätverk)

Avstånd är fördröjning

Ett anrop från Stockholm till en server i Virginia korsar Atlanten två gånger innan första byten kommer tillbaka, och uppkopplingen kräver flera tur och retur. Det är 100 millisekunder eller mer i oundviklig fördröjning, upprepad för varje resurs som inte är cachad. Att servera samma fil från en nod i Stockholm tar bort den.

Den andra vinsten är kapacitet. En trafiktopp tas emot av hundratals kantnoder i stället för av din egen server, och filer som levereras ur cachen når aldrig din infrastruktur alls. Det är därför statisk drift på ett CDN – Firebase Hosting, Cloudflare, Netlify – är både snabbare och billigare än en enskild virtuell maskin, och varför statiskt genererade webbplatser passar så väl.

Vad ett CDN kan och inte kan cacha

Cachningsbart, och där vinsten är störst: bilder, typsnitt, CSS, JavaScript-paket och förrenderade HTML-sidor som ser likadana ut för alla.

Inte cachningsbart på något användbart sätt: personlig HTML och varje API-svar som speglar en enskild användares data. Det är den missuppfattning som är värd att säga rakt ut – ett CDN gör inte en långsam databas eller ett långsamt API snabbare. Om din app lägger 800 millisekunder på att vänta in en fråga ändrar ett CDN framför nästan ingenting, eftersom svaret inte kan återanvändas för nästa besökare. Det kortar transporten, inte arbetet.

Cachestyrningen är det som bränner

Två headers avgör beteendet: Cache-Control anger hur länge en fil får återanvändas, och ETag låter webbläsaren billigt kontrollera om den ändrats. Standardmönstret är att ge filnamn med innehållshash mycket lång livslängd och HTML kort, så att en driftsättning byter filnamnen och de gamla filerna helt enkelt slutar efterfrågas.

Gör tvärtom – lång cache på HTML – och användarna ser gårdagens sida långt efter att du publicerat. Att rensa kantcachen fixar CDN:ets kopia men inte den som redan ligger i varje webbläsare, vilket är skälet till att filnamnshashar föredras framför att förlita sig på rensningar.