HTTP/3 og QUIC på en LiteSpeed-server: hvad det giver, og sådan tjekker du det

Kort svar: HTTP/3 kører på QUIC-protokollen – UDP i stedet for TCP – og fjerner de ventetider, der opstår ved forbindelsesopbygning og pakketab. Gevinsten er størst på mobilnet og ustabile forbindelser: hurtigere første forbindelse og ingen blokering af alle filer, når en enkelt pakke går tabt. LiteSpeed-webserveren har HTTP/3 indbygget, men om det er slået til, afgøres af serveropsætningen og firewallen. Verificér med alt-svc-headeren eller browserens Netværk-fane – og husk: HTTP/3 gør leveringen bedre, ikke en langsom side hurtig.

Fagligt gennemgået: 2. oktober 2026

HTTP/3 er den første store protokolopgradering siden HTTP/2 – og den, mobilbrugerne mærker mest. Navnene forvirrer let: QUIC er transportprotokollen, HTTP/3 er webprotokollen ovenpå, og QUIC.cloud er LiteSpeeds skytjeneste, der har lånt navnet. Navnet QUIC stammer fra Googles oprindelige „Quick UDP Internet Connections“; i den endelige IETF-standard er QUIC blot et navn.

Denne guide skiller tingene ad, forklarer hvad du reelt får, hvordan browseren finder frem til HTTP/3 – og hvordan du tjekker, at det kører på dit domæne.

HTTP/1.1, HTTP/2 og HTTP/3 – forskellen kort

	HTTP/1.1	HTTP/2	HTTP/3
—	—	—	—
Transport	TCP	TCP	QUIC over UDP
Kryptering	Valgfri (TLS ovenpå)	I praksis altid TLS	TLS 1.3 indbygget i QUIC
Flere filer på én forbindelse	Nej, én ad gangen pr. forbindelse	Ja, multiplexing	Ja, uafhængige strømme
Effekt af ét pakketab	Forsinker forbindelsen	Forsinker alle strømme på forbindelsen	Forsinker kun den berørte strøm

HTTP/2 løste mange af HTTP/1.1’s problemer ved at sende mange filer over én forbindelse. Men fordi alt stadig kører over én TCP-forbindelse, venter alle filer, når én pakke skal gensendes. Det er netop den flaskehals, HTTP/3 fjerner.

Hvad HTTP/3 forbedrer

To konkrete forbedringer bærer værdien.

Hurtigere håndtryk: Hvor TCP + TLS kræver flere ture frem og tilbage, før første byte kan sendes, klarer QUIC forbindelse og kryptering i én samlet proces. Ved genbesøg kan data ofte sendes med det samme (0-RTT), fordi browseren genbruger oplysninger fra sidste forbindelse.

Ingen head-of-line-blokering: På TCP stopper én tabt pakke alle samtidige downloads, til den er gensendt. På QUIC kører hver ressource i sin egen strøm, så ét tab kun rammer én fil.

Derudover kan en QUIC-forbindelse overleve, at brugerens IP-adresse skifter – fx når telefonen går fra wi-fi til mobilnet – fordi forbindelsen identificeres med et forbindelses-id frem for IP og port. Det er derfor, gevinsten er størst netop dér, hvor pakketab, netværksskift og høj latenstid hører hjemme: mobilnet, offentlig wi-fi og lange afstande.

Hvornår mærker du forskellen?

Sidder dine besøgende primært på stabil fiberforbindelse tæt på serveren, er forskellen mellem HTTP/2 og HTTP/3 lille. Har du mange mobilbrugere, kunder i andre lande eller sider med mange små filer, er der mere at hente. En webshop, hvor kunderne browser produkter på telefonen i toget, er et typisk eksempel på et site, hvor HTTP/3 giver mening – mens et internt værktøj, der kun bruges fra kontoret, næppe mærker noget.

Sådan finder browseren HTTP/3

Browseren starter ikke med HTTP/3, fordi den ikke ved, om serveren understøtter det. Første forbindelse sker typisk via HTTP/2 over TCP. Serveren svarer med en alt-svc-header, der fortæller, at samme indhold også kan hentes via HTTP/3 – fx alt-svc: h3=":443"; ma=86400. Browseren husker tilbuddet i den angivne tid og bruger h3 ved de næste requests.

Nogle domæner annoncerer også HTTP/3 i DNS med en HTTPS-record, så browseren kan bruge h3 allerede fra første forbindelse. Det er især udbredt bag CDN’er som Cloudflare. Uden HTTPS-recorden er alt-svc-mekanismen den normale vej.

1. Tjek, om dit site kører HTTP/3

Fra en terminal kan du først se, om serveren tilbyder HTTP/3, og derefter teste en egentlig HTTP/3-forbindelse. Den sidste kommando kræver en curl-version, der er bygget med HTTP/3-understøttelse:

curl -sI https://ditdomæne.dk/ | grep -i alt-svc
curl -sI --http3 https://ditdomæne.dk/

Uden terminal: Åbn browserens udviklerværktøjer → Netværk, højreklik på kolonneoverskrifterne, og slå „Protocol“ til. Står der h3 ud for dine requests, kører HTTP/3. Bemærk, at browseren ofte bruger HTTP/2 på første besøg og først skifter til h3 ved næste – den lærer af alt-svc-headeren. Genindlæs derfor siden, før du konkluderer.

Du kan også bruge et online HTTP/3-tjek, fx LiteSpeeds http3check.net, som tester udefra og derfor ikke påvirkes af dit eget netværk.

2. Når HTTP/3 ikke er aktivt

På LiteSpeed-servere er HTTP/3 en serverfunktion – der er intet WordPress-plugin at installere. Mangler h3, er de typiske forklaringer:

• Funktionen er slået fra på serveren: Spørg hostingudbyderen, om HTTP/3 er aktiveret for dit domæne.
• UDP port 443 er blokeret: QUIC bruger UDP, ikke TCP. Serverens firewall skal tillade indgående UDP på port 443, ellers bliver alt-svc-tilbuddet aldrig til en forbindelse.
• Dit eget netværk blokerer UDP 443: Mange virksomhedsfirewalls gør det. Browseren falder så stille tilbage til HTTP/2, og du tror fejlagtigt, at serveren ikke understøtter h3.
• En proxy foran serveren: Går trafikken gennem et CDN eller en proxy, er det proxyens HTTP/3-understøttelse, de besøgende møder.

Bag Cloudflare er det Cloudflares egen HTTP/3-indstilling, der gælder for besøgende. Cloudflare henter i dag indholdet fra din server via HTTP/1.1 eller HTTP/2, så serverens egen HTTP/3-understøttelse spiller ingen rolle for trafik bag den orange sky. Det samme gælder QUIC.cloud CDN: dér er det CDN’ets kantservere, der taler HTTP/3 med browseren.

3. Sikkerhed og firewall

HTTP/3 ændrer ikke på, hvordan WordPress er beskyttet, men to ting er værd at kende. For det første skal firewall- og overvågningsregler også dække UDP-trafik på port 443, ikke kun TCP. For det andet kan 0-RTT-data i princippet afspilles igen af en angriber (replay). Webservere begrænser derfor typisk 0-RTT til sikre requests som almindelige GET-kald, så handlinger som login, formularer og betalinger ikke udføres to gange. Det er serverens ansvar og kræver normalt ingen indstilling i WordPress.

Hvad det betyder for dine målinger

Forvent ikke et hop i PageSpeed-scoren: labtests kører på stabile, simulerede forbindelser, hvor QUIC’s fordele knap kommer i spil. Gevinsten viser sig i feltdata – især TTFB og LCP for mobilbrugere – og i færre langsomme enkeltoplevelser. Forskellen på lab- og feltdata er forklaret i guiden om PageSpeed Insights og CrUX.

HTTP/3 er med andre ord et fundament: Det gør leveringen robust, mens indholdets størrelse og serverens svartid stadig er dine egne opgaver. Se TTFB-guiden og guiden til en hurtigere WordPress-side.

Sådan verificerer du

HTTP/3 er bekræftet, når:

• alt-svc-headeren annoncerer h3;
• browserens Netværk-fane viser h3 på requests efter en genindlæsning;
• et online HTTP/3-tjek giver grønt for dit domæne.

Det er en éngangsverifikation – protokollen kræver ingen løbende pleje. Er h3 fraværende, og hostingen bekræfter, at det burde køre, så test fra et andet netværk, fx mobilnettet: virksomhedsfirewalls, der blokerer UDP 443, er en klassisk falsk alarm. Gentag tjekket, hvis du flytter sitet, skifter CDN eller ændrer firewallregler.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• Hvad er LiteSpeed?
• Høj TTFB i WordPress
• Cloudflare vs. QUIC.cloud
• WordPress hosting hos Hostious – LiteSpeed og NVMe med servere i Europa

Ofte stillede spørgsmål om HTTP/3

Er QUIC.cloud og QUIC det samme?

Nej. QUIC er transportprotokollen bag HTTP/3 – en åben standard, alle kan bruge. QUIC.cloud er LiteSpeeds kommercielle skytjeneste (CDN og optimering), der har lånt navnet. Du kan køre HTTP/3 uden QUIC.cloud – og omvendt.

Skal jeg installere noget i WordPress for at få HTTP/3?

Nej – protokollen håndteres af webserveren eller CDN’et, ikke af WordPress. På LiteSpeed-hosting er den indbygget i serveren; dit arbejde er at verificere, at den er slået til og ikke blokeres af en firewall.

Hvad hvis en browser ikke understøtter HTTP/3?

Så bruger den bare HTTP/2 eller HTTP/1.1 som hidtil. alt-svc-mekanismen er et tilbud, ikke et krav, så browsere uden HTTP/3 – eller på netværk, der blokerer UDP – henter siden ad den almindelige vej.

Hvorfor viser min browser HTTP/2, selvom serveren understøtter HTTP/3?

Oftest fordi det er første besøg, og browseren endnu ikke har set alt-svc-headeren, eller fordi dit netværk blokerer UDP port 443. Genindlæs siden, og test eventuelt fra mobilnettet eller med et online HTTP/3-tjek.