What Is HTTP/2 and HTTP/3? A Practical Guide for WordPress Sites

HTTP/2 and HTTP/3 are the two current versions of the Hypertext Transfer Protocol, the language browsers use to request pages from web servers. HTTP/2 was standardized in 2015 and is supported by 100% of modern browsers. HTTP/3, finalized as RFC 9114 in 2022, is supported by every major browser as of 2024. Both are drop-in upgrades over HTTP/1.1: same URLs, same HTML, but significantly faster page loads, especially on mobile networks and high-latency connections.

Quick answer: which version should my WordPress site use?

In 2026, the right answer is "HTTP/3 with HTTP/2 fallback". Every browser negotiates the highest version both sides support, so you do not have to choose. If your server speaks HTTP/3, modern browsers use it; older browsers fall back to HTTP/2; ancient clients fall back to HTTP/1.1. There is no scenario where HTTP/2 or HTTP/3 is slower than HTTP/1.1 for a real-world WordPress page, so the question is only whether your hosting stack supports it.

What problem does HTTP/2 solve compared to HTTP/1.1?

HTTP/1.1, the protocol that ran the web from 1997 to 2015, has one fatal flaw on a modern site: it opens one TCP connection per resource, and only six in parallel per domain. A typical WordPress page loads 50 to 150 resources (CSS, JS, images, fonts, tracking scripts). Under HTTP/1.1, those 100+ requests serialize through a queue of six connections, each waiting on the previous one to finish. The browser literally sits idle waiting for slots to free up.

HTTP/2 solves this with three changes:

Multiplexing. A single TCP connection carries an unlimited number of parallel request/response pairs (called streams). All 150 resources travel over one connection, interleaved.
Header compression (HPACK). HTTP headers (cookies, User-Agent, referer) often add up to several KB per request. HPACK compresses them and remembers repeated headers, dropping per-request overhead from kilobytes to bytes.
Binary framing. HTTP/1.1 is text-based and ambiguous to parse. HTTP/2 uses a binary frame format that is faster for servers and proxies to process, and eliminates a class of smuggling and parsing attacks.

Net effect: a WordPress page that loads in 4 seconds over HTTP/1.1 typically loads in 1.5 to 2.5 seconds over HTTP/2, on the same server. The improvement is bigger on mobile networks because the connection setup overhead is amortized across all requests.

What does HTTP/3 add on top of HTTP/2?

HTTP/3 keeps everything HTTP/2 introduced (multiplexing, header compression, binary framing) but replaces the underlying transport. Instead of TCP, HTTP/3 runs over QUIC, a transport protocol built on UDP. This sounds like an implementation detail but it fixes three real performance problems:

Head-of-line blocking at the TCP layer. HTTP/2 multiplexes streams over one TCP connection, but TCP itself delivers packets in order. If one packet drops, every stream on that connection stalls until the retransmission arrives. QUIC handles packet loss per-stream, so a single dropped packet only affects the stream it belongs to.
Faster connection setup. Establishing an HTTPS connection over TCP requires three round trips (TCP handshake, then TLS handshake). QUIC combines them into one round trip for first-time connections, and zero round trips for repeat connections within a few minutes (called 0-RTT). On a mobile connection with 100ms latency, this saves 200-300ms before the first byte of content even starts loading.
Connection migration. QUIC connections are identified by a connection ID, not by IP + port. When a phone switches from Wi-Fi to cellular, the QUIC connection survives. TCP connections would have to reconnect.

Real-world gain on top of HTTP/2: typically 5-15% faster for first page loads, more on lossy mobile networks, less on a stable wired connection.

How do I check which HTTP version my WordPress site is currently using?

Four reliable methods, ordered from quickest to most authoritative:

InspectWP report. The Performance section of any InspectWP report lists the HTTP version negotiated for the main document. One line, no setup.
Chrome DevTools. Open DevTools (F12), Network tab, reload the page, right-click any column header and enable "Protocol". The column shows h2 for HTTP/2 and h3 for HTTP/3 (also called http/3 in some Chrome versions).
Command line with curl. Run curl -I --http2 https://yoursite.com for HTTP/2 or curl -I --http3 https://yoursite.com for HTTP/3 (curl 7.66+ required). The response line shows HTTP/2 200 or HTTP/3 200.
Public testing tools. https://http3check.net tests HTTP/3 support specifically. https://tools.keycdn.com/http2-test tests HTTP/2 support. Both return the negotiated version and the Alt-Svc header (which advertises HTTP/3 support).

One gotcha: a site can advertise HTTP/3 in its Alt-Svc header but not actually have HTTP/3 working. The header tells the browser "next time, try HTTP/3 on UDP port 443", but if UDP is blocked anywhere in the path, the browser silently falls back to HTTP/2. Always verify with an actual request, not just the Alt-Svc header.

How do I enable HTTP/2 or HTTP/3 on a WordPress site?

HTTP versions are negotiated at the webserver level. WordPress itself has nothing to do with this; the choice is between your hosting stack and the browser. Three scenarios cover almost all sites:

Scenario 1: managed WordPress hosting

Almost every managed WordPress host (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) has shipped HTTP/2 by default since 2018. HTTP/3 support is now widespread but not universal as of 2026. Kinsta, Cloudways, SiteGround, Raidboxes and Pressable have HTTP/3 enabled by default. WP Engine has it available as a toggle. If your host is not in this list, ask support; it is usually a one-click change.

Scenario 2: shared hosting with cPanel or Plesk

cPanel hosts (IONOS, Hostinger, many resellers) typically ship HTTP/2 by default and HTTP/3 on newer accounts. Check by enabling EasyApache 4 with the mod_http2 module if not already present. HTTP/3 in Apache requires the mod_http3 module which is still considered experimental. The pragmatic path on shared hosting is to put Cloudflare in front (free tier is fine) and let Cloudflare handle HTTP/3 termination, which has been their default since 2019.

Scenario 3: self-managed VPS or dedicated server

The configuration depends on your webserver:

nginx. HTTP/2 needs nginx 1.9.5+ and the http2 directive on your listen line: listen 443 ssl http2;. HTTP/3 needs nginx 1.25+ compiled with QUIC support: listen 443 quic reuseport; listen 443 ssl; plus add_header Alt-Svc 'h3=":443"; ma=86400';. The reuseport flag is critical or HTTP/3 silently fails to start.
Apache. HTTP/2 needs mod_http2 enabled and the directive Protocols h2 h2c http/1.1 in your virtual host. HTTP/3 in Apache is still experimental; most production Apache setups stop at HTTP/2 and put nginx, Caddy or Cloudflare in front for HTTP/3.
Caddy. HTTP/3 is enabled by default since Caddy 2.6. Nothing to configure; if HTTPS works, HTTP/3 works.
LiteSpeed and OpenLiteSpeed. Both ship HTTP/3 by default. This is one reason LiteSpeed has gained share in the WordPress hosting market.

One requirement people miss on self-managed setups: HTTP/3 requires UDP port 443 to be open in your firewall. Many default server configurations only open TCP 443. Run sudo ufw allow 443/udp on Ubuntu or the equivalent for your firewall stack.

What is the role of Cloudflare and other CDNs?

A CDN sitting in front of your origin server typically terminates the modern protocol at the edge, then talks to your origin over HTTP/1.1 or HTTP/2. From the visitor's perspective, the connection to the CDN edge node (often 20-50ms away) is HTTP/3, fast and modern. The link from the CDN to your origin happens server-to-server in datacenter networks where the protocol matters much less. This is why putting Cloudflare in front of a shared host running only HTTP/1.1 still gives most of the speed benefit. The visitor never directly touches your origin.

The catch: if your origin returns a cache-busting header (no-cache, no-store) or your content is uncacheable (logged-in WordPress pages, WooCommerce cart), the CDN has to fetch from origin on every request, and the slow origin-to-CDN hop becomes the bottleneck. For those cases, the protocol on the origin still matters.

Common mistakes and how to avoid them

Treating HTTP/2 as a magic bullet for slow sites. HTTP/2 fixes connection overhead. It does not fix slow PHP, unoptimized queries, 5MB hero images, or render-blocking JavaScript. If your TTFB (time to first byte) is 2 seconds, switching to HTTP/3 saves you 200ms. The other 1800ms are still PHP and database.
Forgetting to keep HTTP/1.1 enabled. Search engine crawlers, monitoring tools, and ancient client libraries sometimes only speak HTTP/1.1. Disabling HTTP/1.1 entirely breaks them. Modern webservers negotiate the highest mutually supported version automatically; keep all three (h3, h2, http/1.1) enabled.
Concatenating and inlining assets out of HTTP/1.1 habit. Under HTTP/1.1, combining 30 CSS files into 1 was a major win because of the connection limit. Under HTTP/2 and HTTP/3, that optimization stops mattering and can even hurt (a single large bundle invalidates the cache for any change; 30 small files invalidate only the ones that changed). Most WordPress performance plugins still default to "combine all" because users expect it, but it is no longer the right default in 2026.
Assuming Alt-Svc means HTTP/3 is working. The header advertises HTTP/3 support; it does not guarantee the connection actually establishes. Always verify with curl or DevTools.
Blocking UDP at the firewall. A common cause of HTTP/3 silently not working. Check both the server firewall and the network firewall (cloud provider security group, ISP-level filtering on consumer connections).

HTTP/2, HTTP/3 and Core Web Vitals

Google's Core Web Vitals measure Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Of the three, LCP is the one most affected by HTTP version. The LCP element (usually the hero image or the largest above-the-fold block) needs to download fully before LCP can be reported, and download speed is exactly what HTTP/2 and HTTP/3 improve. Sites that move from HTTP/1.1 to HTTP/2 see LCP drop by 300-800ms on average. The HTTP/2 to HTTP/3 jump is smaller, typically 50-200ms, but on mobile networks with packet loss it can be larger.

What InspectWP checks

The Performance section of every InspectWP report shows which HTTP version was negotiated for the main document, plus the content encoding (gzip, Brotli) and total HTML size. If your site is still on HTTP/1.1 in 2026, the report flags it as a warning, because it is one of the highest-impact, lowest-effort performance wins available, usually a single switch in the hosting panel. If you are on HTTP/2 but not HTTP/3, that shows as informational; HTTP/3 is the modern default but HTTP/2 is still entirely acceptable. The version your browser sees is the version your visitors get, so the report reflects real-world performance, not theoretical config.