Kort fortalt: HTTP/3 er en nyere transport til webtrafik, der kører over QUIC (UDP). Det kan i nogle scenarier give hurtigere og mere stabil forbindelse, især på mobilnetværk med packet loss.
Hvorfor betyder det noget?
- Hurtigere connection setup i nogle scenarier
- Bedre håndtering af packet loss
Hvilken indflydelse har HTTP/3?
HTTP/3 kan påvirke:
- TTFB i nogle scenarier (hurtigere handshake)
- stabilitet ved packet loss (mindre “head-of-line” problemer)
- mobiloplevelse på ustabile netværk
Men det er vigtigt at være realistisk: på et allerede godt setup med HTTP/2 og god caching kan forskellen være lille. HTTP/3 er mest interessant som en stabilitetsforbedring, ikke som en erstatning for klassiske optimeringer som caching, billedoptimering og JS-reduktion.
Hvornår blev HTTP/3 introduceret?
HTTP/3 kom som næste skridt efter HTTP/2, fordi man ville forbedre transport-laget yderligere – især i situationer med netværksproblemer. QUIC blev designet til at håndtere moderne netværksforhold bedre.
HTTP/3 vs HTTP/2: hvornår ser du forskel?
Du ser typisk mest effekt når:
- brugere er på mobilnet med packet loss
- forbindelser ofte brydes og genoprettes
- der er mange små requests og handshake overhead er mærkbar
Du ser ofte mindre effekt når:
- dine brugere er på stabilt wifi/ethernet
- du har effektiv edge caching (CDN) tæt på brugeren
Sådan tester du om HTTP/3 er aktivt
Praktisk:
- DevTools → Network → kolonnen “Protocol” (skal vise
h3for nogle requests) - Kør tests i forskellige netværk (wifi vs mobil)
- Sammenlign repeat view og first view
Nogle setup leverer en blanding: HTML på h2, nogle assets på h3, afhængigt af klient/support.
Hvad bør du måle for at se effekten?
HTTP/3 handler primært om transport og stabilitet. Derfor giver det mening at kigge efter:
- lavere connection/TLS overhead på nogle netværk
- mere stabil TTFB på ustabile forbindelser
- færre “spikes” i waterfall når der er packet loss
Praktisk: test i et miljø hvor der faktisk er packet loss, ellers kan forskellen være lille.
Typiske scenarier hvor HTTP/3 hjælper
- mobilnetværk med tab af pakker
- brugere der skifter mellem netværk (wifi → mobil)
- lange sessions hvor forbindelser ellers “dør”
Typiske scenarier hvor du ikke ser meget forskel
- meget effektiv edge caching tæt på brugeren
- stabile forbindelser (fiber/wifi)
- sites hvor CPU/rendering er den reelle flaskehals (store bundles)
Typiske faldgruber
- Du aktiverer HTTP/3, men det er kun aktivt for en lille del af trafikken (browser/support varierer)
- Du forventer store “score”-forbedringer uden at løse billeder/JS/caching
Praktisk tjekliste
- Bekræft
h3i DevTools på mindst nogle requests - Test på mobilnet med varierende kvalitet
- Sammenlign first view og repeat view (caching vs transport)
- Sørg for at de store problemer (billeder, render-blocking, JS) stadig adresseres
FAQ
Skal man aktivere HTTP/3?
Hvis din stack (CDN/server) gør det nemt og stabilt, kan det være værd at aktivere – især hvis du har mange mobilbrugere på ustabile net.
Men det bør sjældent være et tidligt fokuspunkt. Start med de klassiske flaskehalse: caching/TTFB, billeder/LCP, render-blocking og JavaScript/INP. HTTP/3 kan være et “ekstra lag” efter fundamentet.
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.
