HTTP/2 and HTTP/3 explained: what they change for speed and how to turn them on

HTTP/2 is the version of the web's transfer protocol that lets a browser download all the files of a page at the same time over one connection, instead of in batches of six per host as HTTP/1.1 does. HTTP/3 keeps that idea but runs over QUIC, a newer transport on UDP, which connects faster and copes better with mobile networks that lose packets. Both are free, both need HTTPS, and on most hosts and every major CDN turning them on is a checkbox. This guide explains what each version changes, when it makes a visible difference, how to check what your site uses and how to switch them on for nginx, Apache, Caddy and Cloudflare.

Quick answer

• Run the HTTP/2 and HTTP/3 test. The ALPN row says what the server chose: h2 is HTTP/2; http/1.1 means it is off.
• nginx: listen 443 ssl; http2 on; (1.25.1+) or listen 443 ssl http2; on older versions.
• Apache: a2enmod http2 and Protocols h2 http/1.1 in the virtual host; use the event MPM.
• Caddy: HTTP/2 and HTTP/3 are on by default.
• Cloudflare, Netlify, Vercel and most managed hosts: HTTP/2 is already on; in Cloudflare, HTTP/3 is a toggle under Speed → Settings → Protocol Optimization.
• Everything needs HTTPS: browsers only speak HTTP/2 and HTTP/3 over TLS.
• Fewer bytes still beat fewer requests: HTTP/2 does not make a large image smaller.

What is HTTP/2?

HTTP is the language browsers and servers use to ask for and send pages, images, scripts and fonts. HTTP/1.1, from the late 1990s, sends one request at a time on each connection, and browsers open at most six connections per host. A page with 80 files therefore downloads in queues, each file waiting for a free connection.

HTTP/2, standardised in 2015 (RFC 7540, revised as RFC 9113 in 2022), changes how the same requests travel, not what they mean. URLs, headers, status codes and caching work exactly as before. What changes:

• Multiplexing. Every request and response is split into small frames that share one connection, so all files can be in flight at once and a slow one no longer blocks the rest.
• Header compression (HPACK). Every request repeats headers such as cookies and the user agent. HTTP/2 compresses them and sends only what changed, which saves real bytes on pages with many requests.
• One connection per host. One TCP and TLS handshake instead of up to six, so less setup time and better use of the connection's speed.
• Priorities. The browser tells the server which files it needs first, such as CSS before images below the fold. How well servers follow that varies.

HTTP/2 also introduced server push, which let a server send files before the browser asked. It rarely helped and often wasted bandwidth. Chrome removed support in 2022 and Firefox followed in 2024; use 103 Early Hints or a <link rel="preload"> instead (see preload, preconnect and prefetch).

What is HTTP/3?

HTTP/3 (RFC 9114, 2022) keeps HTTP/2's multiplexing and priorities but replaces the transport underneath. HTTP/1.1 and HTTP/2 run over TCP; HTTP/3 runs over QUIC (RFC 9000, 2021), which runs over UDP and has TLS 1.3 built in. Three things improve:

• Faster connection setup. TCP and TLS need separate handshakes; QUIC does both in one round trip. On a repeat visit, 0-RTT resumption can send the first request with no round trip at all.
• No head-of-line blocking at the transport. Over TCP, one lost packet stalls every file on the connection until it is resent. QUIC keeps each file's stream separate, so a lost packet only delays the file it belonged to.
• Connection migration. A QUIC connection can survive a switch from Wi-Fi to mobile data without starting over.

Browsers do not try HTTP/3 blind. The server announces it with an Alt-Svc response header, such as Alt-Svc: h3=":443"; ma=86400, and the browser uses HTTP/3 on its next connection. That is why a first visit usually arrives over HTTP/2 and later visits over HTTP/3. Current versions of Chrome, Edge, Firefox and Safari all support HTTP/3.

HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/2 vs HTTP/1.1

The practical difference shows on pages with many files: product grids, galleries, pages with dozens of scripts and fonts. Over HTTP/1.1 their waterfall looks like a staircase, six files at a time; over HTTP/2 the requests start together. On a page with one HTML file, one stylesheet and one image, the difference is small. The old HTTP/1.1 workarounds, such as sprites, domain sharding and inlining, become unnecessary or harmful (see "What HTTP/2 changes in how you build" below).

HTTP/2 vs HTTP/1.1 goes deeper: how multiplexing and HPACK header compression work, why HTTP/2 still stalls on a lost packet, what replaced the original priority scheme, why browsers dropped server push in favour of preload and 103 Early Hints, and which HTTP/1.1 front-end habits to unlearn.

QUIC and HTTP/3 vs HTTP/2

HTTP/3 helps most where the network is worst: phones on the move, long distances, congested Wi-Fi. On a good wired connection close to the server, HTTP/2 and HTTP/3 are hard to tell apart. It costs little to enable where your CDN or server supports it, as long as UDP port 443 is open; if the browser tries QUIC and gets no answer, it falls back to HTTP/2 after a delay.

QUIC gets its speed from three design choices: it runs over UDP inside the browser and server rather than in the operating system, it merges the transport and TLS 1.3 handshakes into one round trip (0-RTT on repeat visits), and it identifies connections by an ID, so a phone can switch networks without reconnecting. The guide what is QUIC? HTTP/3 vs HTTP/2 explains each, how a browser discovers HTTP/3 through Alt-Svc or a DNS HTTPS record, and when turning it on is worth it.

When HTTP/2 and HTTP/3 make a difference

Both protocols cut waiting, not bytes. They help when a page loads many files from the same host, when the connection is slow to set up, and on mobile networks. They do not help with a slow server (the time to first byte is the same, apart from the handshake) or with large files. A page with a 2 MB hero image and a 1 MB script is slow on any protocol.

In Core Web Vitals terms, HTTP/2 mostly helps LCP on pages where the hero image or critical CSS was queued behind other files, and HTTP/3 shaves round trips off the connection before the first byte. The page speed guide puts the protocol in context with the fixes that usually matter more, and TTFB: what a slow server looks like breaks down the handshake time that HTTP/3 shortens.

Both are all-or-nothing per connection, which is why third-party files still on HTTP/1.1 show up in the per-file table: a font host or a chat widget served over http/1.1 brings its own connections with the old limits.

Does HTTP/2 affect SEO?

Not directly. Googlebot has crawled over HTTP/2 where servers support it since November 2020, and Google Search Central said at the time that this brings no ranking benefit; it only makes crawling more efficient for Google and the server. The indirect effect is speed: if HTTP/2 or HTTP/3 improves your LCP for real visitors, that shows in Core Web Vitals, which Google uses in ranking. The Core Web Vitals guide explains how that assessment works.

How to check which protocol your site uses

The test has two parts. First, a TLS handshake with your server that offers h2 and http/1.1 through ALPN (the extension browsers use to agree on a protocol) and records which one the server picks, plus the TLS version and cipher. The page response's Alt-Svc header says whether HTTP/3 is advertised.

Then the page is loaded in Chromium and every response is grouped by the protocol it actually used, so third-party files are covered too:

Compression, cache headers and CDN detection are in the same panel because they live in the same configuration. In your own browser: developer tools → Network, right-click the column headers and add Protocol. h2 means HTTP/2, h3 means HTTP/3.

How to turn on HTTP/2 and HTTP/3

On most hosts and every major CDN, HTTP/2 is already on and HTTP/3 is a switch. On your own server it is a few lines: http2 on; in nginx 1.25.1 and newer (listen 443 ssl http2; before that), Protocols h2 http/1.1 with the event MPM in Apache, and nothing at all in Caddy or LiteSpeed. HTTP/3 additionally needs a QUIC listener, an Alt-Svc header and UDP port 443 open in every firewall on the way; Apache's stable server has no HTTP/3, so it needs a CDN or proxy in front.

The guide on how to enable HTTP/2 and HTTP/3 has the full configuration for nginx, Apache, Caddy, LiteSpeed, IIS and Cloudflare, the firewall commands, and the traps that leave a site on HTTP/1.1 after the change. Use the test result to decide where to start:

1. Read the ALPN row

• negotiated h2: HTTP/2 is on for your origin. Go to step 3.
• server chose http/1.1: HTTP/2 is off. Step 2.
• not tested (plain http): the page is served over http://. Move to HTTPS first; there is no HTTP/2 in browsers without it. See SSL/TLS checks that matter.
• could not test: the handshake failed (a firewall, an odd port). Check the SSL/TLS findings.

2. Turn it on where the connection ends

If a CDN sits in front, the protocol visitors get is the CDN's: turn HTTP/3 on in its settings and leave the origin as it is. Without a CDN, change the web server itself, following the step-by-step settings for each server, and reload.

3. Open UDP 443 before advertising HTTP/3

An Alt-Svc: h3=":443" header tells browsers to try QUIC on their next connection. If UDP 443 is closed at the server or in a cloud firewall, they try, wait and fall back to HTTP/2, which is slower than not advertising HTTP/3 at all. Leave 0-RTT off unless your application treats replayed GET requests safely.

4. Check the per-file table

The "Responses by protocol" chips count what the browser actually used. http/1.1: 12 on a site that negotiates h2 means those twelve files came from somewhere else: a font host, an analytics script, an image CDN on a plan without HTTP/2. Open the http2 finding to see the URLs. Replace the host, self-host the file (fonts especially), or accept it if it is one small file.

Browser errors: ERR_HTTP2_PROTOCOL_ERROR and ERR_QUIC_PROTOCOL_ERROR

Both errors are searched far more by visitors than by site owners, and both have a quick answer for each: if only one person sees the error, the cause is usually on their device or network; if everyone does, it is the server, a proxy or the CDN. In both cases, if the HTTP/2 and HTTP/3 test negotiates the protocol and loads the page, the site's basic setup works.

Chrome shows ERR_HTTP2_PROTOCOL_ERROR when an HTTP/2 connection breaks mid-response. For a single visitor, an extension, antivirus HTTPS scanning, a VPN or cached data is the usual cause. Server-side, the common causes are a response cut short (a full disk under the proxy's buffer, a crashed PHP process, a timeout), headers HTTP/2 forbids such as Connection or Transfer-Encoding, and a wrong Content-Length. The guide to fixing ERR_HTTP2_PROTOCOL_ERROR gives the visitor checklist and the site-owner diagnosis with curl --http2, logs and a temporary HTTP/1.1 fallback.

ERR_QUIC_PROTOCOL_ERROR is the HTTP/3 counterpart: a QUIC connection failed in a way the browser did not recover from. It usually depends on the network, because firewalls, VPNs and antivirus products treat UDP differently from TCP. On the server side, look for UDP 443 closed, an Alt-Svc header sent by servers that do not speak QUIC, or a load balancer that splits QUIC connections. The guide to fixing ERR_QUIC_PROTOCOL_ERROR covers turning QUIC off in Chrome as a test, testing with curl --http3-only, and switching HTTP/3 off at the CDN or server while you fix it.

Delivery beyond the protocol

HTTP/2 and HTTP/3 decide how files travel; three other settings decide how many bytes travel and how often. They usually live in the same server or CDN configuration, which is why the test checks them together.

Text compression. HTML, CSS, JavaScript and SVG shrink a lot with Brotli or gzip, and HTTP/2 does not compress them for you (HPACK only compresses headers). Text compression with gzip and Brotli compares the two and shows the setting for each server and CDN.

Browser caching. A file the browser already has needs no protocol at all. Files with a version in their name can be cached for a year; HTML should be revalidated. Cache-Control for humans has the headers to copy for each type of file.

A CDN. Most CDNs speak HTTP/2 and HTTP/3 to browsers whatever your origin supports, and they serve files from near the visitor. CDN basics explains what a CDN fixes and what it does not.

What HTTP/2 changes in how you build

Some HTTP/1.1 habits hurt on HTTP/2:

• Domain sharding (img1., img2.) forces extra connections and handshakes; consolidate to one host.
• Sprites and inlining save requests that no longer cost much; separate files can be cached separately.
• Bundling everything into one 2 MB JavaScript file means one change invalidates the whole cache; smaller bundles are fine now.
• Preconnecting to every third party. Each extra host is a new connection even on HTTP/2; self-hosting fonts and scripts puts them on the connection you already have.

And one thing stays true: fewer bytes is still faster than fewer requests. HTTP/2 does not make a 1.8 MB image smaller. See image sizes that do not hurt.

Verify

• The ALPN row reads "negotiated h2"; the Alt-Svc row shows h3=":443" if you enabled HTTP/3.
• The http2 finding reports the document over h2 (or h3) and few or no HTTP/1.1 responses.
• In the browser's developer tools → Network, the Protocol column shows h2 or h3 for your files.
• HTTP/3 needs one visit to be advertised and a later connection to be used; browsers cache the Alt-Svc hint.

Common mistakes

• Enabling HTTP/2 on port 80. Browsers ignore it; only the TLS port counts.
• Apache with prefork. Protocols h2 is accepted but HTTP/2 is not used; switch to the event MPM.
• UDP 443 closed. HTTP/3 is advertised, the browser tries QUIC, times out and falls back. Slower than not advertising it.
• Worrying about a proxy in the middle. Varnish or a load balancer speaking HTTP/1.1 to the origin is fine, as long as the edge that talks to browsers speaks h2.
• Expecting a big score jump. HTTP/2 helps pages with many files; a page with one large image and one large script gains little. Fix the bytes too.

Questions people ask

What is HTTP2 and what does it do?

HTTP/2 is the second major version of HTTP, the protocol browsers use to fetch pages and files. It sends all the requests of a page over one connection at the same time (multiplexing) and compresses repeated headers, where HTTP/1.1 fetches one file per connection at a time and queues the rest. Nothing changes in your URLs or content; pages with many files simply load with less waiting. Browsers use it only over HTTPS.

What is HTTP3 and what does it change?

HTTP/3 is the newest version of HTTP, standardised in 2022 as RFC 9114. It works like HTTP/2 but runs over QUIC, a transport on UDP with encryption built in, instead of TCP. That gives a faster connection setup, no stalls for every file when one packet is lost, and connections that survive a switch between Wi-Fi and mobile data. Servers announce it with an Alt-Svc header, and browsers use it from the next connection on.

Is HTTP/2 the same as HTTPS?

No. HTTPS means the connection is encrypted with TLS; HTTP/2 is how requests travel over that connection. You can have HTTPS with HTTP/1.1, which many older servers still use. In practice they go together, because browsers only use HTTP/2 over HTTPS, and HTTP/3 has encryption built into QUIC. So HTTPS comes first: without a certificate, no browser will use HTTP/2 or HTTP/3 with your site.

Does HTTP/2 help SEO?

Not directly. Googlebot has crawled over HTTP/2 since November 2020, and Google said this gives no ranking benefit; it only makes crawling cheaper for both sides. The indirect effect is through speed: if HTTP/2 or HTTP/3 makes pages load faster for real visitors, that improves Core Web Vitals, which Google uses in ranking. Turn it on for visitors, not for rankings.

Is HTTP/2 server push still worth using?

No. Server push let a server send files before the browser asked for them, but it often sent files the browser already had cached and rarely made pages faster. Chrome removed support in 2022 and Firefox in 2024, so pushed files are ignored by most visitors. Use a preload link for files the page needs early, or 103 Early Hints, which tells the browser what to fetch while the server is still building the page.

Do all browsers support HTTP/3?

Current versions of Chrome, Edge, Firefox and Safari all support HTTP/3, so most visitors can use it once your server or CDN advertises it. Browsers always keep HTTP/2 as a fallback: if QUIC is blocked by a firewall, VPN or company network, they connect over HTTP/2 instead. That is why you enable HTTP/3 alongside HTTP/2, never instead of it, and keep UDP port 443 open so the fallback is rare.

Do I still need to bundle files and use sprites on HTTP/2?

Mostly no. Those tricks existed because HTTP/1.1 made every extra request expensive. On HTTP/2 extra requests are cheap, and separate files cache better: change one small script and only that file is downloaded again. Keep some bundling, since hundreds of tiny files still add overhead, but split large bundles by page or feature, drop image sprites and stop sharding files across extra hostnames.