Hva er cache? Slik påvirker det farten på nettsiden din

Cache, eller hurtigbuffer på norsk, er en ferdig lagret kopi av filer eller sider. Den gjør at nettsiden ikke må bygges eller lastes ned på nytt ved hvert besøk. Riktig oppsatt gir den kortere lastetid og bedre Core Web Vitals. Feil oppsatt viser den gammelt innhold, eller i verste fall én kundes data til en annen kunde.

Hva er cache, og hva heter det på norsk?

Cache er en midlertidig kopi av data som er lagret nærmere brukeren, slik at den kan hentes raskere neste gang. På norsk kalles det hurtigbuffer, mellomlager eller bare buffer. Nettleseren på mobilen din bruker det, det samme gjør nettsiden din på serveren, og Google brukte det i mange år til å vise kopier av nettsider i søkeresultatene.

For en bedriftsnettside er poenget enkelt. Uten cache må serveren hente innhold fra databasen, kjøre kode og bygge siden på nytt for hver besøkende. Med cache leverer den en ferdig bygd HTML-fil på brøkdeler av tiden. Nettleseren slipper også å laste ned logo, skrifttyper og stilark på nytt når kunden klikker seg videre til neste side.

Ulempen er at en kopi kan bli gammel. Har du endret en pris eller åpningstid og kunden fortsatt ser den gamle, ligger det nesten alltid en kopi igjen i ett av lagene. Det vi ser oftest, er at bedriften tømmer cachen i nettleseren sin og tror problemet er løst, mens kopien fortsatt ligger på serveren eller i CDN-et.

Hvilke typer cache finnes på en nettside?

En vanlig WordPress-side eller nettbutikk har gjerne fire lag med cache, og hvert av dem tømmes på et eget sted. Tabellen viser hvor de ligger, hvem som styrer dem og hvordan du tømmer dem.

De fire cache-lagene på en typisk bedriftsnettside

• Lag | Hvor ligger kopien? | Hva lagres? | Hvem styrer det? | Slik tømmes det
• Nettleserens cache | På kundens PC eller mobil | Bilder, CSS, JavaScript, skrifttyper | Du, via Cache-Control-innstillinger | Kunden gjør en hard oppdatering eller tømmer nettleseren
• Sidecache | På serveren (utvidelse eller webhotell) | Ferdig bygde HTML-sider | Utvidelse i CMS-et eller webhotellet | «Tøm cache»-knapp i utvidelsen eller kontrollpanelet
• Objektcache (f.eks. Redis) | I serverens minne | Svar fra databasen | Webhotell eller utvikler | Tømmes i kontrollpanelet eller via utvikler
• CDN (f.eks. Cloudflare) | På servere nær brukeren | Filer og eventuelt HTML | Den som har tilgang til CDN-kontoen | «Purge cache» (tøm hurtigbuffer) i CDN-panelet

Hvilke lag du har, avhenger av plattformen. Lukkede plattformer som Wix og Squarespace styrer cachen for deg. Det er en del av grunnen til at de er enkle å bruke, men også til at du har lite å justere. På WordPress må du selv velge og sette opp løsningen. Vi går nærmere inn på forskjellene i guiden om hvordan du velger CMS-system.

Hvordan påvirker cache hastigheten og plasseringen i Google?

Cache påvirker først og fremst hvor raskt serveren svarer og hvor mye nettleseren må laste ned. Begge deler slår direkte ut i Core Web Vitals, som Google bruker som rangeringssignal. Ifølge web.dev bør Largest Contentful Paint (LCP), altså tiden det tar før hovedinnholdet vises, være 2,5 sekunder eller mindre. Over 4 sekunder regnes som dårlig. Målingen gjøres ved 75. persentil av sidevisningene.

Her kommer cache inn: Google skriver i veiledningen Optimize LCP at høy TTFB (tiden før den første byten kommer fra serveren) kan gjøre det vanskelig eller umulig å nå 2,5 sekunder. På en WordPress-side uten sidecache bruker serveren ofte mye av tiden på å bygge siden før noe i det hele tatt sendes. Ingen bildekomprimering kan hente inn den tiden igjen. Derfor setter vi opp sidecache før vi begynner å skru på bildene.

Etter Lighthouse-optimalisering (bildekomprimering, caching, opprydding i skript) forbedres ytelsesscoren hos Box sine kunder typisk fra under 55 til over 80.

Cache hjelper også på søk på en mindre opplagt måte. Når siden svarer raskt, kan Google gjennomsøke flere sider på samme tid. Det gjelder også for AI-oversiktene (AI Overview) og andre AI-svar i søk, som bygger på innholdet Google har gjennomsøkt og indeksert. En treg eller ustabil server gjør at nye og oppdaterte sider fanges opp senere. Vil du gå videre med det tekniske, har vi en egen guide om søkemotoroptimalisering i WordPress.

Hvordan sletter du cache, og i hvilken rekkefølge?

Tøm cachen innenfra og ut: først i CMS-et, så på serveren, så i CDN-et og til slutt i nettleseren. Gjør du det i motsatt rekkefølge, kan CDN-et hente den gamle kopien fra serveren på nytt før serveren er tømt. Da ser kunden fortsatt feil versjon.

• 1. Tøm sidecachen i CMS-et. I WordPress finner du knappen i cache-utvidelsen, for eksempel i adminlinjen øverst («Purge All» eller «Tøm cache»).
• 2. Tøm serverens cache hos webhotellet. Mange norske webhotell har egen sidecache eller Redis i kontrollpanelet, og den tømmes ikke av utvidelsen i WordPress.
• 3. Tøm CDN-et. I Cloudflare heter funksjonen «Purge Cache». Gjelder endringen bare én side, er det bedre å tømme den ene adressen enn alt. Da slipper serveren at alle sidene bygges på nytt samtidig.
• 4. Gjør en hard oppdatering i nettleseren: Ctrl + Shift + R (Windows) eller Cmd + Shift + R (Mac). Da hentes siden på nytt uten at hele nettleserhistorikken slettes.
• 5. Holder ikke det, tømmer du nettleserens hurtigbuffer: Ctrl + Shift + Delete i Chrome, Edge og Firefox på Windows (Cmd + Shift + Delete i Chrome på Mac). Kryss bare av for «Bufrede bilder og filer», ikke for informasjonskapsler, hvis du ikke vil logges ut overalt.
• 6. Kontroller i et privat vindu, eller på mobilen med wifi slått av. Ser du riktig versjon der, er serveren og CDN-et i orden.

Ser kunden gammelt innhold selv om du ser riktig versjon, er det som regel kundens egen nettleser eller et mellomledd hos kunden som henger igjen. Det løser du ikke på serveren. Løsningen er at filene får nye navn ved hver endring, som vi forklarer i neste del. Bruker du et byrå til drift, bør tømming av cache etter endringer stå i rutinen. Se hva som bør være med i en avtale om drift av nettside.

Hvilke cache-innstillinger bør nettsiden ha?

Filer som har nytt navn ved hver ny versjon, bør lagres i ett år. HTML-sider bør lagres kort eller sjekkes mot serveren før de brukes på nytt. Sider med personopplysninger skal ikke lagres i det hele tatt. Det styres av HTTP-hodet Cache-Control, og MDNs dokumentasjon av Cache-Control er referansen utviklere bruker.

Anbefalte Cache-Control-oppsett etter filtype

• Innhold | Innstilling | Hvorfor
• CSS, JavaScript og skrifttyper med versjon i filnavnet (style.a1b2c3.css) | public, max-age=31536000, immutable | Ny versjon gir nytt filnavn, så den gamle kopien kan ligge et år
• Bilder og PDF-er uten versjon i navnet | max-age=86400 pluss ETag | Lagres i ett døgn, deretter går en rask sjekk mot serveren
• Offentlige HTML-sider (forside, tjenestesider) | no-cache, eller kort max-age i nettleseren og lengre i CDN | Kunden ser endringer raskt, mens serveren får mindre å gjøre
• Handlekurv, kasse, Min side, innlogget innhold | private, no-store | Skal aldri lagres i et delt lag

Tre fallgruver som koster dyrt

Den første er å tro at «no-cache» betyr «ikke lagre». Det betyr at kopien kan lagres, men må sjekkes mot serveren før hver bruk. Det er «no-store» som forbyr lagring. Den andre er å sette `max-age=31536000, immutable` på filer som ikke bytter navn ved endringer. MDNs veiledning om HTTP-caching forklarer at immutable sier til nettleseren at innholdet aldri endres. Får det nye stilarket samme filnavn, kan vanlige besøkende se det gamle designet lenge etter lanseringen. Dette rammer gjerne et redesign av nettsiden rett etter lansering.

Den tredje er den alvorligste. I Cloudflare kan man sette en regel om å bufre alt («Cache Everything»), som også lagrer HTML. Uten et unntak for innloggede brukere og handlekurv-informasjonskapsler kan én kundes handlekurv eller Min side bli vist til neste besøkende. WooCommerce ber cache-utvidelser om å holde handlekurv og kasse utenfor, men CDN-et og serverens cache følger ikke alltid den beskjeden. Hvis personopplysninger blir vist til feil person, er det et brudd på personopplysningssikkerheten, og da gjelder GDPR-fristen på 72 timer for å melde fra til Datatilsynet. Vi fraråder derfor regler som bufrer all HTML i nettbutikker, med mindre noen har testet dem innlogget og med varer i handlekurven.

Krever cache samtykke etter de nye reglene for informasjonskapsler?

Vanlig HTTP-cache av egne filer, som er nødvendig for å levere siden brukeren har bedt om, regnes etter vår vurdering ikke som noe som krever samtykke. Men ekomloven § 3-15 er teknologinøytral, og reglene ble strammet inn fra 1. januar 2025. Ifølge Datatilsynets veiledning må samtykke til informasjonskapsler og lignende teknologi være gyldig etter GDPR. Lagres informasjon lokalt hos brukeren for analyse eller sporing, krever det samtykke, uansett om leverandøren kaller det cache eller noe annet. Beskriv lagringen i personvernerklæringen.

Hva skjedde med Google cache?

Google cache er avviklet. Google fjernet lenken til den bufrede kopien i søkeresultatene tidlig i 2024, og i september 2024 sluttet også søkekommandoen cache: å virke. Fra 11. september 2024 lenker Google i stedet til Internet Archives Wayback Machine. Du finner lenken ved å klikke på de tre prikkene ved et søkeresultat og åpne panelet «Om dette resultatet».

For bedrifter betyr det at du ikke lenger kan bruke Google cache til å se når Google sist besøkte siden din, eller hvordan Google så den. Bruk heller URL-inspeksjon i Google Search Console. Der ser du siste gjennomsøking, og med «Test publisert nettadresse» ser du hvordan siden blir vist nå. Ligger det fortsatt gamle titler eller priser i søkeresultatet, er det fordi Google ikke har gjennomsøkt siden på nytt. Det har ingenting med cachen din å gjøre. Mer om hvordan søkemotorene henter innhold, finner du i artikkelen om hvordan søkemotorer fungerer.

Når cache ikke er riktig løsning på en treg nettside

Cache løser ikke en treg nettside hvis problemet ligger i tunge bilder, for mange skript fra tredjeparter eller et overlesset tema. Det hjelper heller ikke hvis innholdet er unikt for hver besøkende. Da gjør cachen bare at det samme problemet blir levert litt raskere, eller at feilen blir vanskeligere å finne.

• Sider som er unike for hver besøkende, som Min side, bookingkalendere med sanntidsdata og kasser i nettbutikker, kan i liten grad bufres. Der er det databasen og koden som må bli raskere.
• Har webhotellet treg prosessor eller lite minne, gjør cachen førstebesøket raskt, men hver gang cachen tømmes, blir siden treg igjen. Da er det bedre å bytte webhotell enn å legge på flere lag.
• To cache-utvidelser samtidig, eller en utvidelse oppå webhotellets egen cache, gir ofte ødelagt design og hvite sider. Velg én løsning.
• Hvis du nettopp skal lansere en ny side, bør cachen vente til innholdet er ferdig. Ellers bruker du tiden på å tømme cache i stedet for å teste.

Hva koster det å sette opp cache riktig?

Selve verktøyene er ofte gratis. Det som koster, er oppsett, testing og vedlikehold. LiteSpeed Cache, WP Super Cache og W3 Total Cache er gratis utvidelser til WordPress, og Cloudflare har en gratisplan. Mange webhotell har dessuten sidecache inkludert. Betalte utvidelser og bedre servere koster mer, og prisene varierer så mye at du bør sjekke hos leverandøren.

I tekniske SEO-gjennomganger hos Box er de tre vanligste funnene manglende/feil canonical-tagger, uoptimaliserte bilder og treg mobil-lastetid — alle tre er normalt løst på under en arbeidsdag.

For en vanlig bedriftsnettside er cache altså en jobb på timer, ikke uker. Den store kostnaden er feil som ikke blir oppdaget: en kasse som er bufret, eller et nytt design som ikke vises. Vårt råd er å legge oppsettet inn i en fast rutine for vedlikehold av WordPress, slik at cachen blir testet på nytt etter oppdateringer. Vil du se hva teknisk arbeid utgjør av totalbudsjettet, har vi samlet tallene i oversikten over hva en nettside koster. En rask egenkontroll kan du gjøre med gjennomgang for å sjekke nettsider.

Vil du ha hjelp med farten på siden, ser vi på hele løsningen: server, cache, bilder og skript. Les mer om hvordan vi bygger og drifter nettsider for bedrifter.