Often the files are fine and the connection is the problem. Every request travels over a transport protocol, and older ones handle packet loss badly. On a patchy mobile network, one dropped packet can stall everything behind it. HTTP/3 was built to fix exactly that failure.
This is one of the least glamorous performance topics we deal with. Nobody asks for HTTP/3 in a project brief. It never shows up in a design review. It sits underneath the whole site, quietly deciding how fast bytes actually arrive.
The good news is that it is mostly a setting, not a rebuild. The honest news is that it will not rescue a heavy site. Both of those things are true at once, and this article explains why.
HTTP/3 is the third major version of the protocol browsers use to fetch web pages. It was published by the IETF as RFC 9114 in June 2022. The big change is underneath: instead of running over TCP like every earlier version, HTTP/3 runs over a transport protocol called QUIC.
The RFC describes itself plainly. It maps HTTP semantics over QUIC, a transport that offers "stream multiplexing, per-stream flow control, and low-latency connection establishment". Those three phrases are the entire pitch for the protocol.
Nothing about your HTML, CSS, or images changes. A page served over HTTP/3 contains exactly the same content as the HTTP/2 version. Only the delivery mechanism differs, which is why you can usually enable it without touching a single line of your site.
HTTP/2 already sent many files down one connection at the same time. The problem was that all of those streams shared a single TCP connection. If one packet went missing, TCP held back everything behind it until that packet arrived, even for unrelated files.
That behaviour has a name: head-of-line blocking. It is invisible on a good office connection and painful on a train. HTTP/3 solves it by moving multiplexing down into QUIC, where RFC 9114 notes that each stream gets its own flow control rather than sharing one queue.
The second difference is encryption. HTTP/2 could technically run unencrypted, even though browsers never allowed it in practice. QUIC builds security into the transport itself, so encryption is not an optional layer bolted on top.
The practical result is that HTTP/3 tends to look similar to HTTP/2 on a strong connection and noticeably better on a weak one. If most of your traffic is mobile, that gap matters more than it looks on paper.
QUIC is the transport protocol under HTTP/3, defined by the IETF as RFC 9000 in May 2021. Its full title says most of it: "QUIC: A UDP-Based Multiplexed and Secure Transport". It runs over UDP rather than TCP.
UDP sounds like a strange choice because it offers no delivery guarantees on its own. That is the point. TCP is baked into operating systems and hard to change, so QUIC rebuilds reliability in user space where it can actually evolve, and uses UDP purely as a delivery envelope.
RFC 9000 lists what QUIC provides: "flow-controlled streams for structured communication, low-latency connection establishment, and network path migration." That last item is the one people miss. Path migration means a connection can survive a network change.
In everyday terms, that is walking out of your house while a page loads. Your phone drops off Wi-Fi and onto mobile data. With TCP the connection dies and starts again. With QUIC it can continue, which is a genuinely useful thing on a phone.
More than most people assume. W3Techs reported in August 2026 that HTTP/3 is used by 40.0% of all websites. For comparison, the same source reported HTTP/2 at 34.7% in the same month. HTTP/3 is no longer the experimental option.
Browser support is further ahead than server support. Can I Use lists global browser support for HTTP/3 at 92.43%, with Chrome and Edge from version 87, Firefox enabled by default from version 88, and Safari from version 16.0.
Safari took the longest road. Can I Use records the feature as present but disabled through Safari 14 to 15.6, with full support arriving in Safari 16.0, and the same pattern on iOS. If you support an audience on older iPhones, some of them will still be on HTTP/2.
That combination is why we treat this as a safe default. Almost every visitor can use it, and the ones who cannot simply fall back to HTTP/2 without noticing anything.
Sometimes, and by less than you hope. HTTP/3 improves how efficiently bytes move across a poor connection. It does nothing about how many bytes you send. A bloated page delivered over a better transport is still a bloated page.
Here is the order we work in, and it has not changed. Cut the payload first. Fix the images, the fonts, and the third-party scripts. Then look at hosting and delivery. HTTP/3 belongs in that second group, alongside caching and a good CDN.
The gains that do exist show up where you would expect. Faster connection setup helps the first request on a page, which feeds into Time to First Byte. Fewer stalls under packet loss helps everything after it, including Largest Contentful Paint.
We are deliberately not quoting a percentage improvement here, because any honest number depends entirely on the visitor's network. Vendors who promise you a fixed speed gain from a transport protocol are describing their test conditions, not your customers.
Open your site in Chrome, open DevTools, and go to the Network tab. Right click the column headers and switch on the Protocol column. Reload the page. Each request will show its protocol, and HTTP/3 appears as h3.
Do not be surprised if the first load shows h2 and the second shows h3. Browsers usually discover HTTP/3 support through an Alt-Svc response header on an earlier connection, then upgrade on the next visit. That is normal behaviour, not a misconfiguration.
Check a few different request types too. It is common to see your own pages on h3 while an embedded script or font from another company still arrives over h2, because that company controls its own delivery, not you.
For most businesses, you do not configure it, you inherit it. HTTP/3 is enabled at the edge by your hosting platform or CDN, so the real question is whether your provider supports it and whether the toggle is switched on for your domain.
If you are on a managed platform like Webflow, this is handled for you and there is no setting to find. If you sit behind a CDN such as Cloudflare or Fastly, or deploy to a platform like Vercel, look for the HTTP/3 or QUIC option in the network settings for your domain.
The one real world blocker is UDP. QUIC uses UDP port 443, and some corporate firewalls block or throttle UDP traffic. Those visitors quietly fall back to HTTP/2, which is fine. It is worth knowing when a client insists their office network sees no difference.
If you are choosing infrastructure right now, this belongs on the checklist rather than at the top of it. We covered how to think about that layer in our guide to whether your website needs a CDN.
It can help your Core Web Vitals a little, and it is not a ranking factor by itself. Google measures the experience your visitors get, not the protocol that delivered it. If HTTP/3 improves loading metrics for real users, that improvement counts. The protocol name does not.
This distinction matters because it changes what you optimise for. Nobody at Google is checking whether you serve h3. They are looking at field data from actual visitors, which means a faster transport only helps if it moves those numbers.
Where we do see a clear argument is for sites with international or mobile-heavy audiences. Longer network distances and weaker connections are exactly the conditions QUIC was designed for, so those sites get the most out of it.
Check it once, then stop thinking about it. Spend two minutes confirming your site serves h3, and if it does not, ask your host why. After that, put your energy into payload size and render blocking work, which is where the large wins still live.
That is the honest version of this topic. HTTP/3 is a genuine improvement to how the web moves data, backed by published standards and now used by a large share of sites. It is also a checkbox, not a strategy, and treating it as one is how teams end up with a fast protocol serving a slow page.
If you want us to look at how your site is actually being delivered, from the transport layer up through images and scripts, we are happy to walk through it. Come and say hello at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.