Cache-hit ratio: hvorfor cachen ikke rammer

Kort svar: En cache er kun så god som sin hit-rate – andelen af forespørgsler, der får det hurtige, cachede svar. De fire klassiske hit-rate-dræbere er URL-parametre (især UTM- og klik-id’er), der deler cachen op i tusind varianter; cookies, der udløser unødigt bypass; for kort cache-levetid (TTL); og purge-rutiner, der rydder alt for ofte. Mål hit-raten med headere og accesslog, luk hullerne ét ad gangen – og mål igen.

Fagligt gennemgået: 2. oktober 2026

„Vi har cache“ og „vores besøgende får cache“ er to forskellige udsagn. Et site kan have en perfekt opsætning på papiret og alligevel servere halvdelen af trafikken uden cache – fordi kampagnelinks, cookies og ivrige purges stille udhuler hit-raten. Denne guide gør hit-raten målbar og lukker de typiske huller.

Guiden handler om sidecachen (hele HTML-sider) i fx LiteSpeed Cache eller Cloudflare. Forskellen på sidecache, object cache og browsercache står i guiden om cache-typerne.

Før du ændrer noget: Mål hit-raten, før du retter, så du har et udgangspunkt. Skriv ned, hvilke bypass-regler og purge-indstillinger der findes i dag. Fjern aldrig undtagelser for kurv, checkout, konto og wp-admin for at hæve raten – de skal bypasse.

Hvad hit-raten egentlig måler

Hit-raten er antal HIT divideret med alle forespørgsler, der kunne være cachet. Nævneren er det vigtige: tæller du wp-admin, REST-kald, checkout og indloggede brugere med, ser raten dårligere ud, end den er. Mål derfor på offentlige sidevisninger fra anonyme besøgende – det er dem, cachen skal tjene.

Headerne fortæller, hvad der skete med den enkelte forespørgsel:

Header	Værdi	Betydning
x-litespeed-cache	hit	Siden kom fra LiteSpeeds sidecache
x-litespeed-cache	miss	Siden blev genereret af PHP og gemt til næste gang
x-litespeed-cache	hit,private	Privat cache pr. bruger (fx ESI eller indlogget)
cf-cache-status	HIT	Cloudflare leverede fra kantens cache
cf-cache-status	MISS / EXPIRED	Ikke i cache, eller udløbet – hentet fra origin
cf-cache-status	BYPASS / DYNAMIC	Bevidst ikke cachet, eller ikke omfattet af cache-regler

Betydningen af Cloudflares værdier er uddybet i guiden om CF-Cache-Status.

1. Mål hit-raten

Stikprøven: hent dine vigtigste sider to gange i træk og læs cache-headeren – andet besøg skal være HIT. Med curl ser du kun headerne og undgår cookies fra din egen browser:

curl -sI https://ditdomæne.dk/ | grep -i -E "x-litespeed-cache|cf-cache-status"
curl -sI "https://ditdomæne.dk/?utm_source=nyhedsbrev" | grep -i -E "x-litespeed-cache|cf-cache-status"

Systematisk: træk en times accesslog og tæl HIT mod MISS og BYPASS. Logformatet varierer mellem servere, så en optælling kræver, at cache-status er med i loggen. På CDN-niveau viser Cloudflares analyse andelen af forespørgsler, der blev leveret fra cache. Gør du det samme før og efter hver ændring, kan du se, hvad der virkede:

Som tommelfingerregel bør et indholdssite med stabil trafik nå en høj hit-rate på offentlige sidevisninger – ofte et godt stykke over 80 %. Webshops ligger naturligt lavere, fordi kurv, checkout og konto bypasser med vilje. Vigtigere end det præcise tal er udviklingen: falder raten efter en ændring, har du fundet et hul.

2. Dræber 1: URL-parametre

Cachen nøgler på URL’en – og for cachen er ?utm_source=facebook en helt anden side end uden. En nyhedsbrevsudsendelse med unikke parametre kan dermed sende tusindvis af besøgende uden om cachen på én gang: præcis når belastningen er størst.

Løsningen er at få cachen til at ignorere rene trackingparametre (utm_*, gclid, fbclid og lignende), så alle varianter rammer samme kopi:

• LiteSpeed Cache: indstillingen Drop Query String fjerner de angivne parametre fra cache-nøglen. Standardlisten dækker de mest udbredte trackere; tilføj dem, dine egne værktøjer bruger.
• Cloudflare: i Cache Rules kan cache-nøglen sættes til at ignorere query strings, men ifølge Cloudflares dokumentation kun på Enterprise og pay-as-you-go. På andre planer kan en URL-omskrivningsregel fjerne trackingparametre, før forespørgslen når cachen.
• FlyingPress: ignorerer kendte trackingparametre i sin cache.

Analytics påvirkes ikke, når parametrene kun fjernes fra cache-nøglen: de står stadig i browserens adresselinje, og analysescriptet læser dem dér. Pas på med at ignorere alle query strings: søgning (?s=), filtre i en webshop og sideskift ændrer faktisk indholdet og skal give hver sin side.

3. Dræber 2: cookies og bypass-regler

Cache-bypass på cookies er nødvendigt for login og kurv – men hver ekstra bypass-cookie æder hit-rate. De typiske synder:

• et samtykke- eller A/B-testplugin, der sætter en cookie på alle besøgende og dermed – afhængigt af regelsættet – sender alle uden om cachen;
• gamle, håndbyggede regler, der bypasser på cookies fra plugins, der for længst er slettet;
• en webshop, der sætter kurv-cookies, før den besøgende har lagt noget i kurven.

Gennemgå bypass-reglerne, og test som helt ny besøgende i et privat vindue: får du HIT på andet besøg – også efter at have accepteret cookies? Hvis ikke, er det dér, hullet er. Undtagelser i LiteSpeed er gennemgået i guiden om cache-undtagelser.

4. Dræber 3: for kort TTL

Udløber cachen hvert 10. minut, genopbygges den hele dagen – og første besøg efter hvert udløb betaler prisen. Sæt en lang TTL (timer eller døgn) på offentlige sider, og lad purge-mekanismen håndtere friskheden: cachen skal udløbe, fordi indholdet ændrede sig, ikke fordi klokken gik. Kortere TTL giver kun mening for sider med indhold, der ændrer sig uden en redigering i WordPress, fx en side med lagerstatus fra et eksternt system.

5. Dræber 4: for ivrig purge

„Ryd alt ved hver ændring“ er den stille dræber – én produktopdatering behøver ikke rydde hele sitets cache. Brug målrettet automatisk purge, der kun rydder de berørte URL’er (siden selv, forsiden og relevante kategorier), og gem totalrydninger til deploys og temaskift. Tjek også, om et plugin eller en planlagt opgave rydder hele cachen med faste mellemrum. Se guiden om LiteSpeed og gammelt indhold og guiden om purge i Cloudflare.

6. Tjek varianter, der deler cachen op

Ud over parametre og cookies kan cachen være delt op i varianter, som ikke er nødvendige. Hver variant skal varmes op for sig, og hit-raten falder:

• Mobil og desktop: en separat mobilcache er kun nødvendig, hvis temaet leverer forskellig HTML til mobil. Med et responsivt tema kan én fælles cache bruges.
• Sprog og valuta: varianter pr. sprog eller valuta er nødvendige, hvis indholdet ændres – men bør bygge på URL’en (fx /en/) frem for cookies, hvor det er muligt.
• ESI og private blokke: LiteSpeeds ESI kan cache siden offentligt og kun hente fx kurven privat. Det hjælper webshops, men forkert brugt kan det give mange små, private svar.

Verificér hit-raten

Hit-raten er sund, når:

• andet besøg på enhver offentlig side giver HIT – også med et UTM-pyntet kampagnelink og efter cookie-accept;
• accessloggens HIT-andel på anonyme sidevisninger ligger stabilt højt;
• TTFB på tilfældige sider er konsekvent lav (se guiden om høj TTFB).

Mål igen efter kampagneudsendelser – det er dér, parameterhullet viser sig – og efter nye plugins, der kan have medbragt nye cookies eller purge-vaner.

Læs også

• Hub: WordPress performance og cache
• Page cache, object cache og browser cache: hvem gør hvad?
• LiteSpeed Cache cacher ikke siden
• Hvorfor viser CF-Cache-Status DYNAMIC, BYPASS eller MISS?
• WordPress hosting hos Hostious – LiteSpeed som standard; Redis object cache understøttes fra WP StartUp

Ofte stillede spørgsmål om cache-hit ratio

Hvad er en god hit-rate?

Det afhænger af sitet. Et indholdssite med stabil trafik bør nå en høj rate på offentlige sidevisninger, mens webshops ligger lavere, fordi kurv, checkout og konto bypasser med vilje – og det er korrekt. Døm aldrig raten uden at vide, hvor meget af trafikken der skal bypasse.

Mister jeg tracking ved at ignorere UTM-parametre?

Nej – parametrene fjernes ikke fra URL’en i browseren, de udelades kun af cache-nøglen. Analytics læser dem i browseren som altid; forskellen er, at alle kampagnebesøg nu får den hurtige, cachede side.

Hjælper en cache-warmer eller crawler på hit-raten?

Ja – den fylder cachen, før besøgende kommer, så færre rammer et koldt MISS. Men den maskerer også hullerne: ret parametre, cookies og purge først, og lad crawleren, fx LiteSpeeds, være prikken over i’et.

Hvorfor er hit-raten lav i min webshop?

Ofte fordi kurv- eller sessionscookies sættes på alle besøgende, også før de har lagt noget i kurven, og cachen derfor bypasser. Tjek, hvornår cookien sættes, og brug privat cache eller ESI til kurven, så resten af siden kan caches.