Hurtigere hjemmeside hjælp til en langsom hjemmeside

Få edge cache-hit på HTML

Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.

Skrevet af Kim Tetzlaff

cachingttfbperformance

Trin-for-trin

  1. Vælg 1–3 offentlige URL’er og mål TTFB (first view vs repeat view) for at se om caching virker.

  2. Læs response headers (Cache-Control, Vary, Age) og identificér hvad der forhindrer caching.

  3. Fjern eller begræns cookies på offentlige pages, og ret Vary så cachen ikke fragmenteres unødigt.

  4. Sæt en enkel cache-strategi for HTML og verificér cache-hit på edge (og at indholdet stadig er korrekt).

Mange sites “har et CDN”, men deres vigtigste sider føles stadig langsomme for nye besøgende. Årsagen er ofte simpel: HTML bliver ikke cached – eller bliver cached så sjældent at hit-rate er tæt på nul.

Det giver høj TTFB, og så starter alt andet senere (CSS/JS/billeder). LCP følger ofte med.

Målet med guiden: At få cache-hit på HTML for offentlige sider (blog/guides/ordbog/landingssider) uden at servere forkert indhold til forkerte brugere.

Hvis du vil have baggrunden først, læs: Cache-Control basics og orbog: edge caching. Guiden her er workflow’et.

Før du går i gang

Du skal kunne:

  • se response headers (DevTools eller curl)
  • ændre cookies/tema/plugins eller CDN-regler (eller få en udvikler/drift til det)
  • teste én URL ad gangen (så du ved hvad der virker)

Vigtigt: Vælg en URL der bør være offentlig og ens for alle (fx et blogindlæg).

Trin 1: Mål om problemet er “first view” (og om caching gør noget)

Kør 3–5 tests og sammenlign:

  • first view (kold cache)
  • repeat view (varm browser cache)

Hvis repeat view er meget hurtigere, men first view stadig er høj TTFB, er det typisk edge/origin-laget der mangler.

Brug waterfall til at se TTFB på dokumentet (HTML).

Trin 2: Læs de tre vigtigste headers: Cache-Control, Vary og Age

Du skal ikke starte i et CDN-dashboard. Start i facts:

  • Cache-Control: må cachen overhovedet gemme HTML?
  • Vary: splitter du cachen i for mange varianter?
  • Age (hvis tilgængelig): har en shared cache en kopi?

Baggrund:

Hvis du ser Cache-Control: private eller no-store på offentlige pages, er det oplagt årsag.

Trin 3: Find det der forhindrer caching (de klassiske syndere)

Synd 1: Cookies på alle requests (også offentlige sider)

Hvis din HTML-request altid har cookies (marketing, consent, sessions), vælger mange CDNs at spille sikkert og ikke cache – eller cache pr. cookie-variant (praktisk talt 0% hit-rate).

Praktisk løsning:

  • stop unødige cookies på offentlige content-sider
  • scoping: sæt cookies kun hvor de er nødvendige (fx checkout, login, eller specifikke kampagnesider)

Synd 2: Vary er for bred eller forkert

Vary er korrekt når svaret reelt varierer. Men det er et problem når den varierer på ting der ikke ændrer HTML på content-sider.

Typiske fejl:

  • Vary: Cookie på offentlige pages
  • Vary: User-Agent uden at HTML faktisk er device-specifik
  • Vary: * (ofte en “fodfejl”)

Målet er ofte at ende med noget simpelt som Vary: Accept-Encoding for offentlige sider.

Synd 3: For lang eller utydelig redirect-kæde før den rigtige URL

Redirects koster round-trips. De kan ofte håndteres smartere på edge, men det bedste er at minimere kæder.

Se: HTTP-redirects.

Trin 4: Sæt en enkel HTML-cache-strategi (uden at overdrive)

En pragmatisk strategi for content-sites:

  • Browser: revalidate ofte (så du ikke låser brugere fast)
  • Edge: cache HTML i fx 10–60 minutter (hvis indhold er offentligt)
  • Assets (CSS/JS/fonts/billeder): lang cache hvis filnavne versioneres

Hvis du ikke har purge, så undgå dage/uger på HTML.

Trin 5: Verificér cache-hit – og verificér at indholdet stadig er korrekt

Efter ændringer:

  • tjek at Age stiger på gentagne requests (eller at CDN-cache-status viser hit)
  • tjek at to forskellige browsere uden login får samme (korrekte) HTML
  • tjek at en logget bruger ikke får cached offentlig HTML med privat indhold

Hvis du har personalisering, skal cache keys være bevidste, ellers skal de sider bypasses.

Trin 6: Når du skal længere ned i kæden (reverse proxy og origin)

Hvis edge-cache stadig ikke giver stabile hits:

Typiske fejl

  • Du “cacher” HTML, men glemmer at cookies stadig splitter alt → ingen hit-rate.
  • Du preloader/optimerer assets, men HTML er stadig langsom → LCP flytter sig næsten ikke.
  • Du sætter lang TTL på HTML uden purge → forældet indhold og mistillid.

Opsamling

Få først cache-hit på HTML på én offentlig URL. Skalér derefter til flere skabeloner.

Relateret på sitet

Relaterede guides

Forbedr TTFB med caching, edge cache og hurtigere serverrespons

2026-02-01

Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.

Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning

2026-04-02

Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.

Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering

2026-04-01

Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.

Undgå CLS fra fonts: font-display, preload og stabile fallbacks

2026-03-30

Lær at undgå layout-hop (CLS) fra webfonts med font-display, fallback-strategi og korrekt preload. Guiden er til dig der vil have pæn typografi uden at ødelægge stabilitet.

Sådan fejlsøger du LCP fra start til slut

2026-03-27

Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.

Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet

2026-03-26

Følg en praktisk guide til at finde, vurdere og udsætte tredjeparts scripts, så de ikke ødelægger LCP, INP og den samlede brugeroplevelse.

FAQ

Er HTML-cache sikkert?

Ja, hvis siden er offentlig og du er bevidst om cache keys og invalidation. Risikoen opstår når personalisering/cookies blandes ind i samme URL uden klare regler.

Skal jeg cache alt i flere dage?

Nej. Korte TTL’er på HTML kan give stor effekt. Længere TTL kræver purge/invalidation, ellers risikerer du forældet indhold.

Hvorfor hjælper browser cache ikke på first view?

Browser cache hjælper primært gentagne besøg. Edge cache/CDN kan hjælpe first view fordi svaret kan leveres tæt på brugeren.

Eksterne kilder

Reference til HTTP caching og Vary-semantik.

Næste skridt efter guiden

Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.

Se relaterede emnerLæs forklarende blogindlægTjek begreber i ordbogSe hele ordbogen (A–Å)

Om forfatteren

Kim Tetzlaff

Kim skriver og vedligeholder indhold på hurtigere-hjemmeside.dk med fokus på målelig performance, Core Web Vitals og teknisk SEO. Målet er at gøre optimering konkret: hvad der faktisk flytter tal i feltdata, og hvordan du finder den korteste vej fra symptom til fix.

Se forfatterprofil Metode og kvalitetsprincipper
Kim Tetzlaff