Hurtigere hjemmeside hjælp til en langsom hjemmeside

Transfer-Encoding

Transfer-Encoding beskriver hvordan HTTP-legemet leveres. Når serveren bruger `chunked`, kan den sende data i bidder, før den kender hele længden.

Skrevet af Kim Tetzlaff

Kort fortalt: Transfer-Encoding fortæller browseren, hvordan svaret skal samles op. Når den er sat til chunked, kan serveren sende HTML i bidder undervejs. Det kan give hurtigere første byte og bedre progressiv rendering.

Hvad handler Transfer-Encoding om?

  • En HTTP-header der beskriver transportformen for svaret
  • Typisk chunked, hvor legemet sendes i flere bidder i stedet for én færdig størrelse
  • Et signal om, at serveren kan begynde at levere data før alt indhold er færdigproduceret

Hvorfor betyder det noget for hastighed?

Transfer-Encoding kan påvirke din oplevede hastighed på to måder:

  1. TTFB kan falde, hvis origin eller en proxy ikke længere buffer hele svaret først.
  2. Ressourcer kan opdages tidligere, fordi HTML (og eventuelle kritiske styles/links) når frem i tide til at browseren kan gå i gang med parsing, styling og (senere) paint.

Det betyder ikke, at du automatisk får bedre Core Web Vitals. Hvis problemet i stedet ligger i render-blocking CSS/JS eller tung main-thread, kan render delay stadig dominere LCP.

Typiske årsager til at “chunked” ikke hjælper

  • Appen flusher aldrig tidligt (PHP/Node-koden venter med at sende alt)
  • Reverse proxy bufferer svaret (klassisk når der forventes fuldt respons før viderelevering)
  • Compression/streaming pipeline kan ende med at bufferes ét sted før komprimering
  • Det streamede indhold er ikke kritisk for dit LCP-element (du kan streame “noget”, men ikke det der betyder noget for første visning)

Typiske forbedringer i praksis

  • Fjern buffering der hvor du har kontrol: app- og proxy-lag skal tillade tidlig flush i stedet for at samle hele svaret.
  • Start med HTML, ikke små “stunts”: de første byte bør indeholde de elementer og links der styrer LCP og rendering.
  • Mål og bekræft: brug TTFB, Render delay og Lighthouse/field-data før og efter.

Relaterede begreber

  • TTFB – hvad første byte dækker over
  • LCP – hvordan “første visning” måles
  • Render delay – når data er klar, men paint kommer sent
  • Reverse proxy – hvor streaming ofte enten hjælpes eller stoppes
  • Server-Timing – et billigt signal til at se hvor tiden gik

FAQ

Betyder chunked altid lavere TTFB?

Nej. Chunked gør det muligt at sende data gradvist, men effekten kræver at appen/proxyen faktisk flusher output tidligt. Hvis svaret buffers, bliver “chunking” ikke til hurtigere første visning.

Hvorfor ser jeg ingen `Content-Length`?

Når svaret er chunked, kendes total længde typisk ikke før alt er produceret. Derfor mangler `Content-Length` ofte, og data leveres som flere `chunk`.

Er det det samme som server push i HTTP/2?

Nej. Transfer-Encoding handler om transport af selve svaret. Server Push er en proaktiv mekanisme til at sende ekstra ressourcer; de to ting påvirker forskellige dele af performance-kæden.

Eksterne kilder

MDN forklarer headeren, og RFC’en uddyber den semantiske rolle i HTTP. DevTools gør effekten synlig i timing.

Næste skridt fra begreb til handling

Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.

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