Page cache, object cache og browser cache: hvem gør hvad?

Kort svar: Der er fire cache-lag, og de løser hver sin opgave: browser cache (genbrug af filer hos den enkelte besøgende), CDN- eller edge-cache (filer serveret tæt på besøgende), page cache på serveren (færdig HTML til anonyme besøgende) og object cache (databasesvar til de dynamiske sider). Når nogen siger “ryd cachen”, er spørgsmålet altid: hvilken? Kender du lagene, ved du både, hvad du skal fejlsøge, og hvad du mangler.

Fagligt gennemgået: 2. oktober 2026

“Cache” bruges om fire forskellige ting, og sammenblandingen koster både fejlfindingstimer og forkerte køb. Denne guide giver dig det mentale kort: hvor hvert lag bor, hvad det gemmer, hvornår det rammer – og hvordan de spiller sammen på et hurtigt WordPress-site.

Rejsen gennem lagene

En request stopper ved det første lag, der kan svare. Browseren tjekker først sin egen cache. Derefter kommer et eventuelt CDN, så serverens page cache – og kun hvis ingen af dem har et færdigt svar, starter PHP og WordPress. Når WordPress kører, kan object cachen spare databasen for gentagne forespørgsler.

Jo tidligere et lag kan svare, jo hurtigere bliver oplevelsen, og jo mindre arbejde lander på serveren.

De fire lag – hver sin opgave

Lag	Bor	Gemmer	Hjælper
Browser cache	Hos den besøgende	Statiske filer (CSS, JS, billeder, fonte)	Gengangere og sideskift
CDN/edge cache	På servere nær besøgende	Statiske filer – og HTML med edge-løsninger som APO	Fjerne besøgende og spidsbelastning
Page cache	På din server (LiteSpeed eller plugin)	Færdig HTML til anonyme besøgende	TTFB for al anonym trafik – størst enkeltgevinst
Object cache	I serverens RAM (Redis eller Memcached)	Databasesvar og beregnede værdier	wp-admin, checkout, søgning – alt uden page cache

Browser cache: styret af headere

Browser cache styres af de headere, serveren sender med hver fil. Cache-Control: max-age=31536000 fortæller browseren, at filen må genbruges i et år uden at spørge igen. ETag og Last-Modified gør det muligt at spørge “er filen ændret?” og få et kort 304 Not Modified tilbage i stedet for hele filen.

Lange levetider er kun sikre, fordi WordPress versionerer filnavne: Et tema eller plugin tilføjer typisk ?ver= med et versionsnummer, og cache-plugins laver nye filnavne, når de samler eller minimerer filer. En ny udgave får dermed en ny URL, og browseren henter den automatisk.

Page cache: hele siden færdig

Page cache gemmer den færdige HTML-side, så næste anonyme besøgende får den direkte uden PHP og database. Det er det lag, der flytter TTFB mest. På en LiteSpeed-server håndteres det af webserveren selv via LiteSpeed Cache-pluginnet.

Page cache skal bevidst springes over for indhold, der er personligt:

• indloggede brugere og wp-admin;
• kurv, checkout og “Min konto” i WooCommerce;
• sider, der afhænger af cookies, for eksempel valuta- eller sprogvalg.

Får forkerte personer forkert indhold, er det næsten altid en undtagelse, der mangler. Se guiden om cache-undtagelser i LiteSpeed.

Object cache: databasen i hukommelsen

WordPress har altid en object cache, men som standard lever den kun i den enkelte request og glemmes bagefter. En vedvarende object cache med Redis eller Memcached gemmer svarene i serverens hukommelse på tværs af requests, så den samme forespørgsel ikke skal køres igen og igen.

Det mærkes ikke på en anonym forside, der allerede kommer fra page cache, men det mærkes i wp-admin, i checkout og i søgninger. Hos Hostious understøttes Redis object cache fra WP StartUp og skal aktiveres pr. site. Opsætningen er beskrevet i guiden om Redis i LiteSpeed Cache.

Sådan spiller de sammen

Lagene konkurrerer ikke – de dækker hinandens blinde vinkler. En anonym dansk besøgende får HTML fra page cachen og statiske filer fra browser- eller CDN-laget. En kunde i checkout rammer PHP uden page cache, og her bærer object cachen databasearbejdet.

Deraf følger arbejdsdelingen på et sundt site med primært danske besøgende: Page cache og object cache på serveren er fundamentet, browser cache-headere følger med cache-pluginnet, og et CDN er et tilvalg, hvis publikum er internationalt eller trafikken svinger meget. Den overvejelse står i guiden om Cloudflare APO og Cloudflare vs. QUIC.cloud.

Bag de fire lag findes desuden PHP’s egen OPcache, som gemmer den kompilerede PHP-kode i hukommelsen. Den er slået til på de fleste moderne servere og kræver normalt ingen indsats fra dig, men den forklarer, hvorfor en kodeændring på serveren nogle gange først slår igennem efter en genstart af PHP.

Ryd lagene i den rigtige rækkefølge

Når du har ændret noget, skal lagene ryddes indefra og ud. Ellers kan et ydre lag nå at hente en gammel udgave fra et indre lag og gemme den igen.

1. Object cache – kun nødvendigt, hvis du har ændret indstillinger eller data direkte i databasen, eller hvis et plugin opfører sig mærkeligt efter en opdatering.
2. Page cache på serveren – efter ændringer i indhold, tema eller plugins.
3. CDN-cache – efter page cachen, så CDN’et henter den nye udgave.
4. Browseren – test i et privat vindue. Besøgendes browsere får nye filer automatisk, når filnavnet er versioneret.

Ryd ikke alt “for en sikkerheds skyld” flere gange om dagen. Hver fuld rydning betyder, at de næste besøgende rammer en kold cache, og at serveren skal bygge alle sider op på ny. Ryd målrettet det lag og de sider, ændringen gælder.

Fejlfinding: hvilket lag driller?

• “Jeg ser gammelt indhold”: Følg lagene indefra og ud – ryd server-cache først, derefter CDN, og test i et privat vindue for at udelukke browserlaget. Se LiteSpeed- eller Cloudflare-purge-guiden.
• “Cachen rammer ikke”: Læs headerne – x-litespeed-cache for serverlaget og cf-cache-status for CDN-laget. Hit-raten som helhed har sin egen guide.
• “Forkert indhold til forkert person”: Persondata er havnet i page- eller CDN-cache – se guiden om cache af personligt indhold.
• “Hurtig forside, tungt admin”: Der mangler typisk et vedvarende object cache-lag – se Redis-guiden.

Et hurtigt tjek fra kommandolinjen viser headerne for både server- og CDN-laget:

curl -sI https://ditdomæne.dk/ | grep -i -E "x-litespeed-cache|cf-cache-status|cache-control|age"

Kør kommandoen to gange. Anden gang skal en side, der må caches, vise et hit.

Verifikation

Dit cache-setup er komplet, når du kan svare ja til fire spørgsmål med målinger:

1. Får anonyme besøgende page cache-hit? (header-tjek)
2. Får gengangere statiske filer fra cache eller 304? (Netværk-fanen)
3. Bærer object cachen de dynamiske sider? (hit-rate i pluginnet eller Redis-statistik)
4. Ryddes lagene i rigtig rækkefølge ved opdateringer? (en testrettelse er synlig med det samme)

Kan du svare ja fire gange, er “ryd cachen” ikke længere et mysterium, men en præcis handling på et præcist lag.

Læs også

• Hub: WordPress performance og cache
• Hvad er cache? Lagene bag et hurtigt WordPress-site
• Cache-hit ratio: hvorfor cachen ikke rammer
• Object cache med Redis eller Memcached i LiteSpeed Cache
• Høj TTFB i WordPress
• WordPress hosting hos Hostious – LiteSpeed og NVMe, Redis object cache fra WP StartUp

Ofte stillede spørgsmål om cache-lagene

Hvilket lag giver størst gevinst?

Page cache – den forvandler hver anonym sidevisning fra PHP-arbejde til fillevering. Derefter object cache for de dynamiske sider. CDN og browser cache finjusterer oplevelsen; de to serverlag bærer den.

Behøver jeg alle fire lag?

Page cache, object cache og browser cache: ja, hvis din hosting giver adgang til dem. CDN eller edge-cache: især ved internationalt publikum eller særlige belastningsmønstre. Mangler du ét lag, er det oftest object cache.

Rydder „Purge All“ alle fire lag?

Nej – typisk kun serverlagene og CDN’et, hvis integrationen er sat op. Browserlaget kan du ikke rydde hos besøgende; det håndteres med versionerede filnavne, så nye udgaver får nye URL’er.

Hvorfor hjælper object cache ikke på min forside?

Fordi forsiden typisk allerede kommer fra page cache, så WordPress og databasen slet ikke bliver spurgt. Object cachen gør en forskel på de sider, der ikke kan caches, som wp-admin, kurv og checkout.