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

Hvis din side indeholder store medier (video, store assets, “lazy” thumbnails) kan Range request være forskellen på:

“hent kun det der skal bruges nu”
og “hent hele filen igen og igen”

Problemet er, at det sjældent bliver tydeligt i en enkelt audit. Det bliver først tydeligt, når du søger i mediet, genbesøger en stor ressource hurtigt eller tester på en mobil-forbindelse.

Hvad er Range request – og hvorfor fejler det ofte?

En Range request er browserens måde at bede om et udsnit af en fil, typisk via Range: bytes=.... Hvis alt spiller, svarer serveren med 206 Partial Content og ofte Content-Range.

I praksis ender mange setups dog i et af disse scenarier:

Browser sender Range, men origin/proxy/CDN ignorerer headeren.
Svaret bliver 200 OK med hele payloaden.
Klienten downloader mere data end nødvendigt, og det kan give langsommere afspilning eller flere re-downloads ved seek.

Den hurtige diagnose: 3 tegn på at Range ikke virker

1) Ser du `Range`-headeren i Network?

Åbn DevTools → Network → filtrér på den relevante ressource (video, stor billedfil eller API-asset). Kig efter om request faktisk indeholder en Range-header.

Hvis der ingen Range er: så er problemet ikke “serverens partial support”, men klientens adfærd eller medieopsætning.

2) Får du `206 Partial Content` tilbage?

Du leder efter statuskoden 206. Får du 200 OK, så har du næsten altid et problem i kæden (forwarding/handling).

Tjek også om du ser Content-Range, som typisk følger med partial responses.

3) Falder bytes ned ved seek / resume?

Det er det “praktiske” testpunkt. Hvis du downloader samme megabytes igen ved en handling der burde bruge et udsnit, så er Range ikke en reel gevinst.

Typiske årsager (der rammer 90% af fejlene)

Range header bliver ikke forwarded i et proxy/CDN-lag.
Origin har ikke Range support for netop den endpoint (middleware slukker, statisk filer håndterer ikke partial, eller en routing-regel returnerer fuld fil).
Caching og delvist indhold blandes: partial responses får ikke en korrekt cache-nøgle, eller bliver cached på en måde der gør at næste request stadig rammer “forkert” indhold.
Content-encoding/små transformationslag gør Range kompliceret i netop din stack (nogle proxies kan vælge at forenkle og give 200 i stedet).

Hvis du ofte arbejder med reverse proxies: start her, fordi det er det lag der oftest både kan forwarde og “normalisere” headers. Se også Reverse proxy.

Hvad du kan gøre: konkrete fixes

1) Forward `Range` korrekt (og bevar status semantik)

Hvis du har kontrol over proxy/CDN:

sørg for at Range-headeren ikke bliver fjernet
og at svaret må komme igennem som 206 (ikke omformatetet til 200)

2) Ret cache-strategien for partial indhold

Hvis partial indhold caches uden at tage højde for byte-offset, kan du få:

lav hit-rate og gentagne downloads
eller i værste fald “forkert svar” ved efterfølgende requests

Praktisk tilgang:

test partial responses med cache slået fra
og beslutar om partial indhold skal caches særskilt eller holdes uden for delte caches

Du kan koble det til Cache-Control og HTTP cache revalidation når du justerer reglerne.

3) Verificér med en “handlingsbaseret” test

Gør det konkret:

lav en scene hvor du søger/seeker (eller genviser en del af mediet)
og sammenlign request-mønsteret før/efter

Range er et “felt” problem. Derfor vinder du typisk ved at teste i faktiske flows frem for kun lab.

Relationen til andre performance-lag

Transfer-Encoding handler om hvordan svaret transporteres (fx chunked streaming).
Range request handler om hvilken del af filen klienten vil have (partial indhold).

De kan begge være relevante samtidig: du kan have hurtig transport i første fase, men stadig miste gevinst i seeking hvis partial responses ikke leveres korrekt.

Opsamling: tjekliste før du tror “det er ok”

Request indeholder Range-header ved de relevante handlinger
Respons er 206 Partial Content (ikke 200)
Content-Range matcher det forventede udsnit
Bytes overføres faktisk mindre ved seek/resume
Cache-regler ændrer ikke adfærden i gentagne runs

Hvis du kan sætte hak ved alle punkter, har du næsten altid ryddet op i det mest typiske Range-problem.

Næste skridt

Hvis du samtidig arbejder med streaming af HTML (progressiv rendering), så kig på Transfer-Encoding (chunked) guide.

Relaterede blogindlæg

Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis

2026-03-30

Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.

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.

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.

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.

Sådan prioriterer du hastighedsoptimering uden at spilde tid

2026-03-27

Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.

FAQ

Hvorfor ser det “ikke ud som et performance problem” i PageSpeed?

Fordi meget af gevinsten først viser sig i brugerhandlinger: seek, resume eller hurtige thumbnail-visninger. PSI/Lighthouse måler mest første load og lab-runs, ikke gentagne byte-offset requests under reel brug.

Er Range request altid hurtigere?

Nej. Hvis proxy/CDN ikke understøtter partial indhold korrekt, kan du ende med 200 OK (hele filer) eller med caching der ikke virker, hvilket kan gøre det værre end en simpel download strategi.

Hvordan hænger Range request sammen med streaming?

Range request er den klassiske mekanisme bag seeking og delvis henting. Hvis du samtidig bruger streaming/fragmenteret levering (fx chunked), kan timing forbedres, men Range fejler stadig hvis headers eller statuskoder ikke matcher.

Eksterne kilder

HTTP Range requests og 206 Partial Content er standardiseret; resten er et praktisk debug-flow i DevTools og i netværkskæden.

Næste skridt i samme emne

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

Se relaterede guides Gå til emneoversigt Slå begreb op i ordbog Læs om metode og kilder

Range request i praksis