Hurtigere hjemmeside hjælp til en langsom hjemmeside

Forbedr TTFB med caching, edge cache og hurtigere serverrespons

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

Skrevet af Kim Tetzlaff

Trin-for-trin

  1. Mål TTFB i WebPageTest og PageSpeed Insights for at se om problemet er stabilt på tværs af sider.

  2. Aktivér page cache på serveren og verificér cache-hit i response headers.

  3. Opsæt edge cache/CDN for offentlige sider og justér cache-control for HTML og assets.

  4. Mål first view og repeat view igen og dokumentér forbedringen i TTFB.

Målet

At reducere tiden til første byte, så resten af siden kan starte tidligere.

TTFB er ofte den tidligste flaskehals i hele kæden. Hvis serveren er langsom til første byte, starter CSS, JS og billeder også senere. Derfor er TTFB-optimering ofte en af de hurtigste måder at forbedre både LCP og oplevet hastighed - men den fjerner ikke nødvendigvis tunge billeder eller render-blocking; det er ét lag i en større strategi.

Guiden her er særligt relevant for CMS-drevne sites (WordPress m.fl.), webapps med server-side rendering og alle der bruger CDN/edge. Du skal have adgang til cache-indstillinger, hosting eller CDN-dashboard.

Før du går i gang

  • Dokumentér nuværende TTFB på 3–5 kørsler (ikke én enkelt måling) - waterfall viser ventetid på dokument-requesten.
  • Tjek om svaret er personligt (cookies, geo) - så er cache sværere og du skal segmentere tests.
  • Lav ændringer i et kontrolleret vindue hvor du kan rulle tilbage, hvis cache begynder at servere forkert indhold.

Baseline: mål korrekt før du ændrer noget

Før du ændrer caching:

  • mål mindst 3–5 runs i WebPageTest eller lignende
  • sammenlign first view vs repeat view
  • notér om problemet gælder alle sider eller kun enkelte templates

Hvis TTFB kun er høj på bestemte sider, kan problemet være i den side-specifikke backend-logik.

Trin-for-trin

  1. Mål TTFB (WebPageTest/PSI) og se om det er konsekvent højt
  2. Slå page cache til (server/LiteSpeed/omvendt proxy)
  3. Brug CDN/edge cache hvis det giver mening
  4. Sæt lange cache-tider på versionerede assets

Trin 1: Identificér om problemet er origin, cache eller netværk

Se efter:

  • høj TTFB på first view, men lav på repeat view (caching hjælper allerede)
  • høj TTFB på begge (origin/server-problem)
  • stor geografisk variation (CDN/edge-problem)

Trin 2: Aktiver page cache

For offentlige sider er page cache ofte det mest effektive skridt:

  • cache HTML output
  • undgå unødvendige variationer (cookies, query-parametre)
  • verificér cache hit i headers/logs

Trin 3: Edge cache/CDN

Hvis du har brugere fra flere lokationer:

  • brug edge cache til HTML hvor sikkert
  • cache assets længe
  • hold purge-processen enkel

Trin 4: Cache-Control på assets

Versionerede CSS/JS/billeder kan normalt caches meget længe. Det reducerer belastning og gør repeat views hurtigere. Se Cache-Control basics for forskellen på HTML og hashed assets - og undgå at sætte lang max-ageikke-versionerede filer.

Trin 5: Undgå at HTML bliver “uncacheable” ved en fejl

Cookies på alle sider, Cache-Control: private uden behov, eller Vary: *-lignende mønstre kan gøre at CDN aldrig får et stabilt cache-hit. Gør offentlige GET-sider så “rene” som muligt: én cachebar repræsentation pr. URL.

Typiske fejl der holder TTFB oppe

  • HTML kan ikke caches pga. cookies på alle requests
  • for mange plugins/hooks i server-rendering
  • databasequeries uden indeks/optimering
  • ingen edge cache på offentlige sider
  • for tunge database-queries på hver request - cache skjuler symptomet; du bør stadig optimere queries på tunge templates

Sådan kontrollerer du resultatet

  1. Sammenlign TTFB før/efter på samme URL og samme testlokation.
  2. Brug repeat view i WebPageTest: hvis TTFB stadig er høj, er problemet ofte origin - ikke browsercache.
  3. Inspicér response-headers: age, x-cache, cf-cache-status (afhænger af CDN) - du skal kunne se om du rammer edge.
  4. Følg Search Console over tid; feltdata opdateres langsomt.

Praktisk checkliste før release

  • TTFB målt før/efter ændringer
  • Page cache aktiv på offentlige templates
  • Edge cache og purge-flow verificeret
  • Assets har fornuftige cache headers
  • Repeat view er mærkbart hurtigere end first view

Tjekliste

  • HTML kan caches hvor det er muligt
  • Assets har lang cache og versions-sti

Relateret

Relaterede guides

Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys

2026-03-30

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.

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

Hvor høj TTFB er et problem?

Det afhænger af kontekst, men hvis TTFB konsekvent er høj på vigtige landingssider, bør du optimere caching og backend. Sammenlign first view og repeat view for at se hvor meget cache hjælper.

Skal jeg cache HTML på et informationssite?

Typisk ja, i hvert fald for offentlige sider. Brug gerne edge cache med en fornuftig udløbstid og mulighed for purge ved opdateringer.

Hvad er forskellen på browser cache og edge cache?

Browser cache gælder den enkelte bruger. Edge cache/CDN gør at mange brugere kan få samme cached response tæt på deres lokation.

Næste skridt efter guiden

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

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.

Kim Tetzlaff