Cache-undtagelser i LiteSpeed: sider, cookies og roller

Kort svar: Nogle sider må aldrig caches offentligt: alt med persondata, formularer med engangstokens og sider med indhold, der skifter pr. besøgende. I LiteSpeed Cache undtager du præcist – pr. URI, query string, cookie, brugerrolle, kategori, tag eller user agent – under fanen Excludes i cache-indstillingerne. Kunsten er at undtage smalt: en undtagelse for meget koster fart på hele sitet, en for lidt viser forkert indhold. Verificér altid med cache-headerne bagefter.

Fagligt gennemgået: 2. oktober 2026

Cache-undtagelser er der, hvor hastighedsopsætning bliver håndværk: WooCommerce-siderne klarer LiteSpeed Cache selv, men kampagnesider med nedtælling, medlemsområder, formularer og landingssider med personaliseret indhold er dit ansvar. Denne guide viser undtagelsestyperne, hvornår hver især er den rigtige – og hvornår du slet ikke skal undtage, men bruge privat cache, ESI eller en kortere TTL i stedet.

Menupunkternes navne og placering kan variere mellem versioner af LiteSpeed Cache. Felterne nedenfor findes i pluginnets cache-indstillinger, typisk på fanerne Excludes og Cache.

Hvad skal undtages – og hvad skal ikke

Skal undtages: sider med persondata eller sessionsindhold ud over WooCommerce-automatikken – fx egne “min side”-løsninger – formularer med engangstokens (nonce), der udløber i cachet HTML, sider med tidsafhængigt indhold (nedtællinger, “kun i dag”-priser) og medlemsindhold bag login uden privat cache.

Skal ikke undtages: almindelige sider “for en sikkerheds skyld”. En kontaktformular med standardopsætning virker fint på cachede sider, og roterende indhold, der gerne må være ens i cache-levetiden, er ingen grund til undtagelse – sæt hellere kortere TTL på den ene side.

Før du ændrer noget: Notér de nuværende værdier i Excludes-felterne, eller eksportér pluginnets indstillinger, så du kan rulle tilbage. Tilføj én undtagelse ad gangen, ryd cachen, og test både den undtagne side og en almindelig side bagefter. En for bred linje kan stille og roligt slå cachen fra på store dele af sitet.

1. Kortlæg de dynamiske sider

Lav en liste over sider, hvor indholdet afhænger af, hvem der ser det, eller hvornår. Gennemgå medlemsplugins, bookingsystemer, formularplugins og kampagnesider. For hver side skal du kunne svare på: Er det hele siden, der er personlig – eller kun en lille del? Er det tid, bruger eller session, der ændrer indholdet? Svaret afgør, hvilken af værktøjerne nedenfor der er den rigtige.

2. Vælg den smalleste undtagelse

Type	Felt i LiteSpeed Cache	Brug den til
URI	Do Not Cache URIs	Konkrete sider eller stier – fx /medlem/ eller /kampagne-live/
Query string	Do Not Cache Query Strings	Parametre der ændrer indholdet – fx egne filtre; værdien er ligegyldig, navnet tæller
Kategori og tag	Do Not Cache Categories / Tags	Indlæg i en bestemt kategori eller med et bestemt tag (slug, én pr. linje)
Cookie	Do Not Cache Cookies	Besøgende i en særlig tilstand – fx et medlemsplugins cookie
User agent	Do Not Cache User Agents	Særlige klienter, fx et overvågningsværktøj, der skal se en frisk side
Rolle	Do Not Cache Roles	Hele brugerroller – fx shop_manager under test

Sådan matcher URI-feltet: Ifølge LiteSpeeds dokumentation er udgangspunktet et delvist match – en linje som /kampagne rammer alle URI’er, der indeholder strengen, også /kampagne-2026/ og /blog/om-kampagne/. Brug ^ foran for at matche fra starten af stien og $ til sidst for et præcist match:

/kampagne-live/$
^/medlem/

Den første linje rammer kun præcis den side. Den anden rammer alt under /medlem/, men ikke en artikel, der bare har ordet “medlem” i slug’en.

Cookie-feltet virker sådan, at en side ikke caches, hvis en af de listede cookies findes i requesten. Det er effektivt – men vælg en cookie, der kun sættes for de relevante besøgende. En cookie, som alle får ved første besøg, slår cachen fra for hele sitet.

Husk også forskellen på “undtag fra cache” og “undtag fra optimering”: går CSS eller JavaScript i stykker på én side, er det optimeringsundtagelserne under sideoptimeringens Tuning-indstillinger, du skal bruge – ikke cache-undtagelser. Se guiden til JavaScript efter defer og delay.

3. Brug kortere TTL i stedet for undtagelse

Mange sider behøver ikke undtages – de skal bare fornyes oftere. LiteSpeed Cache lader dig give enkelte stier deres egen levetid i feltet Force Cache URIs ved at skrive TTL i sekunder efter stien:

/tilbud-i-dag/$ 300

Her caches siden i fem minutter i stedet for standardlevetiden (som er en uge, 604800 sekunder, i pluginnets standardopsætning). Det er ofte det bedste kompromis for nedtællinger og daglige tilbud: siden er hurtig for næsten alle, og indholdet er aldrig mere end få minutter gammelt. Bemærk, at Force Cache URIs også tvinger caching af stien – brug det kun til sider, der må være ens for alle.

4. Undtag én side direkte fra editoren

For enkeltsider er der en enklere vej end URI-feltet: LiteSpeed Options-boksen i WordPress-editoren har en indstilling, “Disable Cache”, som undtager netop det indlæg eller den side. Fordelen er, at undtagelsen følger indholdet, også hvis slug’en ændres. Ulempen er, at den er usynlig i den centrale liste – notér den derfor i din dokumentation.

5. Til udviklere: undtag fra koden

Bygger du selv funktionen, kan koden fortælle LiteSpeed Cache, at det aktuelle svar ikke må caches, skal caches privat eller skal have en bestemt TTL. LiteSpeeds API har hooks til netop det:

// Svaret må ikke caches (årsagen vises i debugloggen)
do_action( 'litespeed_control_set_nocache', 'personligt medlemsindhold' );

// Svaret må kun caches privat for den aktuelle bruger
do_action( 'litespeed_control_set_private', 'brugerspecifik side' );

// Svaret caches i 300 sekunder
do_action( 'litespeed_control_set_ttl', 300, 'kortlivet tilbud' );

Det er den mest præcise løsning, fordi beslutningen træffes præcis dér, hvor koden ved, om indholdet er personligt. Kald hooket, før output sendes.

Tjek, at undtagelsen virker

Headeren x-litespeed-cache-control viser sidens cache-beslutning, og x-litespeed-cache viser hit eller miss. Test som anonym besøgende – i et privat vindue eller med curl:

curl -sI https://ditdomæne.dk/kampagne-live/ | grep -i x-litespeed
curl -sI https://ditdomæne.dk/ | grep -i x-litespeed

Kør hver kommando to gange. Den undtagne side skal melde no-cache hver gang, mens den almindelige side skal gå fra miss til hit. Hele læsningen af headerne står i header-guiden – den er også værktøjet, når problemet er det omvendte: en side, der burde caches, men ikke bliver det, fordi en undtagelse rammer for bredt.

Alternativet: ESI og AJAX

Før du undtager en hel side, så spørg: er det hele siden, der er dynamisk – eller kun en stump? En nedtæller, et navn eller en kurvstatus kan serveres dynamisk i en ellers cachet side med ESI (på en LiteSpeed-server) eller et lille AJAX-kald. Så beholder du cache-gevinsten på resten af siden; fremgangsmåden er beskrevet i WooCommerce-guiden. Undtagelser er til sider, hvor alt er personligt – stumper klares smartere.

Mellemvejen er privat cache: siden caches pr. bruger i stedet for at blive genereret forfra hver gang. Det passer til medlemsområder, hvor den samme bruger ser de samme sider flere gange. Stier, der kun må caches privat, kan angives i feltet Private Cached URIs.

Typiske fejl

• For bredt URI-mønster: /konto uden ^ og $ rammer også /blog/saadan-opretter-du-en-konto/. Brug ankre.
• Cookie-undtagelse, der rammer alle: Samtykke- og statistikcookies sættes for næsten alle besøgende. Undtager du på dem, er cachen reelt slået fra.
• Rolle-undtagelser, der bliver stående: En rolle, der blev undtaget under en test, bliver ofte glemt. Det gør ikke skade for gæster, men giver forkert indtryk af sitets hastighed, når du selv er logget ind.
• Undtagelse i stedet for fejlrettelse: Viser en side forkert indhold, fordi et plugin skriver personlige data ud for gæster, er undtagelsen et plaster. Den rigtige løsning er at hente stumpen dynamisk.

Verifikation

Undtagelserne er korrekte, når de følsomme sider viser no-cache i headerne ved hvert besøg, resten af sitet stadig får cache-hit, og listen over undtagelser er kort nok til at kunne forklares på ét minut. Gennemgå listen halvårligt: undtagelser fra nedlagte kampagner og slettede plugins har det med at blive stående – og hver unødvendig linje koster cache-hit-rate. Dokumentér hvorfor for hver linje, så oprydningen er ufarlig. Hvordan du måler, om cachen rammer, står i guiden om cache-hit ratio.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• LiteSpeed cacher ikke siden: læs headerne
• LiteSpeed Cache til WooCommerce
• LiteSpeed viser gammelt indhold
• LiteSpeed Cache-indstillinger
• Hvad er cookies? Sådan virker cookies på en hjemmeside
• WordPress hosting hos Hostious – LiteSpeed-servere som standard, ikke som tilkøb

Ofte stillede spørgsmål om cache-undtagelser

Skal jeg undtage kurv og checkout manuelt?

Nej – med WooCommerce aktivt håndterer LiteSpeed Cache det automatisk. Manuelle undtagelser er til dine egne dynamiske sider, som ingen automatik kender.

Hvorfor virker min formular kun nogle gange?

Klassisk nonce-problem: formularens engangstoken udløber, mens siden ligger i cache, og indsendelser afvises. Løsning: undtag siden, sæt kortere TTL end token-levetiden – eller brug en formularløsning, der henter token via AJAX.

Koster undtagelser på hastigheden?

Kun på de undtagne sider – de leveres af u-cachet PHP ved hvert besøg. Derfor undtager man smalt: hver side på listen er en side, hvor serveren arbejder forfra hver gang.

Hvad er forskellen på privat cache og ingen cache?

Ingen cache betyder, at siden genereres forfra ved hvert besøg. Privat cache gemmer en kopi pr. bruger, så den samme bruger får siden hurtigt næste gang, uden at andre kan se den. Privat cache passer til personlige sider, der ses flere gange; ingen cache til sider, der skal være helt friske hver gang.