HTTP/1.1 vs HTTP/2 vs HTTP/3 — Why Your Website Feels Faster (or Slower)

Introduction

When you’re trying to speed up a website, what comes to mind first? Minifying JavaScript? Compressing images? Caching?

Those are all important — but there’s one lower-level detail that’s easy to miss: the version of the HTTP protocol your website is using.

The difference between HTTP/1.1, HTTP/2, and HTTP/3 isn't just technical trivia. It can have a real, measurable impact on how fast your site loads — especially in real-world network conditions like mobile or high-latency environments.

Here’s what’s changed across the versions, and why it matters more than you might think.

HTTP/1.1 – The Old Reliable (With Some Rust)

HTTP/1.1 ran the internet for over two decades. It’s rock-solid, widely supported, and still in use — but it’s not built for modern web complexity.

Key limitations:

• Runs over TCP
• Handles one request per connection
• Uses keep-alive, but requests still get queued
• No built-in compression or multiplexing

📌 Modern websites aren’t loading one or two files — they’re pulling in dozens of CSS, JS, images, and fonts.

Browsers work around this by opening multiple parallel connections (usually up to 6 per domain), which increases load on servers and network congestion.

That’s why techniques like bundling, minifying, and image sprites were essential back in the day — they were workarounds for the protocol’s inefficiencies.

HTTP/2 – Smarter, But Still on TCP

HTTP/2 improved performance significantly while still using TCP under the hood.

What it does better:

• Supports multiplexing — multiple requests in a single connection
• Reduces application-level blocking between requests
• More efficient use of connections between client and server

This fixes a lot of the queueing problems from HTTP/1.1. But since HTTP/2 still relies on TCP, it inherits TCP’s limitations — most notably head-of-line blocking at the transport layer. If one packet is lost, everything waits for it to be retransmitted.

📌 Most modern browsers and CDNs support HTTP/2 by default, so if your server is configured properly, you might already be using it.

HTTP/3 – Rebuilt for the Modern Web

HTTP/3 is the newest version, and it takes a bold step: ditching TCP entirely. It uses QUIC, a transport protocol built on top of UDP.

Why that’s a big deal:

• Faster connection setup — supports 1-RTT or even 0-RTT handshakes
• Avoids head-of-line blocking by handling streams independently
• Built-in TLS 1.3, fully integrated into the protocol
• Designed for unstable or lossy networks (like mobile and public Wi-Fi)

Because QUIC is designed to handle individual streams separately, one lost packet doesn't block the others — meaning better performance on flaky connections.

📌 Adoption is growing, but it's still not everywhere. Some CDNs support HTTP/3 at the edge, but still use HTTP/1.1 or HTTP/2 when talking to the origin server.

Quick Comparison Table

How to Check Which HTTP Version You're Using

You can check the HTTP version of any site using curl:

curl -I -w "%{http_version}\n" -s https://example.com

• -I: fetch headers only
• -w "%{http_version}": print the HTTP version
• -s: silent mode

What you’ll see:

• 2 → HTTP/2
• 1.1 → HTTP/1.1

To test for HTTP/3 (if your curl version supports it):

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

Not sure if your curl can do HTTP/3? Run:

curl -V

Look for HTTP3 in the Features list.

Note: Some curl builds don’t include HTTP/3 support by default.

So Which One Should You Use?

It depends on your users and your infrastructure:

Final Thoughts

HTTP version upgrades don’t get as much attention as flashy frontend optimizations — but they should.

In real-world conditions, especially on mobile or flaky networks, the version of HTTP your site is using can significantly affect how fast your content loads.

Sometimes the bottleneck isn’t in your code — it’s in the protocol.

Take a minute to check what version you’re running. You might be surprised how much faster things can get with just one upgrade.