From a shared CDN to HTTP/3: ten years of web acceleration
Back in November 2016, I published an enthusiastic post on my blog: "CDNs are now SSL-compatible at OVH." The Pro and Performance shared-hosting plans had just earned the right to combine their CDN, 3 to 19 points of presence depending on the plan, with a free Let's Encrypt certificate. Until then you had to choose: caching close to your visitors, or the green padlock. Some people had even cancelled their CDN option to turn on HTTPS. My own site was running on one of those OVH shared plans at the time, so the announcement concerned me directly. Ten years later, the site you are reading is served over HTTP/3 through CloudFront, in front of an Nginx I tune myself on EC2, at AWS. Between the two, the entire transport layer of the web has been rebuilt. Here is the path, without the needless jargon.
What a CDN actually is
My 2016 definition still holds: a CDN (Content Delivery Network) stores and caches resources on servers other than yours, automatically, to serve them from a point closer to your visitors. Light travels fast through fibre, but a Brussels to Sydney round trip stays incompressible. Bringing the files closer is the dumbest and most effective gain there is.
What has changed is the scale. In 2016, 19 points of presence was a selling point. Today's large networks line up hundreds of them, and the CDN is no longer a checkbox in a shared-hosting panel: it is the front door of the site, the one that terminates HTTPS and speaks the latest protocol with the browser.
HTTP/1.1, the age of queues
To understand why HTTP/3 matters, you have to see where we came from. With HTTP/1.1, a connection carries only one request at a time. A page that loads fifty files means fifty turns in the queue, barely eased by the six parallel connections browsers open. We made up for it with hacks: pasting every icon into a single image, concatenating scripts, scattering resources across subdomains. I did all of it.
HTTP/2, standardised in 2015, fixed this on paper: a single connection, dozens of requests multiplexed inside it, compressed headers. Except that underneath, everything still runs over TCP, which guarantees packet order. A single lost packet and TCP blocks the whole connection while it waits for the retransmission, including files that have nothing to do with it. This is the notorious head-of-line blocking: the supermarket express lane, frozen because one item from the first customer will not scan.
HTTP/3 and QUIC, rebuilding under the road
HTTP/3 does not touch HTTP, it changes the road underneath. The QUIC protocol, standardised in 2021, runs over UDP and reimplements reliability itself, stream by stream. In practice:
Truly independent streams. A lost packet only blocks the file it belongs to. The CSS no longer waits for an image to be retransmitted.
Fewer round trips at startup. TCP then TLS meant two round trips before the first useful byte. QUIC folds TLS 1.3 encryption into its handshake: a single round trip, and zero for a returning visitor (the famous 0-RTT).
Connection migration. A QUIC connection is identified by a token, not an IP address. Your visitor leaves the office Wi-Fi and switches to 4G in the lift: the connection survives instead of renegotiating everything. On mobile, that is the most tangible gain.
And encryption is no longer an option you tick after the fact, the way it was at OVH in 2016: QUIC is encrypted by design, there is no such thing as HTTP/3 in the clear.
What it changes for a small-business site
Let's be honest: on a stable fibre link 10 ms from the server, the difference is measured in milliseconds. HTTP/3 shines exactly where your real customers are: a smartphone on average 4G, a train, a poorly covered area, a hotel Wi-Fi. Less latency on first load, fewer stalls when the network drops packets, no reconnection when you change networks.
In 2016, I wrote that a CDN "helps you rank better." I was getting ahead of myself. The 2026 version, more cautious: speed does not push a site to the top spot, but it weighs on Core Web Vitals, on bounce rate and on conversions. A quote form that responds instantly gets filled in more often, it really is that simple.
The good news: you have nothing to build. HTTP/3 happens at the hosting or CDN level, not in your code. It is a criterion for choosing a provider, not a project.
Check your own site in two minutes
Open your site in Chrome or Firefox, then the developer tools (F12), Network tab. Right-click the column headers and enable the "Protocol" column. Reload the page twice: HTTP/3 discovery goes through a header sent on the first visit, and the protocol often switches only on the second load. If you read "h3", you are set. "h2" is still fine, "http/1.1" across all traffic deserves a conversation with your host. Online testers run the same diagnosis if you would rather paste a URL.
Ten years on, the same obsession
The 2016 post ended on a hover SVG illustration, with and without a CDN. The technology has changed three times since, the idea behind it has not moved: bring the content closer to visitors, encrypt everything, remove the pointless waits. I have migrated several employers from shared hosting to this kind of infrastructure, and I slept better for it.
Today, this tuning is part of my managed hosting, on the same footing as backups and updates. And if your site is still on a shared plan that tops out at HTTP/1.1, moving it over to me is free: so is the diagnosis, it fits in a column of developer tools.
