HTTP/2 and HTTP/3: What Changes for Your Website

HTTP/3 is the newest version of the protocol that moves web pages between servers and browsers, and HTTP/2 is the version that most busy websites already use. Hosting companies and content delivery networks advertise both as automatic speed boosts, and some site owners treat them as magic switches. In practice they change how a browser and a server talk to each other, not what your pages contain. The gain can be real, especially on mobile connections and on pages with many files, but it is rarely dramatic on a lean, well-cached site. Knowing what each version does helps you decide what to enable, what to test and what to ignore.

This guide explains the differences between HTTP/1.1, HTTP/2 and HTTP/3 in plain language, what they mean for page speed, how to check which version your site uses, how to enable them on a typical web server, and which old optimisation habits you can drop. It is written for business owners and administrators who manage a website or talk to a hosting provider, not for protocol engineers.

Why the Protocol Version Matters at All

Every page is a bundle of requests. The browser asks for the HTML document, then for stylesheets, scripts, fonts, images and tracking tags, and each of those is a separate request. In the original design of the web, HTTP/1.1, a browser opened several connections to a server and asked for one file at a time on each. If a large file was slow, everything queued behind it. Developers invented workarounds: they merged files into big bundles, combined small images into sprites and spread assets across extra hostnames. Those tricks made sense for that protocol, and they are the reason many older sites still carry a lot of unusual build steps.

HTTP/2 and HTTP/3 were designed to remove the underlying limits instead of working around them. They let a browser fetch many files at the same time over a single connection, they compress the repetitive headers that accompany each request, and in the case of HTTP/3 they cope better with the unreliable networks that phones use. For a visitor, the result is that the same page can appear sooner, particularly the first time they visit, when the connection has to be set up from scratch.

HTTP/1.1, HTTP/2 and HTTP/3 Compared

The table shows why HTTP/3 is not simply “HTTP/2 but newer”. It changes the transport underneath. HTTP/1.1 and HTTP/2 run over TCP, which delivers data in strict order. If one packet is lost, TCP holds back everything behind it until that packet is resent. HTTP/2 fixed the queueing at the application level but still suffered from this at the transport level. HTTP/3 uses QUIC, which keeps each stream independent, so a lost packet delays only the file it belonged to. The formal descriptions are published as RFC 9113 for HTTP/2 and RFC 9114 for HTTP/3, although you do not need to read them to make good decisions.

What You Can Expect in Real Life

Gains depend on the shape of your site and on who visits it. A page with a handful of requests on a fast office connection will show little difference, because the old protocol was never the bottleneck. A page with seventy requests viewed on a train with patchy coverage benefits much more. The following situations tend to gain the most:

• Pages with many small assets. Multiplexing removes the queue, so dozens of small files no longer wait in line.
• Mobile visitors with unstable connections. HTTP/3 recovers from packet loss and network changes, such as moving from Wi-Fi to mobile data, more gracefully.
• First visits from distant locations. The combined handshake saves round trips, and each round trip costs more when the visitor is far from the server.
• Sites behind a content delivery network. These networks usually offer both protocols at the edge, which means visitors get the benefit without changes to your origin server.

The gains are small in these cases:

• A site whose slowness comes from heavy images, large scripts or a slow database. A better protocol cannot compress a three megabyte photograph for you. Our guide to website speed and Core Web Vitals shows where the real time goes.
• A site with strong caching and few third-party scripts, where repeat visitors already load most files locally.
• An audience that mostly browses from fast fixed connections and modern devices.

Treat the protocol as one layer of the stack. It is cheap to enable and rarely harmful, but it does not replace work on content, caching and code.

How to Check Which Version Your Site Uses

You can find out in a minute without special tools.

1. Use the browser developer tools. Open the Network panel, reload the page, right-click the column headers and enable the Protocol column. Values such as h2 and h3 show the version used for each request. If you see http/1.1 on your own domain, your server is not offering HTTP/2.
2. Use a command-line check. A request with a recent version of curl and the option for HTTP/2 or HTTP/3 shows the negotiated version in the response line. Not every curl build supports HTTP/3, so a failure there does not prove your server lacks it.
3. Use an online checker. Several free services test a URL and report the supported protocols. They test from outside your network, which is what matters.
4. Look at third-party requests separately. Fonts, analytics and widgets come from other servers and use whichever version they offer. You do not control those.

Test the main page, a page with images, and a page behind login if you have one. A site can serve the home page through a content delivery network with HTTP/3 while an application subdomain still answers with HTTP/1.1.

Enabling HTTP/2 and HTTP/3 on Your Server

The exact steps depend on your web server and hosting, so treat the following as a map rather than a recipe.

HTTP/2

HTTP/2 needs HTTPS, so a valid certificate comes first. Our article on SSL certificate renewal and management covers that foundation. Current versions of Nginx and Apache both support HTTP/2. In Nginx it is usually a single parameter on the listen directive or a dedicated setting, depending on the version. In Apache it is a module and a protocols line, and it works best with a threaded processing model rather than the old prefork model, which matters if your PHP is run through the older embedded module. On shared hosting you normally cannot change this at all, and the control panel or the provider enables it for you.

HTTP/3

HTTP/3 needs more than a configuration line. The server must support QUIC, the firewall must allow UDP traffic on port 443 in addition to TCP, and the server announces the new option to browsers through a header called Alt-Svc so that they can switch on a later request. Nginx has support in recent releases, and some other servers and proxies have it as well. The simplest way for most small businesses is to enable it at the content delivery network in front of the site, which terminates the connection and talks to your origin server with whichever version it supports. Read more about that layer in our guide to CDN and web application firewall for small business websites.

Things to Check Before You Switch

• Is UDP port 443 open in the server firewall and in any cloud security group?
• Does the monitoring system check the site over the protocol visitors will use, or only over HTTP/1.1?
• Do any security devices or corporate proxies in front of your site block QUIC? Browsers fall back to HTTP/2 automatically when HTTP/3 fails, so visitors are rarely locked out, but logs may show odd patterns.
• Does the log format record the protocol, so you can compare performance before and after?

Optimisation Habits to Revisit

Some advice from the HTTP/1.1 era is now useless or even harmful. Review these on your own site rather than deleting them blindly, since each decision depends on the way the site is built.

• Merging every script and stylesheet into one huge file. Under HTTP/2, several moderately sized files that can be cached separately often work better, because a small change no longer invalidates a giant bundle. Bundling still reduces overhead, so keep sensible groups rather than hundreds of tiny files.
• Image sprites. They save requests, but they make images harder to maintain and cache. Modern formats and inline vector icons are often cleaner.
• Domain sharding. Spreading assets over several hostnames to get more parallel connections now hurts, because every extra hostname needs its own connection setup.
• Inlining large resources. Embedding big files in HTML defeats caching. Inline only the small, critical parts.

Server push, an HTTP/2 feature that sent files before the browser asked for them, was widely used less successfully than expected and has been removed from major browsers. Modern hints such as preload links achieve a similar goal with more control. Do not build new work around server push.

Measuring the Effect Honestly

Because the benefit differs between visitors, one test on your own laptop proves little. Use a method that you can repeat.

1. Record a baseline. Capture lab tests from several locations and, if available, field data for real visitors, such as the Core Web Vitals report in the search console. Note the dates.
2. Change one thing. Enable the protocol and do not touch images, plugins or caching in the same week.
3. Compare like with like. Use the same pages, the same test settings and a similar number of days of field data.
4. Watch error rates. Check server logs and monitoring for new failures, especially around uploads, long-running requests and streaming.
5. Keep a rollback. Know how to turn the feature off at the server or content delivery network, and test that the site still works without it.

If field data shows a small improvement in loading times on mobile and no rise in errors, keep the change. If nothing changes, you have still modernised the stack at almost no cost, which is a fair outcome.

Security and Compatibility Notes

HTTP/3 is always encrypted, and both newer versions rely on current TLS settings, so enabling them is a good moment to review your certificate and cipher configuration. Older clients that do not support the new protocols simply keep using HTTP/1.1, which means you do not need to maintain separate sites. Some network devices that inspect traffic cannot read QUIC and may either block it or let it pass unexamined, so security teams that depend on inspection should know about the change. As with any change on a server, it belongs in your documented routine. Our overview of server administration describes how we keep such changes planned, tested and reversible for client servers.

A Worked Example

A small online shop runs on a virtual server with Nginx and a content delivery network in front. The site has about eighty requests per product page, and customers browse mostly from phones. The administrator checks the Protocol column and finds that the delivery network already serves HTTP/2 but not HTTP/3, while direct requests to the origin use HTTP/1.1. She records a baseline of mobile loading times from field data over two weeks.

She then enables HTTP/3 in the delivery network settings, confirms that the Alt-Svc header appears and checks that the origin server is unchanged. Over the next two weeks, the field data shows a modest improvement in loading time on mobile connections, and error rates remain flat. Separately, she upgrades the origin to HTTP/2, since the web server version already supports it and the certificate is valid. The remaining slowness comes from oversized product photographs and several marketing scripts, so those become the next project. The protocol work took an afternoon and did what it should, while the larger gains came from the content work that followed.

Common Mistakes

• Expecting a protocol upgrade to fix slow database queries or heavy pages.
• Enabling HTTP/3 without opening UDP port 443, so browsers never use it.
• Testing only the home page and missing an application subdomain that still uses an old protocol.
• Removing every bundle and optimisation at once, then wondering why the site changed.
• Forgetting that third-party scripts follow their own servers’ protocols.
• Leaving monitoring on HTTP/1.1 only, so protocol-specific problems go unseen.
• Making the change together with other updates, which makes results impossible to interpret.

Frequently Asked Questions

Do I need HTTP/3 if I already have HTTP/2?

You do not need it, but it can help visitors on mobile and unreliable networks. If your content delivery network offers it with one setting and no cost, enabling it is a sensible low-risk step.

Will HTTP/2 or HTTP/3 improve my search rankings directly?

Not by themselves. Search engines care about the experience of real visitors, so faster loading can help indirectly, but the protocol version is not a ranking signal that you can switch on.

Is HTTP/3 safe for e-commerce and login pages?

Yes. It is always encrypted and uses modern security. Test checkout and login flows after enabling it, as you would after any server change.

What happens to visitors whose browsers do not support HTTP/3?

They continue to use HTTP/2 or HTTP/1.1. The server offers the newer option and the browser decides whether to use it, so nobody is locked out.

Can I enable these protocols on shared hosting?

Often HTTP/2 is already on, and HTTP/3 depends on the provider. Check the control panel or ask support, and consider a content delivery network if the host does not offer it.

Do I still need to combine my CSS and JavaScript files?

Less than before. A moderate number of sensibly sized files works well under HTTP/2, and large bundles can even hurt caching. Review your build setup and test the result.

The Bottom Line

HTTP/2 and HTTP/3 make the conversation between browser and server more efficient, with HTTP/2 handling many requests at once and HTTP/3 adding better behaviour on unreliable connections. They help most on busy pages and mobile networks, and least on sites that are slow for other reasons. Check which version you use, enable the newer ones where your server, firewall or content delivery network supports them, measure the change with a baseline and keep a rollback ready. Then spend the remaining effort on images, caching and scripts, where the larger gains usually sit.