HTTP/2 vs HTTP/3: What Changes and How to Check

An older speed report, a plugin’s settings page, or a forum thread from a few years ago told you to “enable HTTP/2”. Now your CDN dashboard has a switch for HTTP/3 as well, and you are not sure whether you have either, whether you need both, or whether flipping the switch could break something.

Here is the short version of HTTP/2 vs HTTP/3. Both are newer ways for a browser and a server to exchange files, and both are improvements on the HTTP/1.1 that the web ran on for many years. HTTP/2 is now the normal baseline on any decent host. HTTP/3 builds on the same ideas but changes the connection underneath, which helps most on unreliable mobile networks. Neither is something you install in WordPress; both are set on the server or the CDN.

What was wrong with HTTP/1.1

Under HTTP/1.1, one connection between browser and server carried one request at a time. The browser asked for a file, waited for it to arrive, then asked for the next. To get around this, browsers opened several connections to each domain in parallel, around six, and spread the requests across them.

For a page with a handful of files that was fine. For a modern page with dozens of stylesheets, scripts, fonts and images, it meant files queuing behind each other. Each extra connection also had its own setup cost before any data moved.

A whole set of speed tricks grew up to work around this:

• Combining all CSS into one file and all JavaScript into another, to cut the number of requests.
• Image sprites: many small icons packed into one image and cut out with CSS.
• Domain sharding: spreading files across several subdomains so the browser would open more connections.
• Inlining small files straight into the HTML.

Some of that advice still circulates. Under the newer protocols a lot of it is unnecessary, and domain sharding can actively slow things down.

What HTTP/2 changed

HTTP/2 lets many requests and responses travel over a single connection at the same time, interleaved. This is called multiplexing. The browser no longer has to wait for one file before asking for the next, and it no longer needs to open a pile of connections to the same server.

It also compresses request and response headers, which matters more than it sounds when a page makes many small requests carrying the same cookies and headers each time.

Two practical points:

• Browsers only use HTTP/2 over HTTPS. If your site still runs on plain HTTP, you are on HTTP/1.1 whatever the server supports.
• Server push is gone. HTTP/2 included a feature for the server to send files before the browser asked. Major browsers have since dropped support for it, so you can ignore any old advice built around it.

What HTTP/3 changes on top

HTTP/2 still runs over TCP, the long-standing transport that makes sure data arrives complete and in order. That promise of order has a cost. If one packet is lost on a patchy connection, everything on that connection waits until it is resent, even files that had nothing to do with the lost packet. One connection carrying everything, the strength of HTTP/2, becomes a weakness on a bad network.

HTTP/3 runs over a newer transport called QUIC, which is built on UDP instead of TCP. The differences that matter for speed:

• Lost data only holds up the file it belongs to. Other files on the same connection keep arriving.
• Faster setup. The connection and the encryption are negotiated together, so there are fewer round trips before the first byte moves. That shows most when the server is far away.
• Connections survive a network change. When a phone moves from Wi-Fi to mobile data, an HTTP/3 connection can carry on rather than starting from scratch.

On a fast, stable office connection the difference between the two can be small. On mobile data in a moving train, or on congested networks, HTTP/3 tends to help more.

Who actually notices the difference

It is worth being realistic about this. If you test your own site from a desk near the server on fibre broadband, HTTP/2 and HTTP/3 will probably look much the same, and you may conclude the newer one does nothing. The people who benefit are rarely sitting where you are.

• Visitors on mobile data with signal that drops in and out, where lost packets are common and HTTP/2’s single connection keeps stalling.
• Visitors far from the server, such as overseas customers of a site hosted in India, or the reverse, where every extra round trip during connection setup costs noticeably more.
• People moving between networks, leaving the office Wi-Fi with your page half loaded.

That is also why a single lab test from a well-connected data centre tends to understate the gain. If most of your audience fits one of the groups above, offering HTTP/3 is a reasonable small step. If they are mostly on stable office connections near your server, it is a nice-to-have.

HTTP/2 vs HTTP/3 side by side

How to check which one your site uses

The quickest way is in your own browser.

1. Open your site in Chrome or Edge, open developer tools and go to the Network tab.
2. Right-click any column heading and tick “Protocol” to add that column.
3. Reload the page. Each row now shows h2, h3 or http/1.1.

Look at the first row (your HTML) and at your own images and scripts. Third-party files, such as fonts or analytics, will show whatever their own servers use, which tells you nothing about your hosting.

Do not be surprised if your first load shows h2 and a later load shows h3. A browser normally learns that a server offers HTTP/3 from a header in an earlier response, then uses it on the next connection. Some networks, particularly corporate ones, block the kind of traffic HTTP/3 uses, and the browser then quietly stays on HTTP/2. That fallback is automatic, which is why switching HTTP/3 on is rarely risky.

If you are comfortable with a terminal, curl -I --http2 https://yourdomain.com shows the protocol in the first line of the reply.

How to enable HTTP/2 for a website

On most current hosting, HTTP/2 is already on for every site with an SSL certificate. If your check shows http/1.1:

• Make sure the site loads over HTTPS everywhere. Without it, nothing else applies.
• Ask the host. On shared hosting you cannot change this yourself. If an established host does not offer HTTP/2 on a secure site, that tells you something about how current the server software is.
• On your own VPS, it is a web server setting. Apache, Nginx and LiteSpeed all support it, though how it is enabled differs and the server’s own documentation is the place to follow.
• Through a CDN. If your site sits behind a CDN in proxy mode, visitors connect to the CDN, not your server, and the CDN decides the protocol. Many offer HTTP/3 as a simple setting. Our explainer on how a CDN sits in front of your site covers that setup.

HTTP/3 is newer and less universal on hosting, so a CDN is often the easiest way to offer it. Make one change, then repeat the protocol check and a speed test from the same location.

What this means for old speed advice

Once your site is on HTTP/2 or HTTP/3, revisit these habits:

• Combining every file into one. Not needed for request count the way it once was, and a giant bundle means one small change forces visitors to download everything again. Some combining still helps; our post on minifying and combining CSS and JavaScript looks at the trade-off.
• Domain sharding. Undo it. Extra domains mean extra connections and DNS lookups, which works against multiplexing.
• Counting requests above all. The number still matters, especially requests to other companies’ domains, but which requests and how big they are matters more. See which HTTP requests are worth cutting for that.

What a newer protocol will not fix

A faster way of moving files does not make the files smaller or fewer. Heavy images, too much JavaScript and slow server response are all still there under HTTP/3. Treat the protocol as plumbing: worth getting right, quick to check, and rarely the reason a site feels slow. Our group guide on what the server controls in page speed puts it alongside the server settings that matter more, and the wider website speed and performance guide covers the rest.

Frequently asked questions

Is there a WordPress plugin that turns on HTTP/2?

No. The protocol is negotiated between the browser and the web server or CDN before WordPress is involved. A plugin cannot change it. Some caching plugins mention HTTP/2 only to adjust settings such as file combining to suit it. Switching the protocol itself happens in the hosting setup or the CDN.

Can turning on HTTP/3 break my site?

It is one of the lower-risk changes you can make. Browsers that cannot use HTTP/3, or that sit on networks blocking it, fall back to HTTP/2 automatically. If you do see problems after switching it on at a CDN, turning the setting off again restores the previous behaviour.

Why do some files on my page show HTTP/2 and others HTTP/3?

Each domain is negotiated separately. Your own files use whatever your server or CDN offers, while fonts, analytics, video embeds and other third-party files use whatever their providers offer. Within your own domain, the first connection may also be HTTP/2 until the browser learns HTTP/3 is available.

Does HTTP/2 help a site that is still on plain HTTP?

It cannot, because browsers only use HTTP/2 and HTTP/3 over encrypted connections. A site without a working SSL certificate stays on HTTP/1.1. Moving to HTTPS comes first, and it is worth doing for security and visitor trust in any case.

The protocol column is a two-minute check; the rest of a slow site usually takes longer to untangle. Our website speed optimisation pairs a review of server response time with the page-side work on images, caching and scripts, and ends with a re-test you can compare against the starting point.

Next in this series: Gzip vs Brotli Compression: Check and Enable It