Kort fortalt: Når en browser sender en Range request, beder den om en bestemt del af et indhold. Hvis serveren kan levere det, kommer svaret ofte som 206 Partial Content. Det kan reducere ventetid og dataforbrug ved fx video-seeking.
Hvad måler/handler det om?
En Range request handler om:
Range-headeren (typisk byte-intervaller)- serverens evne til at svare med partial content
- hvorvidt netværket og caching lagene faktisk leverer det, klienten forventer
Hvorfor betyder det noget?
Hvis Range request virker som forventet:
- henter klienten kun det nødvendige udsnit
- kan video/medie ofte starte hurtigere ved seeking
- kan “resume” downloads bruge mindre båndbredde
Hvis Range request ikke virker:
- serveren returnerer hele filen (
200 OK) - afspilning eller browsing kan føles langsommere, især på mobil/ustabilt net
- du får flere og tungere downloads uden at det er tydeligt i “klassisk” performance-måling
Typiske årsager til at Range ikke leverer gevinst
Range-headeren forsvinder i et proxy/CDN-lag (forwarding/normalisering).- Origin svarer ikke med partial content (Range disabled, uegnet middleware, statisk filhåndtering der ikke støtter udsnit).
- CDN caching blander partial responses eller cache-resultatet bliver mindre effektivt, fordi nøgler/headers ikke passer.
- Content-encoding gør det sværere: når der komprimeres, bliver byte-intervaller ofte “ikke ligetil”. Løsningen er afhængig af stack og CDN-understøttelse.
Typiske forbedringer
- Sørg for at
Range-headers bliver forwarded til origin for de relevante endpoints. - Bekræft at du får
206 Partial ContentogContent-Rangetilbage ved requests. - Overvej caching-strategi: delvist indhold kan kræve særlig behandling (eller bevidst ikke at cached i delte nøgler).
- Test på de rigtige bruger-scenarier: fx “seek” i afspiller og hurtige thumbnail-views, ikke kun første load.
Relaterede begreber
FAQ
Hvorfor bruges Range request i praksis?
Til ting som videoseeking, store downloads med resume, eller når klienten vil hente en specifik del i stedet for hele payloaden.
Hvorfor ser jeg 200 OK i stedet for 206?
Typisk fordi origin/proxy/CDN ikke understøtter Range, eller fordi `Range`-headeren bliver fjernet/ignoreret. Resultatet er ofte større dataoverførsel end nødvendigt.
Hvad er den største risiko ved caching af partial indhold?
Partial responses skal i praksis caches ud fra byte-offset (eller behandles så de ikke blandes). Hvis caching ikke tager højde for det, kan du få forkerte svar eller dyre re-downloads.
Eksterne kilder
MDN dokumenterer Range-semantikken, og RFC’en beskriver statuskoden og indholds-udsnit.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
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
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.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
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.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
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.
Hvordan du spotter render delay (uden at stirre på score)
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.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
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.
