Van een gedeeld CDN naar HTTP/3: tien jaar snellere websites
In november 2016 publiceerde ik een enthousiaste blogpost: "CDN's zijn nu SSL-compatibel bij OVH." De gedeelde hostingpakketten Pro en Performance hadden net het recht gekregen om hun CDN, 3 tot 19 aanwezigheidspunten afhankelijk van het pakket, te combineren met een gratis Let's Encrypt-certificaat. Tot dan moest je kiezen: caching dicht bij je bezoekers, of het groene slotje. Sommigen hadden hun CDN-optie zelfs opgezegd om HTTPS te kunnen aanzetten. Mijn eigen site draaide toen op zo'n gedeeld OVH-pakket, dus die aankondiging raakte me rechtstreeks. Tien jaar later wordt de site die je leest geserveerd via HTTP/3 over CloudFront, voor een Nginx die ik zelf afstel op EC2, bij AWS. Tussen die twee is de volledige transportlaag van het web opnieuw opgebouwd. Dit is het traject, zonder overbodig jargon.
Wat een CDN eigenlijk is
Mijn definitie uit 2016 klopt nog steeds: een CDN (Content Delivery Network) slaat bronnen op en cachet ze op andere servers dan de jouwe, automatisch, om ze te serveren vanaf een punt dichter bij je bezoekers. Licht gaat snel door glasvezel, maar een retourrit Brussel-Sydney blijft onvermijdelijk. Bestanden dichterbij brengen is de domste en meest doeltreffende winst die bestaat.
Wat wél veranderd is, is de schaal. In 2016 was 19 aanwezigheidspunten een verkoopargument. De grote netwerken van vandaag zetten er honderden op een rij, en het CDN is niet langer een vinkje in een paneel voor gedeelde hosting: het is de voordeur van de site, degene die HTTPS afsluit en het nieuwste protocol met de browser spreekt.
HTTP/1.1, het tijdperk van de wachtrijen
Om te begrijpen waarom HTTP/3 telt, moet je zien waar we vandaan komen. Met HTTP/1.1 draagt een verbinding maar één verzoek tegelijk. Een pagina die vijftig bestanden laadt, betekent vijftig beurten in de wachtrij, nauwelijks verzacht door de zes parallelle verbindingen die browsers openen. We compenseerden dat met knutselwerk: alle iconen in één afbeelding plakken, scripts samenvoegen, bronnen over subdomeinen verspreiden. Ik heb het allemaal gedaan.
HTTP/2, gestandaardiseerd in 2015, loste dit op papier op: één verbinding, tientallen verzoeken erin gemultiplext, gecomprimeerde headers. Alleen loopt eronder alles nog over TCP, dat de volgorde van de pakketten garandeert. Eén verloren pakket en TCP blokkeert de hele verbinding in afwachting van de hertransmissie, inclusief de bestanden die er niets mee te maken hebben. Dat is de beruchte head-of-line blocking: de snelkassa van de supermarkt, vastgelopen omdat één artikel van de eerste klant niet door de scanner gaat.
HTTP/3 en QUIC, onder het wegdek herbouwen
HTTP/3 verandert niets aan HTTP, het verandert de weg eronder. Het QUIC-protocol, gestandaardiseerd in 2021, rijdt over UDP en implementeert de betrouwbaarheid zelf opnieuw, stroom per stroom. Concreet:
Echt onafhankelijke stromen. Een verloren pakket blokkeert alleen het bestand waartoe het behoort. De CSS wacht niet langer op de hertransmissie van een afbeelding.
Minder heen-en-weer bij het opstarten. TCP en dan TLS, dat waren twee retourritten voor de eerste nuttige byte. QUIC verwerkt de TLS 1.3-versleuteling in zijn handshake: één retourrit, en nul voor een terugkerende bezoeker (de befaamde 0-RTT).
Verbindingsmigratie. Een QUIC-verbinding wordt geïdentificeerd door een token, niet door een IP-adres. Je bezoeker verlaat de kantoor-wifi en schakelt over op 4G in de lift: de verbinding overleeft in plaats van alles opnieuw te onderhandelen. Op mobiel is dat de meest voelbare winst.
En versleuteling is niet langer een optie die je achteraf aanvinkt, zoals bij OVH in 2016: QUIC is versleuteld vanaf het ontwerp, HTTP/3 in klare tekst bestaat niet.
Wat het verandert voor een kmo-site
Laten we eerlijk zijn: op een stabiele glasvezelverbinding 10 ms van de server wordt het verschil in milliseconden gemeten. HTTP/3 schittert precies daar waar je echte klanten zitten: een smartphone op matige 4G, een trein, een slecht bereikte zone, een hotelwifi. Minder latentie bij het eerste laden, minder haperingen als het netwerk pakketten verliest, geen herverbinding bij het wisselen van netwerk.
In 2016 schreef ik dat een CDN "je beter doet scoren in zoekmachines". Ik ging een tikje te snel. De versie van 2026, voorzichtiger: snelheid stuwt een site niet naar de eerste plaats, maar ze weegt op de Core Web Vitals, op het bouncepercentage en op de conversies. Een offerteformulier dat meteen reageert, wordt vaker ingevuld, zo eenvoudig is het.
Het goede nieuws: je hoeft niets te ontwikkelen. HTTP/3 speelt zich af op het niveau van de hosting of het CDN, niet in je code. Het is een criterium om een dienstverlener te kiezen, geen bouwwerf.
Controleer je eigen site in twee minuten
Open je site in Chrome of Firefox, dan de ontwikkelaarstools (F12), tabblad Netwerk. Klik met de rechtermuisknop op de kolomkoppen en zet de kolom "Protocol" aan. Herlaad de pagina twee keer: de ontdekking van HTTP/3 verloopt via een header die bij het eerste bezoek wordt verstuurd, en het protocol schakelt vaak pas bij de tweede keer laden om. Lees je "h3", dan zit je goed. "h2" is nog altijd prima, "http/1.1" op al het verkeer verdient een gesprek met je host. Online testers stellen dezelfde diagnose als je liever een URL plakt.
Tien jaar later, dezelfde obsessie
De post uit 2016 eindigde op een SVG-illustratie om over te hoveren, met en zonder CDN. De techniek is sindsdien drie keer veranderd, het idee erachter is niet verschoven: de inhoud dichter bij de bezoekers brengen, alles versleutelen, nutteloos wachten wegwerken. Ik heb meerdere werkgevers van gedeelde hosting naar dit soort infrastructuur gemigreerd, en ik sliep er beter door.
Vandaag maakt deze afstelling deel uit van mijn beheerde hosting, op dezelfde voet als back-ups en updates. En als je site nog op een gedeeld pakket zit dat blijft steken op HTTP/1.1, is de overstap naar mij gratis: de diagnose ook, ze past in één kolom van de ontwikkelaarstools.
