Trin-for-trin
Mål TTFB i WebPageTest og PageSpeed Insights for at se om problemet er stabilt på tværs af sider.
Aktivér page cache på serveren og verificér cache-hit i response headers.
Opsæt edge cache/CDN for offentlige sider og justér cache-control for HTML og assets.
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
- Mål TTFB (WebPageTest/PSI) og se om det er konsekvent højt
- Slå page cache til (server/LiteSpeed/omvendt proxy)
- Brug CDN/edge cache hvis det giver mening
- 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-age på ikke-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
- Sammenlign TTFB før/efter på samme URL og samme testlokation.
- Brug repeat view i WebPageTest: hvis TTFB stadig er høj, er problemet ofte origin - ikke browsercache.
- Inspicér response-headers:
age,x-cache,cf-cache-status(afhænger af CDN) - du skal kunne se om du rammer edge. - 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
- Ordbog: CDN, Cache-Control, ETag
- Guide: Fjern render-blocking (hvis TTFB er ok men LCP er dårlig)
Relaterede guides
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
2026-03-30Mange 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-02Læ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-01Hvis 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-30Læ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-27Fø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-26Fø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.