Enkel guide til HTTP-caching: slik får du nettsiden til å føles lett og responsiv

Mange bruker tid på å optimere bilder og kode, men glemmer noe som ofte gir størst effekt: god utnyttelse av HTTP-caching. Riktig satt opp kan caching gjøre at siden føles lett, responsiv og rimelig å drifte, uten at du skriver én linje JavaScript ekstra.

I denne guiden ser vi på hvordan caching faktisk fungerer, hvilke overskrifter du bør kjenne til, og hvordan du kan legge en enkel, trygg strategi som fungerer både for små nettsteder og mer avanserte løsninger.

Hva er HTTP-caching, egentlig?

Når noen besøker nettsiden din, lastes HTML, CSS, JavaScript, fonter og bilder ned til nettleseren. Uten caching ber nettleseren om alt på nytt ved hvert besøk, selv når filene er helt like som forrige gang.

HTTP-caching lar nettleseren (og mellomliggende proxyer eller CDN) lagre ressurser lokalt en periode. Hvis innholdet ikke har endret seg, kan nettleseren bruke den lagrede versjonen i stedet for å hente den på nytt fra serveren.

To hovedtyper caching du bør skille mellom

Det er nyttig å skille mellom to strategier: caching av statiske ressurser og caching av HTML. Mange små nettsteder får store gevinster bare ved å gjøre det første riktig.

Statiske ressurser er filer som sjelden endres, typisk CSS, JavaScript, fonter og bilder. HTML endres ofte oftere og bør derfor caches mer forsiktig.

Viktige HTTP-headere: Cache-Control, Expires og ETag

Nettlesere og mellomlagre styres i stor grad av HTTP-headere. De viktigste du vil støte på, erCache-Control,ExpiresogETag.

Cache-Controler dagens standardvalg. Med den kan du blant annet styre hvor lenge noe kan ligge i cache, om det er offentlig eller privat, og om nettleseren i det hele tatt har lov til å cache ressursen.

Enkle eksempler på Cache-Control

Her er noen typiske verdier du vil se, oversatt til praktiske eksempler:

• Cache-Control: public, max-age=31536000, immutablefor versjonerte CSS/JS-filer som bare endres når filnavnet gjør det.
• Cache-Control: public, max-age=300for HTML som kan ligge i cache i noen minutter, men bør oppdateres jevnlig.
• Cache-Control: no-storefor svært sensitivt eller dynamisk innhold som aldri skal lagres.

Expireser en eldre måte å angi utløpstid på, som fortsatt støttes. Mange servere sender både Expires og Cache-Control for bakoverkompatibilitet.

Validering med ETag og Last-Modified

ETagogLast-Modifiedbrukes til såkalt betinget caching. Nettleseren kan spørre serveren om filen er endret siden sist, i stedet for å laste hele filen på nytt.

Hvis ressursen er uendret, svarer serveren med statuskode 304 og svært liten datamengde. Resultatet er mindre trafikk og raskere følelse for den som besøker siden, selv om ressursen teknisk sett hentes på nytt.

Trygg grunnstrategi for små og mellomstore nettsteder

Hvis du vil ha en enkel start uten å gå deg vill i alle muligheter, kan du følge denne grunnstrategien:

• GiHTMLkort cachetid, for eksempel 0 til 5 minutter, og tillat validering med ETag.
• Gistatisk innhold med versjonerte filnavnlang cachetid, for eksempel ett år.
• Gistatisk innhold uten versjoneringmoderat cachetid, for eksempel én dag.

Versjonerte filnavn betyr at du endrer navnet på filen når innholdet endres, for eksempel style.2024-06.css eller ved bruk av hashes gjennom et byggverktøy.

Hvordan endre caching i Apache, Nginx og via PHP

De fleste delte webhotell og VPS-oppsett kjører Apache eller Nginx. Mange kontrollpaneler har egne innstillinger for caching, men du kan også sette headere manuelt i konfigurasjon eller .htaccess.

I Apache kan du for eksempel bruke mod_headers og mod_expires til å sette Cache-Control og Expires for ulike filtyper. I Nginx brukes egne location-blokker med expires og add_header.

Typiske feil som gir dårlig caching

En vanlig feil er å gi HTML veldig lang cachetid uten versjonering. Da får besøkende ofte utdaterte sider, og det blir vanskelig å rulle ut kritiske endringer.

En annen feil er å bruke samme filnavn for CSS og JavaScript, samtidig som du gir filene lang cachetid. Nettleseren sitter da fast med gammel stil og logikk, selv om du har oppdatert filinnholdet.

Hvordan teste om caching fungerer som tenkt

Det er lurt å sjekke hva som faktisk går over nettet, ikke bare hva du tror serveren gjør. De fleste nettlesere har utviklerverktøy der du kan se alle forespørsler, headere og cache-status.

I Chrome og Edge finner du dette under Network-fanen. Se etter kolonnen som viser om en ressurs ble hentet fra cache, revalidert eller lastet helt på nytt, og les Cache-Control og relaterte headere i detalj.

Caching og innholdsleveringsnettverk (CDN)

Bruker du en CDN-tjeneste, kan den ofte overstyre caching-regler. Det kan være både en fordel og en kilde til forvirring. Sørg for at du forstår hvilke regler som kommer fra serveren din og hvilke som settes i CDN-panelet.

En ryddig tilnærming er å ha en bevisst standard i applikasjonen eller på opprinnelsesserveren, og deretter bruke CDN-et til mer finjustering eller nødløsninger for midlertidige behov.

Når bør du være forsiktig med caching?

Alt innhold som er knyttet til pålogging, personlige data eller hyppig oppdatert informasjon, bør behandles med ekstra omtanke. Her er det ofte riktig med kort cachetid eller direkte forbud mot caching.

Hvis du er usikker, er det bedre å gi litt for kort cachetid i starten og heller øke den senere når du har bedre oversikt. Du kan også skille mellom innlogget og utlogget trafikk, og være mer offensiv med caching for de som ikke er logget inn.

Oppsummering: start enkelt og bygg videre ved behov

Du trenger ikke en komplisert strategi for å få stor effekt av HTTP-caching. Konsekvent håndtering av HTML, versjonerte statiske filer og tydelige Cache-Control-headere tar deg langt.

Begynn med en enkel grunnkonfigurasjon, test med nettleserens utviklerverktøy, og juster forsiktig. Etter hvert som nettstedet vokser, kan du supplere med CDN, mer detaljerte regler og bedre automatisering i byggløypen.