HTTP/2 and HTTP/3: What Changes for Your Website
HTTP/2 and HTTP/3 move data more efficiently than HTTP/1.1. Learn what multiplexing and QUIC do, whether you need to change anything, and how to check support.
HTTP is the language browsers and servers use to exchange web pages. It has changed over the years, and the newer versions, HTTP/2 and HTTP/3, make pages load more efficiently without changing what your site looks like. For most site owners the good news is that you rarely have to do anything except make sure your hosting and CDN support them.
This article explains what changed, what it means for your performance habits, and how to check which version your site uses.
HTTP/1.1: the old way
With HTTP/1.1, a connection handles one request at a time. To load many files in parallel, browsers open several connections, typically around six per host, and each needs its own setup. If one file is slow, those behind it on the same connection wait. This is called head-of-line blocking. It led to performance tricks that were sensible then: merging many CSS and JavaScript files into one, using image sprites, and serving assets from several hostnames.
HTTP/2: many requests, one connection
HTTP/2, standardised in 2015, keeps the same meaning for requests and responses but changes how they travel.
- Multiplexing: many requests and responses share one connection at the same time, interleaved.
- Header compression: repeated headers such as cookies are sent in a compact form.
- Prioritisation: browsers can signal which files matter most.
- Binary framing: data is sent in binary frames rather than text, which is more efficient to process.
Browsers only support HTTP/2 over HTTPS in practice, which is one more reason to have a valid SSL certificate on every site.
HTTP/3 and QUIC
HTTP/2 still runs over TCP, and a lost packet on a TCP connection can stall every stream on it. HTTP/3, standardised in 2022, runs over QUIC, a protocol built on UDP. QUIC handles each stream independently, so loss in one does not block the others. It also combines the connection and encryption setup, which reduces the number of round trips, and it can keep a connection alive when a phone switches from Wi-Fi to mobile data. These benefits are most noticeable on unreliable or high-latency networks, such as mobile connections.
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC over UDP |
| Parallel requests per connection | One at a time | Multiplexed | Multiplexed, independent streams |
| Encryption | Optional | Used in practice by browsers | Built in (TLS 1.3) |
| Header compression | No | Yes | Yes |
What it means for your optimisation habits
Because requests are cheap on HTTP/2 and HTTP/3, some older advice matters less:
- Concatenating every script into a single huge file is no longer necessary, and can hurt caching, since a small change invalidates the whole bundle.
- Sharding assets across multiple domains is counterproductive, because it forces extra connections.
- Image sprites are rarely worth the maintenance.
Other advice still applies fully. Fewer and smaller files are still faster, compression still helps, caching is still essential, and shipping less JavaScript always helps the browser. A protocol upgrade makes transport more efficient; it does not make a heavy page light.
How to check your version
- Open Chrome DevTools, go to the Network tab, right-click the column headers and enable the Protocol column.
- Reload the page. Values show as
h2for HTTP/2 andh3for HTTP/3. - Or run
curl -I --http2 https://your-site.examplein a terminal and look at the first line of the response.
If your site is behind a CDN, the visitor-to-CDN leg and the CDN-to-origin leg may use different versions. What matters most for visitors is the first one.
Enabling support
HTTP/2 is supported by current versions of Apache and nginx and is typically on by default for HTTPS sites on modern hosting. HTTP/3 support depends on the web server build and network configuration, since it needs UDP traffic to be allowed. On a VPS you control this yourself; on shared hosting it is up to the provider. The simplest way for many sites to offer HTTP/3 is through a CDN, which terminates visitor connections at the edge and speaks the newest protocol on your behalf. Browsers fall back to an older version automatically if a newer one is unavailable, so enabling it carries little risk.
Do not forget the basics
A faster protocol will not rescue a slow server. If your time to first byte is high, work on caching and server response first. Protocols improve how the data travels; they do not change how long it takes your application to produce it.
Myths worth dropping
- "HTTP/3 makes every site dramatically faster." The gain depends on network conditions. On a stable wired connection to a nearby server the difference may be small; on lossy mobile networks it is more likely to show.
- "I must rewrite my site for HTTP/2." You do not. The protocol is negotiated between the browser and the server, and your HTML, CSS and JavaScript stay exactly as they are.
- "Server push will speed things up." HTTP/2 included a push feature, but it proved hard to use well and major browsers have removed or disabled support for it. Use preload hints instead.
The practical takeaway is to confirm that your host or CDN serves at least HTTP/2, enable HTTP/3 where it is offered, and spend your real effort on page weight and server response.
Modern protocols at the edge
Using Cloudflare CDN on a Zebra Hosting Cloud site is an easy way to get modern delivery to your visitors while your origin stays simple. Read more on the CDN page.