Latency — Forsinkelse i netværket og hvad du kan gøre ved det

Latency er den uundgåelige fysiske begrænsning i web performance: lyset kan kun rejse så hurtigt. En server i Singapore kan ikke svare en dansker på under ~80ms uanset serverens hastighed — det er den fysiske afstand. Latency-optimering handler om at minimere de RTT’er der skal gennemføres inden brugeren ser indhold.

Hvad latency består af

En simpel HTTPS-request gennemgår:

1. DNS-opslag — ca. 20-120ms (afhænger af DNS TTL og caching)
2. TCP-handshake — 1 RTT
3. TLS-handshake — 1-2 RTT (afhænger af TLS-version og 0-RTT support)
4. HTTP-request + svar — 1 RTT minimum

En side der fetches fra en server med 100ms RTT kan bruge 400-500ms bare på forbindelsesetablering — inden serveren sender det første byte.

HTTP-protokollens indvirkning

HTTP/1.1 håndterer én request per forbindelse ad gangen (med pipelining som sjælden undtagelse). Browseren åbner op til 6 parallelle TCP-forbindelser per origin — men hver forbindelse kræver sit handshake.

HTTP/2 multiplekser multiple requests over én TCP-forbindelse — eliminerer forbindelses-overhead for ressourcer fra samme origin. Head-of-line blocking er dog stadig et problem på TCP-niveau.

HTTP/3 bruger QUIC over UDP i stedet for TCP. Integreret TLS, elimineret head-of-line blocking, og 0-RTT resumption der genoptager forbindelser uden handshake. Særligt værdifuldt på ustabile forbindelser (mobil).

CDN — den primære latency-løsning

Et Content Delivery Network placerer caches af statisk indhold geografisk nær brugerne. I stedet for at hente fra en server i USA svarer et CDN-edge node i Frankfurt — 10ms i stedet for 100ms.

CDN reducerer latency for:

• Statiske assets (CSS, JavaScript, billeder, fonts)
• Cacheable HTML (statiske sites, SSG)
• Streaming og video

CDN løser ikke latency for dynamisk indhold der ikke kan caches (personaliseret data, live APIs).

Reducer RTT-overhead

Preconnect etablerer DNS, TCP og TLS-forbindelser til tredjeparts-origins tidligt:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

For Google Fonts eliminerer dette typisk 200-400ms ved første brug.

Keep-Alive genbruger TCP-forbindelser til requests mod samme server. HTTP/1.1 gør dette som default; HTTP/2 og HTTP/3 gør det endnu mere effektivt.

TLS 1.3 og 0-RTT reducerer TLS-handshake til 1 RTT (fra 2 i TLS 1.2) og tillader 0-RTT resumption for returnerende forbindelser.

Mål latency med Navigation Timing

TTFB-beregning via Performance API afspejler den samlede latency til serveren:

const nav = performance.getEntriesByType('navigation')[0];
const ttfb = nav.responseStart - nav.requestStart;
console.log(`TTFB: ${Math.round(ttfb)}ms`);

WebPageTest viser detailed waterfall der dekomponerer DNS, TCP, TLS og request-tider per ressource — det mest præcise tool til latency-debugging. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.