HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead

HTTP-protokollen er fundamentet for al kommunikation mellem browser og server. HTTP/1.1 fra 1997 har begrænsninger der direkte forringer web performance for moderne sites med mange ressourcer. HTTP/2 og HTTP/3 løser disse begrænsninger på protokolniveau og forbedrer TTFB og LCP markant på sites der udnytter dem korrekt.

HTTP/1.1 og dens begrænsninger

HTTP/1.1 er request-respons-baseret og synkron: én request ad gangen per forbindelse. Browseren må vente på svar inden næste request kan sendes (head-of-line blocking).

Workarounds i HTTP/1.1-æraen:

• 6 parallelle forbindelser per origin — browseren åbner 6 TCP-forbindelser simultant
• Domain sharding — assets serveres fra flere subdomæner (static1.example.com, static2.example.com) for at omgå 6-forbindelses-grænsen
• Resource bundling — alt JavaScript samles i ét bundle, alt CSS i ét stylesheet

Disse workarounds er ikke nødvendige med HTTP/2 og kontraproduktive.

HTTP/2 — multiplexing og streams

HTTP/2 introducerer binær framing og multiplexing: requests og responses opdeles i frames der sendes interleaved over én enkelt TCP-forbindelse.

Nøgle-features:

Multiplexing — et ubegrænset antal streams per forbindelse. Alle assets fra example.com hentes parallelt over én forbindelse. Ingen 6-forbindelses-grænse.

Header compression (HPACK) — HTTP-headers komprimeres. Gentagne headers (f.eks. Cookie) sendes kun én gang og refereres derefter. Reducerer overhead markant for sites med mange requests.

Stream prioritering — klienten kan angive hvilke streams der er vigtigst. Kritisk CSS og JavaScript kan prioriteres over billeder.

Server push — serveren kan proaktivt sende ressourcer klienten endnu ikke har bedt om. I praksis er dette sjældent nyttigt og oft kontraproduktivt — det er deprecated i mange implementeringer.

# Aktiver HTTP/2 i Nginx
server {
    listen 443 ssl http2;
    # ...
}

TCP head-of-line blocking er dog stadig et problem i HTTP/2: pakketab på TCP-forbindelsen blokerer alle streams — ikke kun den påvirkede.

HTTP/3 — QUIC erstatter TCP

HTTP/3 erstatter TCP med QUIC (Quick UDP Internet Connections), en transportprotokol bygget på UDP med integreret TLS 1.3.

Fordele over HTTP/2:

Elimineret head-of-line blocking — QUIC håndterer tabte pakker per stream. Pakketab påvirker kun den ene stream, ikke alle andre streams på forbindelsen.

0-RTT connection resumption — returnerende brugere kan genoptage en QUIC-session uden handshake. Første request sendes øjeblikkeligt. Med TLS 1.3 over TCP kræver det minimum 1 RTT.

Bedre mobilperformance — QUIC håndterer netværksskift (Wi-Fi til 4G) bedre end TCP via connection migration: forbindelsen overlever IP-adresseændringer.

Connection ID i stedet for IP+port — QUIC identificerer forbindelser via et unikt ID, ikke IP-adresse og port. Mobilbrugere der skifter netværk mister ikke forbindelsen.

Browser- og serverside support

HTTP/2 understøttes af alle moderne browsere og de fleste webservere (Nginx, Apache, Caddy, Cloudflare). Det kræver HTTPS.

HTTP/3 understøttes af Chrome, Firefox og Edge. Cloudflare, Fastly og de store CDN-udbydere understøtter HTTP/3. Origin-servere er langsommere til at implementere det.

Tjek med: curl -I --http3 https://example.com

SEO-implikationer

HTTP/2 og HTTP/3 reducerer TTFB og LCP direkte — særligt for sider med mange ressourcer. Skiftet fra HTTP/1.1 til HTTP/2 kan reducere indlæsningstid med 20-50% for asset-tunge sider.

Google Googlebots støtter HTTP/2. HTTP/3-support for Googlebot er ikke bekræftet (2026). → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.