Reverse proxy og TTFB

Hvis du har en side med høj TTFB, er det fristende at konkludere: “serveren er langsom”. I praksis er det ofte mere præcist at sige: kæden før origin er uklar.

En reverse proxy (eller et CDN/edge-lag) kan både redde og ødelægge performance. Den kan give hurtige svar fra cache, komprimere tekst, terminere TLS og beskytte origin. Men den kan også introducere cache fragmentation, ekstra redirects, upstream-kø og fejl der først ses i produktion.

Kort svar: Hvis du vil forstå høj TTFB, skal du skelne mellem tre ting:

1. Netværksdelen (DNS/TLS/afstand) – se fx DNS-lookup performance og TLS-performance
2. Proxy-/edge-laget (cache, routing, komprimering, rate limits)
3. Origin (CMS, database, template-rendering, cache-miss)

Resten af artiklen giver dig et workflow du kan følge, også hvis du ikke sidder med fuld adgang til serveren.

Hvad er en reverse proxy (i praksis)?

En reverse proxy er et mellemled der står foran din applikation/origin og modtager brugernes requests først. Den kan blandt andet:

• terminere HTTPS/TLS
• route/balancere trafik til flere upstreams
• cache HTML og assets (eller i hvert fald håndtere cache-headers)
• komprimere (Brotli/gzip) og tilføje/ændre headers
• håndtere redirects og sikkerhedsregler

Hvis du har et CDN, har du i praksis også et reverse proxy-lag – bare distribueret på mange edge-noder.

Hvorfor reverse proxy-laget ofte er årsagen til høj TTFB

Det lyder kontraintuitivt: “mellemled” burde gøre det hurtigere. Det gør det også – når cachen rammer og reglerne er rigtige.

Men TTFB bliver høj når reverse proxy-laget:

• ikke kan cache (eller ikke må cache) HTML pga. cookies/varianter
• laver et cache-miss og skal hele vejen til origin (ofte langt væk)
• har upstream-kø eller connection limits (mange samtidige requests)
• laver redirects før endelig HTML (ekstra round-trips)
• har TLS/HTTP-protokol-fallback eller for mange nye forbindelser

Hvis du arbejder med LCP, er TTFB ofte en “rodsag” fordi alt discovery starter senere: CSS/JS/billeder opdages først når HTML kommer.

Debug-flow: sådan finder du laget der gør TTFB høj

1) Start i waterfall og navngiv mønsteret

Brug waterfall og kig på dokument-requesten (HTML):

• Er “Waiting/TTFB” lang på dokumentet?
• Er der redirects før endelig 200?
• Starter LCP-ressourcen først efter HTML?

Hvis ja: stop med at optimere småting før du har styr på TTFB-laget.

2) Kig på response headers (edge vs origin)

Det er her du ofte kan se om du rammer cache.

Kig efter:

• Age (viser ofte at en shared cache har en kopi)
• Cache-Control (hvad er overhovedet tilladt?)
• Vary (splitter du cachen unødigt?)
• CDN/proxy-specifikke “cache status”-headers (navne varierer)

Hvis du ser at Vary inkluderer Cookie på offentlige sider, er det et rødt flag: cachen bliver fragmenteret, og du får mange misses.

Læs baggrunden i Cache-Control basics og orbog: Vary.

3) Brug Server-Timing hvis du kan

Hvis du kontrollerer origin eller proxy-laget, er Server-Timing en af de billigste måder at stoppe gætteriet:

• db;dur=... → database er flaskehals
• app;dur=... → template/rendering
• cache;dur=... → cache-hit/miss kan tydeliggøres

Det kræver disciplin: hold metrics få og forståelige, og vær varsom med hvad du eksponerer offentligt.

Tre klassiske scenarier (og hvad du gør)

Scenario A: Edge-cache findes, men du rammer den næsten aldrig

Typiske tegn:

• Cache-Control er “konservativt” (eller private)
• Vary er bred (fx Vary: Cookie eller Vary: User-Agent)
• HTML har cookies på alle requests (også til offentlige content-sider)

Hvad du gør:

• Skeln mellem offentligt content og personligt indhold.
• Brug en bevidst HTML-strategi (fx max-age=0 i browser, men s-maxage på edge hvis sikkert).
• Ryd op i unødige cookies på rene content-sider (ellers bliver CDN nødt til at spille sikkert).

Se også edge caching og Cache-Control basics.

Scenario B: Du har høj TTFB kun på nogle tidspunkter

Typiske tegn:

• samme URL svinger meget
• spikes i 502/504
• TTFB er høj uden at CPU på origin ser presset ud

Hvad du gør:

• Tjek om proxy’en har upstream-kø, connection limits eller timeouts.
• Tjek om du har “cold” upstreams (autoscaling/cold start) eller cache der udløber synkront.
• Flyt simple redirects/rewrites til edge hvis det giver mening (så origin ikke rammes for hvert hop).

Scenario C: Du “optimerer”, men LCP flytter sig ikke

Typiske tegn:

• du har gjort billeder mindre, men LCP starter stadig sent
• fetchpriority/preload hjælper ikke stabilt

Hvad du gør:

• Check om HTML stadig kommer sent → TTFB er stadig problemet.
• Hvis HTML kommer hurtigt, check render-blocking → fjern render-blocking.
• Hvis HTML kommer hurtigt og render-blocking er ok, check om du henter LCP fra nyt domæne → DNS-lookup performance.

Typiske fejl (jeg ser dem hele tiden)

• “CDN er aktivt, så caching virker”: CDN uden cache på HTML er ofte kun et transportlag. I kan stadig have høj TTFB på dokumentet.
• “Vi har cache, så vi er færdige”: cache uden purge/revalidation giver forældet HTML eller kaos ved deploy.
• “Vary er en detalje”: Vary kan være forskellen mellem 90% cache-hit og 0%.
• “Det må være frontend”: Server-Timing og waterfall afslører ofte at problemet ligger i proxy/origin-kæden før noget JS overhovedet kører.

Næste skridt (konkret)

Hvis du vil gøre dette til en plan, så start her:

1. Find 1–3 vigtigste skabeloner (forside, guide, blogindlæg)
2. Mål TTFB og navngiv mønsteret i waterfall
3. Tjek Cache-Control, Vary, Age og evt. Server-Timing
4. Ret én ting ad gangen og mål igen

Når du er klar til implementering:

• Guide: Forbedr TTFB og cache
• Blog: Sådan læser du en waterfall
• Ordbog: Reverse proxy
• Ordbog: Server-Timing

Relaterede blogindlæg

Cache-Control forklaret: sådan bruger du caching til lavere TTFB

2026-01-25

Lær hvordan Cache-Control påvirker HTML, CSS, JavaScript og billeder, og få en praktisk gennemgang af caching, TTFB og klassiske fejl.

5 grunde til at din hjemmeside er langsom og hvad du gør ved det

2025-11-14

Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.

Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)

2026-04-02

En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.

Vary-header og caching: undgå forkert indhold og lav cache-hit-rate

2026-03-30

Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.

Sådan læser du en waterfall og finder flaskehalse i load

2026-02-10

Lær at læse en waterfall korrekt og find problemer med TTFB, LCP, render blocking og tredjepart, så du kan prioritere den rigtige optimering.

Hvordan du spotter render delay (uden at stirre på score)

2026-04-01

Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.

FAQ

Er et CDN det samme som en reverse proxy?

Funktionelt er et CDN ofte et netværk af reverse proxies. Forskellen er typisk at CDN’et er distribueret på mange POPs (edge), mens en klassisk reverse proxy kan være ét lag foran origin. Begge kan cache og terminere TLS.

Hvorfor ser jeg høj TTFB, selvom min server ikke er presset?

Fordi TTFB også kan komme fra proxy-laget: TLS-terminering, upstream-kø, cache-miss i edge, redirects, eller et load balancer-lag der sender dig til en langsommere upstream. Brug waterfall + response headers til at splitte lagene.

Skal jeg altid cache HTML i reverse proxy?

Nej. HTML-cache kan give stor effekt, men kræver at du ved hvad der er offentligt, hvordan du håndterer cookies/varianter, og hvordan du invaliderer (purge/revalidate). Start med en bevidst strategi, ikke med ‘cache alt’.

Eksterne kilder

Kilder til definitioner af reverse proxy, Vary og Server-Timing - plus HTTP-semantik for caching.

• MDN - Proxy servers and tunneling (inkl. reverse proxy)
• MDN - Server-Timing header
• MDN - Vary header
• RFC 9110 - HTTP Semantics (Vary)

Næste skridt i samme emne

Fortsæt fra forklaring til handling med guides, emner og ordbog.

Se relaterede guidesGå til emneoversigtSlå begreb op i ordbogLæs om metode og kilder