Hvad er cache? Lagene bag et hurtigt WordPress-site

Kort svar: Cache er et midlertidigt lager af færdige svar, så det samme arbejde ikke gøres om for hver besøgende. I stedet for at bygge en WordPress-side fra bunden med PHP, database og tema gemmes resultatet og genbruges. Det er en af de største hastighedsfaktorer for WordPress: en cachet side leveres på millisekunder, en ucachet kan tage sekunder. Prisen er risikoen for forældet indhold, så god opsætning handler om levetider, tømning (purge) og undtagelser for kurv og login.

Fagligt gennemgået: 2. oktober 2026

Cache er et af de ord, der dukker op i alle hastighedsguides, men sjældent bliver forklaret ordentligt. Her får du lagene forklaret ét for ét, så du ved, hvilket lag der gør hvad – og hvilket du skal tømme, når noget ser forkert ud.

Hvorfor cache er nødvendig

Hver ucachet WordPress-visning er et lille byggeprojekt: PHP starter, spørger databasen måske 50–100 gange, kører tema og plugins og samler HTML’en. Det er fint for én besøgende, men det er identisk arbejde gentaget tusind gange for tusind besøgende, der får nøjagtig samme side.

Cache flytter arbejdet fra „hver gang“ til „første gang“: siden bygges én gang, gemmes, og de næste får kopien. Deraf også begrebet cache hit ratio – andelen af besøg, der rammer en gemt kopi. Det er det ærligste mål for, om opsætningen virker.

De fire lag

Lag	Hvor det bor	Hvad det gemmer
Browsercache	Den besøgendes egen enhed	Billeder, CSS og JavaScript ved gentagne besøg
Kant/CDN-cache	Servere tæt på den besøgende	Statiske filer – og med fx QUIC.cloud eller en Cloudflare-regel også HTML
Servercache (sidecache)	Din webserver, fx LiteSpeed	Færdigbyggede HTML-sider – det store spring
Objektcache	RAM på serveren, fx Redis	Databasesvar – hjælper også de dynamiske sider

Lagene løser hver sit. Browser- og kantcache sparer afstand, servercache sparer byggearbejdet, og objektcache sparer databasen – også på sider som kurv og wp-admin, der aldrig må sidecaches. Hele arkitekturen med beslutningstræ står i guiden til cache-typer.

Det skjulte lag: OPcache

Ud over de fire lag har PHP sit eget: OPcache. Det gemmer den oversatte version af PHP-filerne i hukommelsen, så serveren ikke skal læse og fortolke WordPress’ kode forfra ved hver forespørgsel. OPcache er slået til som standard i moderne PHP-installationer og arbejder helt i baggrunden.

OPcache gemmer kode, ikke indhold. Retter du en tekst eller en pris, er det derfor aldrig OPcache, der viser den gamle version. Det bliver først relevant, hvis du redigerer PHP-filer direkte på serveren og ændringen ikke slår igennem – så kan en genstart af PHP eller en OPcache-nulstilling være nødvendig.

Hvad betyder det for dit site?

Tre håndgreb dækker det meste:

• Brug servercache. På LiteSpeed-hosting som Hostious’ WordPress hosting er LiteSpeed Cache-pluginnet den naturlige motor: aktiv sidecache på alt offentligt indhold.
• Undtag det personlige. Kurv, checkout og login må aldrig deles mellem besøgende. Skabelonerne står i guiden til cache-undtagelser.
• Mål. En hit ratio under omkring 80 % på offentlige sider betyder som regel, at noget udsætter cachen: for korte levetider, unødige cookies eller hyppige tømninger.

Har du mange produkter, søgninger eller et travlt wp-admin, er objektcache næste skridt. Redis object cache understøttes fra WP StartUp og skal aktiveres pr. site – se guiden til Redis i LiteSpeed Cache.

Sådan ser du, om en side kom fra cachen

Cache er usynlig for besøgende, men ikke for dig. Hvert svar fra serveren har headere, og de fleste cachelag skriver deres status i dem:

• LiteSpeed skriver x-litespeed-cache: hit eller miss.
• Cloudflare skriver cf-cache-status: HIT, MISS eller DYNAMIC.
• Mange cacheplugins skriver en kommentar nederst i HTML-koden („Cached by … at …“).
• age viser, hvor mange sekunder den cachede kopi har ligget.

Du kan se headerne for én side med curl. Kør kommandoen to gange, og du ser skiftet fra miss til hit:

curl -sI https://dinside.dk/ | grep -iE "x-litespeed-cache|cf-cache-status|cache-control|age"

cache-control og expires fortæller, hvor længe browseren må gemme filen. max-age=31536000 på billeder og CSS betyder et år. Det er rigtigt for filer med et versionsnummer i navnet og forkert for HTML, som bør have en kort levetid eller no-cache, så nyt indhold kommer igennem.

Ser du DYNAMIC fra Cloudflare på alle sider, cacher Cloudflare kun statiske filer, og HTML går stadig til din server. Det er standard og ofte det rigtige for en webshop, men værd at vide, hvis du tror, at „Cloudflare cacher det hele“. Se også hvad DYNAMIC, BYPASS og MISS betyder.

Når cachen viser gammelt indhold – og hvilket lag der har det

„Jeg har rettet, men det er ikke ændret“ er den hyppigste cachesag. Løsningen er at tømme lagene i den rigtige rækkefølge – indefra og ud:

1. Objektcachen (Redis), hvis ændringen er data som pris eller lager.
2. Servercachen (LiteSpeed eller dit cacheplugin), som holder HTML’en.
3. CDN’et (fx Cloudflare → Purge), hvis der er et.
4. Browseren – men ikke ved at bede kunderne rydde deres cache. Brug i stedet versionsnumre på CSS- og JavaScript-filer, så browseren ser et nyt filnavn.

Tømmer du kun browseren, ser du ændringen, men ingen andre gør. Tømmer du kun serveren, mens CDN’et holder på en kopi, ser ingen den. Et privat vindue er den hurtige test af, om det er din egen browser, der holder på det gamle.

Cache på webshops og andre dynamiske sider

En WooCommerce-butik er en blanding af sider, der må caches, og sider, der aldrig må. Produkt- og kategorisider er ens for alle og kan caches. Kurv, checkout og Min konto viser personlige data og skal altid bygges frisk.

Skillelinjen styres typisk af cookies. Når en kunde lægger noget i kurven, sætter WooCommerce cookies, og en korrekt opsat sidecache leverer derefter personligt indhold til netop den kunde. Går det galt, ser kunder hinandens kurv eller navn – en af de alvorligste cachefejl, beskrevet i guiden om kunder, der ser hinandens kurv.

LiteSpeed Cache har indbyggede regler for WooCommerce og kan desuden udskære små personlige elementer, fx kurvikonet, så resten af siden stadig kommer fra cachen. Det er en af grundene til, at én motor, der kender serveren, er lettere at styre end flere plugins oven på hinanden.

Fornuftige levetider og forvarmning

• HTML (sidecache): lang levetid (timer eller dage) kombineret med automatisk tømning, når indhold gemmes. Levetiden er kun et sikkerhedsnet; tømningen holder indholdet friskt.
• Billeder, CSS og JavaScript: et år, hvis filnavnet ændrer sig ved hver ny version, som det gør i moderne temaer og cacheplugins. Ellers en uge.
• Objektcache: styres af WordPress selv; transients har egne udløb. Redis bør have hukommelse nok til, at intet smides ud før tid – tjek „evicted keys“ i Redis’ statistik.
• Forvarmning: efter en fuld tømning er alle sider kolde, og den første besøgende på hver side betaler byggetiden. En crawler, der besøger sitemappet lige efter tømning, fylder cachen igen, før kunderne kommer. LiteSpeed Cache har en indbygget crawler til netop det – se guiden til LiteSpeed-crawleren.

Typiske fejl

• To sidecache-plugins aktive på samme tid, så ingen ved, hvilket lag der leverer siden.
• Sidecache slået til på kurv, checkout eller konto uden undtagelser.
• Et plugin eller et tredjepartsscript, der sætter en cookie på alle besøgende, så cachen omgås på hver side.
• Fuld tømning af hele cachen ved hver lille ændring, så hit ratio aldrig når at blive høj.
• HTML med lang browsercache, så besøgende ser en gammel forside, selv når servercachen er tømt.

Læs også

• Ordbog: Hosting-ordbogen
• Hub: WordPress performance og cache
• Page cache, object cache og browser cache: hvem gør hvad?
• Cache hit ratio: hvorfor cachen ikke rammer
• LiteSpeed viser gammelt indhold efter en opdatering
• WordPress hosting hos Hostious – LiteSpeed, NVMe og Redis object cache fra WP StartUp

Ofte stillede spørgsmål om cache

Hvorfor ser jeg gamle priser efter en opdatering?

Et cachelag udleverer stadig den gamle kopi. Tøm cachen på serveren og eventuelt i CDN’et efter ændringen, og sæt automatisk tømning op ved opdateringer, så det ikke afhænger af, at nogen husker det.

Kan cache ødelægge min webshop?

Forkert opsætning kan. Klassikeren er sidecache på kurv eller konto, så kunder ser hinandens indhold. Med korrekte undtagelser er cache tværtimod det, der holder shoppen hurtig på travle dage.

Er flere cache-plugins bedre end ét?

Nej. To sidecaches oven på hinanden giver dobbelt tømningskompleksitet og sværere fejlfinding. Vælg én motor, der passer til din server, og lad resten af værktøjerne holde sig til deres egne opgaver.

Jeg har rettet en side, men ændringen vises ikke. Hvilken cache skal jeg tømme?

Tøm indefra og ud: objektcache (ved dataændringer), servercache (HTML), CDN (fx Cloudflare) og til sidst browseren – og test i et privat vindue. Tømmer du kun browseren, ser kun du ændringen; tømmer du kun serveren bag et CDN, ser ingen den.

Hvad betyder cf-cache-status: DYNAMIC?

At Cloudflare ikke cacher den side, men sender forespørgslen videre til din server. Det er standard for HTML, fordi Cloudflare kun cacher statiske filer, medmindre du sætter en cacheregel op for sider.