What Is HTTP/2 vs HTTP/3?
HTTP/2 and HTTP/3 are the two newest major versions of HTTP, the protocol browsers use to request web pages and files. HTTP/2 sends many requests and responses in parallel over a single TCP connection (multiplexing) with compressed headers, while HTTP/3 carries the same features over QUIC, a UDP-based transport with TLS 1.3 built in that connects faster and copes better with packet loss and network changes.
What Are HTTP/2 and HTTP/3?
HTTP/1.1, standardised in 1997, can only handle one request at a time per connection, so browsers opened around six parallel connections per host and developers invented workarounds such as image sprites, file concatenation and domain sharding. HTTP/2, published in 2015 and revised as RFC 9113 in 2022, keeps the same methods, status codes and headers but changes how they travel: messages are split into binary frames and interleaved as independent streams on one connection. HTTP/3, published as RFC 9114 in June 2022, keeps that model but replaces TCP with QUIC (RFC 9000). For site owners the differences are invisible in the HTML: the same pages and URLs work over all three versions, and the browser and server agree which one to use when they connect. All major browsers support both HTTP/2 and HTTP/3, but only over HTTPS.
How HTTP/2 and HTTP/3 Work
HTTP/2 opens a single TCP connection per origin and multiplexes every request over it as numbered streams, so a slow response no longer blocks the ones queued behind it at the HTTP level. Headers are compressed with HPACK, which matters because cookies and user-agent strings repeat on every request. The protocol also defined server push, but it proved hard to use well and Chrome removed support in 2022; the 103 Early Hints status with <link rel="preload"> has become the preferred way to start downloads early. HTTP/2 still has one weakness: because TCP delivers bytes strictly in order, a single lost packet stalls every stream on the connection until it is retransmitted (TCP head-of-line blocking). HTTP/3 solves this by running over QUIC, which handles streams independently on top of UDP, so loss on one stream does not hold up the others. QUIC also merges the transport and TLS 1.3 handshakes, so a new connection needs one round trip instead of two or three, and returning visitors can use 0-RTT resumption. Connections are identified by connection IDs rather than IP addresses, which lets a download survive a switch from Wi-Fi to mobile data. Browsers usually discover HTTP/3 through an Alt-Svc: h3=":443" response header or an HTTPS DNS record, so a first visit may use HTTP/2 and later requests switch to HTTP/3.
Best Practices for HTTP/2 and HTTP/3
The simplest route is to put the site behind a CDN or host that already supports both protocols; most major CDNs let you enable HTTP/3 with a single setting. On your own servers, HTTP/2 needs a TLS certificate and, in Nginx, http2 on; in recent versions (or the http2 parameter on the listen directive in older ones). HTTP/3 needs a build with QUIC support (Nginx added it in version 1.25), a listen 443 quic directive, an Alt-Svc header, and UDP port 443 open in the firewall. Once HTTP/2 is live, remove HTTP/1.1 workarounds that now cost more than they save: domain sharding spreads requests over extra connections and defeats multiplexing, and giant concatenated bundles mean one small change invalidates the whole cached file. Moderate bundling is still sensible, because each request carries some overhead. Do not rely on server push; use <link rel="preload"> for critical assets and fetchpriority="high" on the hero image instead. Keep HTTP/1.1 available as a fallback, because some networks block UDP and some clients cannot use QUIC. To check what visitors get, open Chrome DevTools, right-click the Network panel's column headers to show the Protocol column, and look for h2 or h3. Measure the effect with real-user data rather than assumptions: the gains are largest on high-latency or lossy mobile connections and small on fast wired ones.
HTTP/2 vs HTTP/3 and Canvas Builder
HTTP/2 and HTTP/3 are enabled by whoever serves the files, so they apply to Canvas Builder sites in the same way as to any other site. The exported ZIP contains plain HTML, CSS, JavaScript and images that any HTTP/2 or HTTP/3 server can deliver without changes. If you host the export yourself, choose a host or CDN that supports both protocols over HTTPS.
Start building freeFrequently asked questions
Is HTTP/3 faster than HTTP/2?
Often, but not always. HTTP/3 connects in fewer round trips and avoids TCP head-of-line blocking, so it helps most on mobile and high-latency networks where packets are lost. On a fast, stable connection the difference can be small, and where UDP traffic is throttled or blocked, browsers fall back to HTTP/2.
Does HTTP/2 or HTTP/3 affect SEO?
Not directly. Google has said that crawling over HTTP/2 gives no ranking benefit, and the protocol version is not a ranking factor. The indirect benefit is speed: faster delivery can improve Core Web Vitals such as Largest Contentful Paint, which are part of Google's page experience signals.
How do I check whether my site uses HTTP/2 or HTTP/3?
In Chrome DevTools, open the Network panel, enable the Protocol column and reload the page: h2 means HTTP/2 and h3 means HTTP/3. From the command line, curl -I --http2 https://example.com shows the protocol in the status line, and online testing tools can check HTTP/3 support.
Do I need to change my HTML to use HTTP/2 or HTTP/3?
No. The protocols change how requests travel between browser and server, not the content of pages, so the same HTML, CSS and JavaScript work unchanged. Switching is a server or CDN setting.