Grunnleggende caching i nettleseren: en enkel guide for raskere og mer stabile nettsider

Mange nettsider føles trege, selv om serveren er grei og innholdet ikke er spesielt tungt. Ofte handler det om at nettleseren må hente de samme filene om og om igjen, for hver eneste sidevisning.

Med enkel caching kan du redusere unødvendige nedlastinger, gjøre siden mer responsiv og samtidig spare både båndbredde og serverressurser. Her får du en praktisk, jordnær innføring som er lett å ta i bruk i vanlige webprosjekter.

Hva er caching, egentlig?

Caching betyr at nettleseren lagrer kopier av filer lokalt, slik at den kan gjenbruke dem senere i stedet for å hente alt på nytt fra serveren. Typiske kandidater er CSS, JavaScript, fonter og bilder.

Når caching er riktig satt opp, trenger nettleseren bare å hente HTML-siden og eventuelle nye eller endrede filer. Alt annet kan lastes fra lokalt minne eller disk, som er mye raskere enn å gå over nettverket.

To hovedtyper: sterk caching og betinget caching

I HTTP-headerne kan du styre hvordan nettleseren får lov til å lagre ressursene dine. I praksis møter du oftest to varianter av oppførsel: sterk caching og betinget caching.

Sterk cachingbetyr at nettleseren får beskjed om å bruke den lagrede kopien uten å spørre serveren i en gitt periode.Betinget cachingbetyr at nettleseren sjekker med serveren om filen har endret seg, før den eventuelt laster ned en ny versjon.

Viktige HTTP-headere for caching

Du trenger ikke kunne hele HTTP-spesifikasjonen, men disse feltene er nyttige å kjenne til når du vil ha litt kontroll.

• Cache-Control: styrer hvor lenge og hvordan ressursen kan caches (for eksempel max-age, no-store).
• Expires: eldre måte å angi utløpstid på, en konkret dato i fremtiden.
• ETag: et slags fingeravtrykk av filen som kan brukes til å sjekke om den er endret.
• Last-Modified: tidspunktet filen sist ble endret på serveren.

På de fleste moderne oppsett erCache-Controldet viktigste å fokusere på, resten er som oftest supplement eller bakoverkompatibilitet.

En trygg standardstrategi for små og mellomstore sider

For mange nettsider fungerer det fint å skille mellom to typer innhold: relativt statiske ressurser og mer dynamisk innhold som kan endre seg ofte. Når du deler det opp slik, blir valgene enklere.

Du kan tenke omtrent slik: CSS, JavaScript, fonter og bilder kan få lang cache-tid, så lenge du håndterer versjonering. HTML-sider og data som ofte oppdateres bør caches mer forsiktig, og gjerne bare med kort varighet eller betinget caching.

Lang caching for statiske filer med filnavnversjonering

En mye brukt og trygg teknikk er å gi statiske filer versjon i filnavnet. Det kan være et byggnummer, en hash eller et enkelt versjonsnummer som oppdateres når filen endres.

Eksempel i HTML:

<link rel="stylesheet" href="/css/site.v3.css">

Når du endrer CSS-en, oppdaterer du referansen til for eksempel site.v4.css. Nettleseren oppfatter dette som en ny fil og henter den selv om den gamle ligger i cachen.

Enkel konfigurasjon med Cache-Control

Hvis du har tilgang til serverkonfigurasjon, kan du sette caching med Cache-Control for ulike filtyper. Nøyaktig syntaks varierer med teknologi, men prinsippet er det samme.

En vanlig strategi er å gi statiske filer lang varighet, for eksempel 1 år, sammen med immutable for filer med versjon i navnet:

• Cache-Control: public, max-age=31536000, immutable for versjonerte CSS/JS/bilder
• Cache-Control: no-cache eller en lav max-age for HTML-sider

immutable forteller nettleseren at filen ikke vil endre seg i cache-perioden, så det er ingen vits i å spørre serveren om den er oppdatert.

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

Caching er kraftig, men hvis den brukes uforsiktig kan besøkende sitte igjen med gammelt innhold lengre enn du ønsker. Det er spesielt viktig å tenke på dette for innhold som er tidskritisk eller sensitivt.

Typiske områder der du bør være konservativ med caching er innloggede sider, dashboards, handlekurver, ordrehistorikk, kontosider og alt som inneholder personopplysninger eller økonomi.

Vanlige feil og hvordan du unngår dem

Flere vanlige problemer går igjen når folk begynner med caching. Heldigvis kan de fleste unngås med noen enkle vaner og bevisste valg.

• Endringer synes ikke for besøkende:ofte skyldes dette for lang cache på HTML eller statiske filer uten versjonering. Løsning: sett kortere cache på HTML og bruk filnavnversjonering på statiske filer.
• Nettstedet oppfører seg rart etter deploy:kan komme av at gammel JavaScript fortsatt brukes sammen med ny HTML. Løsning: sørg for at alle nye versjoner av JS og CSS får nytt navn, og at HTML peker på disse.
• Private data cachenes for hardt:dette kan gi både forvirring og personvernrisiko. Løsning: bruk no-store eller restriktive regler på sider med sensitive data, og test i ulike nettlesere.

En enkel sjekkliste før du går live

Før du skrur opp caching i produksjon, er det lurt å teste nøye i ulike scenarioer. Både du og eventuelle redaktører bør sjekke at oppdateringer faktisk blir synlige innenfor akseptabel tid.

• Test kall i nettleseren med utviklerverktøy og se hvilke headere som faktisk sendes.
• Prøv å oppdatere CSS og sjekk at nye besøkende får opp endringen uten manuelt å tømme cache.
• Logg inn som vanlig besøkende og se at innloggede sider ikke viser gammel informasjon.

Hvis du gjør endringer i serveroppsettet senere, bør du ta en ny runde med de samme testene. Reglene for caching er en del av den tekniske kvaliteten, ikke en engangsoppsett som aldri røres igjen.

Oppsummering: små grep, stor gevinst

Du trenger ikke avanserte CDN-oppsett eller komplekse byggeverktøy for å få nytte av caching. Med filnavnversjonering, bevisste Cache-Control-regler og litt testing kommer du veldig langt.

Start enkelt: gi statiske filer fornuftige regler, vær forsiktig med HTML og sensitive sider, og legg inn en rutine for å sjekke caching-effekten ved nye lanseringer. Det gir raskere opplevelse og mindre stress ved neste endring.