Voor developers verandert er niets aan de applicatie. Browsers die HTTP/3 ondersteunen, kunnen het protocol automatisch gebruiken. Andere browsers blijven via HTTP/2 communiceren.

Wat maakt HTTP/3 eigenlijk sneller? En waarom kan één verloren netwerkpakket bij HTTP/2 de laadtijd van een complete webpagina beïnvloeden?

Het probleem met HTTP/2: één verloren pakket houdt alles op

Een moderne webpagina bestaat uit tientallen bestanden. Denk aan HTML, CSS, JavaScript, afbeeldingen en fonts. De browser haalt deze bestanden op bij de webserver, vaak met meerdere requests tegelijkertijd.

HTTP/2 maakt dat efficiënt door meerdere requests over één TCP-verbinding af te handelen. Dat heet multiplexing. Dankzij multiplexing hoeft de browser niet voor ieder bestand een afzonderlijke verbinding op te zetten.

Maar TCP heeft een belangrijke eigenschap: gegevens moeten betrouwbaar en in de juiste volgorde worden afgeleverd. Gaat er onderweg een netwerkpakket verloren, dan moet dat pakket opnieuw worden verzonden. Totdat het ontbrekende pakket binnen is, houdt TCP ook gegevens tegen die daarna zijn ontvangen.

Bij HTTP/2 kan dat alle requests op dezelfde verbinding raken.

Stel dat een bezoeker tegelijkertijd een stylesheet, een JavaScript-bestand en een afbeelding downloadt. Er gaat een netwerkpakket verloren dat bij de afbeelding hoort. Hoewel de gegevens van de andere bestanden gewoon aankomen, kan TCP deze tijdelijk niet doorgeven aan de browser.

Dit probleem heet TCP head-of-line blocking.

Op een stabiele glasvezelverbinding valt daar vaak weinig van te merken. Maar op mobiele netwerken, drukke wifi-netwerken en verbindingen met packet loss kan het de laadtijd merkbaar beïnvloeden.

QUIC: afzonderlijke streams over UDP

HTTP/3 gebruikt QUIC als transportprotocol. Waar HTTP/2 gebruikmaakt van TCP, werkt QUIC over UDP.

UDP is een alternatief voor TCP, dat van zichzelf geen garanties biedt voor de aflevering van netwerkpakketten.

Het belangrijke verschil is hoe QUIC meerdere gelijktijdige gegevensstromen (streams) afhandelt.

Bij HTTP/3 krijgt iedere HTTP-request zijn eigen QUIC-stream. Gaat er een netwerkpakket verloren, dan hoeft alleen de betreffende stream op de ontbrekende gegevens te wachten. Andere streams kunnen ondertussen gewoon verder.

In ons eerdere voorbeeld kan de browser dus doorgaan met het ontvangen van de stylesheet en het JavaScript-bestand, terwijl QUIC het ontbrekende pakket van de afbeelding opnieuw laat verzenden.

Dat maakt HTTP/3 dus cruciaal voor websites die veel bestanden tegelijkertijd laden, en bezoekers met een wisselende verbindingskwaliteit, zoals op mobiele netwerken.

Sneller een beveiligde verbinding opzetten

QUIC verbetert ook het opzetten van nieuwe verbindingen.

Bij HTTP/2 over HTTPS moet de browser eerst een TCP-verbinding opzetten en vervolgens een TLS-handshake uitvoeren. Daarvoor moeten meerdere berichten tussen de browser en de server worden uitgewisseld.

QUIC integreert TLS 1.3 rechtstreeks in het transportprotocol. Daardoor kan een nieuwe beveiligde verbinding na één roundtrip al worden gebruikt.

Van wifi naar 5G zonder de verbinding te verliezen

QUIC ondersteunt daarnaast connection migration. Dat maakt het mogelijk om een bestaande verbinding voort te zetten wanneer het IP-adres van de bezoeker verandert.

Bij TCP is een verbinding gekoppeld aan onder andere het bron- en bestemmings-IP-adres. Wanneer een telefoon overschakelt van bijvoorbeeld wifi naar 5G, moet een TCP-verbinding opnieuw worden opgezet.

QUIC identificeert verbindingen niet op basis van IP-adres, maar een connection-ID. Die overleeft het wisselen tussen netwerken. Voor mobiele bezoekers vermindert dat onderbrekingen tijdens het laden van pagina's en het uitvoeren van requests.

Hoeveel sneller wordt een website met HTTP/3?

Dat hangt sterk af van de netwerkverbinding van de bezoeker.

Op een stabiele verbinding met weinig packetloss kan HTTP/2 ongeveer even goed presteren. HTTP/3 levert dan niet per definitie een merkbaar kortere laadtijd op.

De voordelen worden groter wanneer de verbinding minder betrouwbaar is. Denk aan een treinreiziger op mobiel internet, of een bezoeker op drukke openbare wifi.

HTTP/3 verandert natuurlijk niets aan de verwerkingstijd van een PHP-applicatie of databasequery. Als een request twee seconden nodig heeft om een resultaat te berekenen, blijft die verwerking even lang duren. De optimalisatie zit in het transport van de gegevens tussen de browser en de server.

HTTP/3 is sinds 3 juli standaard op Cyberfusion Core

Sinds 3 juli 2026 staat QUIC standaard ingeschakeld op Cyberfusion Core. Je hoeft hiervoor geen applicatiecode aan te passen of extra software te installeren.

Moderne versies van Chrome, Firefox, Edge en Safari ondersteunen HTTP/3. Wanneer een browser ontdekt dat HTTP/3 beschikbaar is, kan deze een QUIC-verbinding via UDP opzetten. Lukt dat niet, bijvoorbeeld omdat een netwerk UDP-verkeer blokkeert, dan kan de browser terugvallen op HTTP/2.

HTTP/3 werkt uitsluitend over een beveiligde verbinding. Je domein moet dus HTTPS gebruiken.

Je kunt in de developer tools van je browser controleren welk protocol wordt gebruikt. Open het tabblad Network en schakel de kolom Protocol in. Bij HTTP/3 zie je meestal h3.

Met een recente versie van curl die HTTP/3 ondersteunt, kun je het ook vanaf de commandline testen:

curl --http3-only -I https://example.com

Met HTTP/3 standaard ingeschakeld profiteren bezoekers waar mogelijk automatisch van de verbeteringen in QUIC. Vooral op mobiele en instabiele verbindingen kan dat zorgen voor een snellere en consistentere gebruikerservaring.