HTTP/2 and HTTP/3: What Changes for Speed and How to Check

Every time a browser loads a page, it speaks a version of HTTP to your server. The version in use decides how requests share a connection, how headers are sent and what happens when a network packet gets lost. Most modern hosts and CDNs already offer HTTP/2, and many also offer HTTP/3, but a surprising number of sites are still served over HTTP/1.1 because nobody turned the newer protocols on.

This guide is for site owners and developers who want to know which protocol their site uses, whether it is worth changing, and how to confirm the change worked. You will learn what each version improves, how to check it in a browser and on the command line, how to enable it, and what stays the same. These protocols change how data is carried, not what is carried. They do not shrink images, remove unused JavaScript or fix a slow server, and they come with no promise of a particular speed-up or search result.

Before you begin

You need to know where your site is served from: shared hosting, a virtual server you manage, or a CDN or platform provider. On managed hosting and CDNs the protocols are usually a switch in a control panel. On a server you manage, you will edit the web server configuration, so back up the current configuration and have a way to roll back.

All the checks in this guide are read-only. In practice both protocols are set up on HTTPS sites: HTTP/2 over TLS is negotiated during the TLS handshake, and HTTP/3 uses TLS 1.3. If you are not on HTTPS yet, start with moving from HTTP to HTTPS. Plan for 30 to 60 minutes.

What each version changes

HTTP/1.1. MDN's history of HTTP notes that HTTP/1.1 introduced connection reuse, chunked responses and the Host header. It still has head-of-line blocking: a client must wait for one response before using that connection for the next request, so browsers open up to six connections per origin to work around it.

HTTP/2. Standardized in 2015 and now specified in RFC 9113. HTTP/2 is a binary protocol that adds multiplexing, so many requests and responses travel in parallel over one connection, and header compression, so repeated header fields are not sent in full each time. Sites do not need to change their pages or applications to benefit; the server and browser both need to support it. Because everything runs over a single TCP connection, MDN explains that packet loss detected at the TCP layer can block all streams at once.

HTTP/3. Defined in RFC 9114. It keeps HTTP's meaning but replaces TCP with QUIC, which runs over UDP. Each stream is handled independently, so a lost packet blocks only the stream it belonged to. web.dev adds that HTTP/3 uses TLS 1.3, so new connections need one round trip and resumed connections none, and that benefits are largest on high-latency or lossy connections. The same article cautions that CDN support varies.

A server tells browsers it offers HTTP/3 with an Alt-Svc response header. The client may then try a QUIC connection and fall back if it fails. The header looks like this, where the protocol ID h3 names HTTP/3, :443 is the port and ma is the number of seconds the information stays valid:

Alt-Svc: h3=":443"; ma=86400

The HTTP/3 specification allows servers to use any UDP port, so use the port your server actually advertises.

What about crawlers?

Google's crawler documentation says its crawlers support HTTP/1.1 and HTTP/2, with HTTP/1.1 as the default, and that a site can opt out of HTTP/2 crawling by answering with a 421 status code. It does not list HTTP/3. The page does not say HTTP/2 helps rankings, and you should not expect it to. For crawling, what matters most is that the server answers correctly and quickly.

Step-by-step instructions

Step 1: Check what you use today in Chrome DevTools

Open your site, press F12 and select the Network tab. Right-click the column headings and tick Protocol. Reload the page. The Protocol column shows h2 for HTTP/2 and h3 for HTTP/3, and http/1.1 for the old protocol. Look at the first row (your HTML) and a few files from your own domain and from third parties.

Two details prevent confusion. Browsers may use HTTP/2 on the first visit and switch to HTTP/3 on later visits, since they learn about HTTP/3 from Alt-Svc. And files from third-party hosts use whichever protocol that host offers, which you cannot change.

What success looks like: You know the protocol used for your HTML and your own static files.

Step 2: Check with curl

curl can print the HTTP version it used. The http_version write-out variable reports the version actually used.

curl -s -o /dev/null -w "%{http_version}\n" --http2 https://example.com/

A result of 2 means HTTP/2 worked. If the output is 1.1, the server did not negotiate HTTP/2. To see whether the server advertises HTTP/3, look for Alt-Svc in the headers:

curl -sI https://example.com/ | grep -i alt-svc

To test HTTP/3 itself, curl needs to be built with HTTP/3 support; its documentation describes the --http3 option (which falls back if HTTP/3 fails) and --http3-only. The feature list printed by curl --version shows what your build supports. If your build lacks support, rely on the browser check.

What success looks like: You have an http_version result and know whether an Alt-Svc header is present.

Step 3: Enable HTTP/2 where you host

On managed hosting, look in the control panel for an HTTP/2 or "modern protocols" setting. On a CDN, it is usually on by default or a single toggle. On servers you run, enable it in the web server configuration (check your server's documentation, since the directive differs). It requires a valid HTTPS setup.

Test after enabling. web.dev warns that HTTP/2 is stricter than HTTP/1.1 about header formatting: uppercase or non-ASCII characters in header names can trigger errors such as ERR_HTTP2_PROTOCOL_ERROR. Load your key pages, login, forms and any API calls your site makes.

What success looks like: Step 1 and Step 2 now show h2, and the site still works.

Step 4: Enable HTTP/3 if your host or CDN offers it

On a CDN this is typically a setting. If you run your own server, it needs a web server build and configuration that support QUIC, and your firewall must allow UDP traffic on the port you advertise. Without that, browsers will try HTTP/3, fail and fall back, which costs a little time. Do not enable it without checking your hosting plan's support.

After enabling, confirm the Alt-Svc header appears, then reload a page twice in Chrome. The Protocol column may show h3 after the browser has learned about it.

What success looks like: The Alt-Svc header is present and the Protocol column shows h3 on later loads.

Step 5: Review old HTTP/1.1 workarounds before removing them

Habits from the HTTP/1.1 era, such as joining many files into one or spreading files over several hostnames, were meant to work around its connection limits. With HTTP/2 multiplexing they matter less, but removing them is not always an improvement. Test before and after. For JavaScript structure, see reducing JavaScript size.

HTTP/2 server push is a case where the feature did not work out in practice. Chrome announced it would disable push by default in Chrome 106, citing low use and mixed results, and recommended 103 Early Hints or preloading instead. If your server still pushes files, plan to stop it.

What success looks like: You have made no change without a before and after measurement.

Step 6: Measure the effect honestly

Run PageSpeed Insights or Lighthouse before and after, from the same location, several times each. Then watch field data for a few weeks. If the change helps, it most often shows up on pages with many requests or visitors on slower or less reliable networks. If nothing changes, the bottleneck is somewhere else, such as images, JavaScript or server time. See improving Lighthouse performance.

What success looks like: You can show a before and after for at least one page, or you know the protocol was not your bottleneck.

Final verification checklist

DevTools shows h2 or h3 for your HTML and your own static files.
curl reports http_version 2 for your home page.
If HTTP/3 is on, the Alt-Svc header is present and UDP traffic is allowed for its port.
Forms, login, checkout and API calls still work after the change.
robots.txt, the sitemap and key pages return normal 200 responses.
Your server does not use HTTP/2 push.
You compared before and after results and saved them.

Common mistakes to avoid

Expecting a large speed-up from the protocol alone. The protocol changes how requests are carried. Large images, heavy scripts and slow back ends stay slow.

Enabling HTTP/3 without opening UDP. Clients may try it, fail and fall back. Make sure the advertised port is reachable.

Sending header names with uppercase or odd characters. HTTP/2 can reject them. Test after enabling.

Removing bundling without measuring. The 1.1-era advice is dated, but test your own site before restructuring.

Still relying on server push. Chrome disabled it by default; use preload or Early Hints.

Checking only one browser visit. HTTP/3 may appear only after the browser has seen Alt-Svc. Reload and check again.

Assuming third-party files follow your settings. Their protocol is set by the third-party host.

Frequently asked questions

Is HTTP/2 or HTTP/3 a ranking factor?

Google's crawler documentation lists the protocols its crawlers support but does not call either a ranking signal. Faster delivery can improve user experience; this guide cannot promise it changes rankings.

Do I need HTTPS for HTTP/2?

HTTP/2 over TLS is negotiated during the TLS handshake, and HTTP/3 uses TLS 1.3 as part of QUIC. In practice you should have HTTPS working before enabling them.

Can I turn HTTP/2 off for crawlers?

Google says that to opt out of crawling over HTTP/2 you respond with a 421 status when it asks over HTTP/2. This is rarely needed; use it only if you have a specific reason.

Why does my site show HTTP/1.1 on a CDN?

The CDN may have the protocol disabled, or the request may have gone to the origin directly. Check the CDN setting and test the public hostname rather than the origin address.

Does HTTP/3 work on every network?

No. A client may fall back to HTTP/2 if a QUIC connection does not work. That fallback is part of how Alt-Svc is designed to be used.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.