Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Anchor | ||||
---|---|---|---|---|
|
Caching er en teknik, der bruges til at gemme data midlertidigt, så man reducerer belastningen på servere og netværk.
Når vi taler om web-applikationer, kan caching forekomme på flere niveauer: På serversiden, i webbrowseren og i selve webapplikationen.
Table of Contents |
---|
Sideinformation
Display Metadata | ||
---|---|---|
|
Serverside
CachingCache
Vi springer hurtigt over caching på selve serveren, for det er der forhåbentligt allerede tænkt på, og det varierer fra API til API, hvilke data det kan betale sig at cache.
Serveren kan opfordre til caching på browser-niveau ved at sætte visse response HTTP-headers:
- "Cache-Control" - styrer hvordan og hvor længe browseren må cache data.
- "Last-Modified" og "ETag" - Bruges af browseren til at vurdere, om en resource har ændret sig og bør hentes igen.
Browser
CachingCache
(Browser: Selve browserprogrammet (f.eks. Edge, Chrome, Safari) ude hos den enkelte slutbruger.)
Browsere vil som udgangspunkt cache data fra en HTTP-response, men det kan variere afhængigt af kontekst.
Vær opmærksom på, hvordan "Cache-Control" header er sat, og hvilke data, der returneres i responsen.
Webapplikation C
achingache
(Webapplikation: En webside med tilhørende HTML/Javascript. Det kører i browseren ude hos slutbrugeren. (F.eks. Boligas webside, når du tilgår den fra din telefon.))
Webapplikationer kan selv implementere interne caching-mekanismer, men det vil som regel være forbundet med store omkostninger at implementere.
For mange vil det forekomme som dobbelt arbejde, når teknologien jo allerede findes i browseren.
I nogle tilfælde kan det blive nødvendigt at tvinge browser-caching igennem for Fetch requests (Se link #3 nedenfor)
Hvis både server- og browser-caching spiller fallit, er et en mulighed at bruge "ServiceWorkers" til at håndtere caching direkte i webapplikationen. (Se link #4 nedenfor)
Eksempler
API-response fra Dataforsyning STAC API
Fetch request til
Server har response headers:
(Server: Datafordeleren distributionsserver. Det sted, som data kommer fra.)
"cache-control: max-age=86400" - Angiver at browsere bør cache responsen i op til 24 timer
Der returneres noget JSON, som caches i browseren.
API-response fra DHMTerraen
Fetch request til
https://services.datafordeler.dk/DHMTerraen/DHMKoter/1.0.0/GEOREST/HentKoter?geop=POINT(574764 6220953)&elevationmodel=dtm&username=xxx&password=yyy
Server har response headers:
"Cache-Control: private" - Angiver, at browsere må cache den returnerede JSON som de har lyst.
Der returneres noget JSON, som automatisk caches i browseren.
API-reponse fra DHMNedboer
Fetch request til
Server har response headers som i eksemplet ovenfor:
"Cache-Control: private"
Men her returneres der en Tiff-fil, som ikke umiddelbart bliver cachet af browseren.
Her burde serveren bruge en anden værdi for Cache-Control for at opfordre klienter til at cache, f.eks. "Cache-Control: public, max-age=31536000".
I dette tilfælde bruger klienten Fetch API, så vi kan ændre "cache" property i requesten fra klienten til: "cache: 'force-cache'" og således opnå, at browseren også cacher disse filer. (Se link #3)
Links
Cache styret fra serversiden
- https://web.dev/articles/http-cache - Kort gennemgang af HTTP caching
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching - Grunding gennemgang af HTTP caching
Cache styret fra webapplikation
3. https://developer.mozilla.org/en-US/docs/Web/API/Request/cache - Brug af Request "cache" property (Specifikt for Fetch requests)
4. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Caching - Om brug af ServiceWorker til caching