HTTP/2 is the second major version of the Hypertext Transfer Protocol, finalized as RFC 7540 in May 2015. It was the first significant update to HTTP since HTTP/1.1 was standardized in 1997, and it addressed fundamental performance problems that had plagued the web for nearly two decades. If your WordPress site still serves content over HTTP/1.1, you are likely leaving significant performance gains on the table.
The protocol grew out of Google's experimental SPDY protocol, which had been in use since 2012 and proved that the core ideas behind HTTP/2 (multiplexing, header compression, prioritization) worked well in production. When the IETF standardized HTTP/2, SPDY was retired, and its ideas became the foundation of the new standard.
Key Improvements Over HTTP/1.1
To understand why HTTP/2 matters, you first need to understand what was wrong with HTTP/1.1. Under the old protocol, each TCP connection could only handle one request at a time. If your browser needed to load 40 resources (a typical WordPress page), it had to open multiple connections (browsers typically allow 6 per domain) and queue the remaining requests. This created artificial bottlenecks that slowed down every page load.
HTTP/2 fixes this and more:
Multiplexing: This is the single biggest improvement. HTTP/2 allows multiple requests and responses to be in flight simultaneously over a single TCP connection. Your browser can request your CSS file, three JavaScript files, and ten images all at the same time, over one connection. No more waiting, no more queuing, no more artificial limits. The server sends back responses as they become available, and the browser assembles them. This one change alone can dramatically reduce page load times for resource-heavy WordPress sites.
Header compression (HPACK): HTTP headers are sent with every single request and response. In HTTP/1.1, these headers are plain text and often repetitive. The same cookies, user-agent strings, and accept headers are sent over and over. HTTP/2 uses a compression algorithm called HPACK that maintains a shared table of common header fields between the client and server. After the first request, subsequent headers only need to send the differences. For a WordPress site that loads 50+ resources per page, this can save tens of kilobytes per page load.
Binary framing: HTTP/1.1 is a text-based protocol, which means the parser needs to scan for line breaks, handle different text encodings, and deal with various edge cases. HTTP/2 uses a binary framing layer that wraps all communication in well-defined frames. Binary data is faster to parse, less error-prone, and more compact. You will never notice this as a user, but it reduces processing overhead on both the server and client.
Stream prioritization: HTTP/2 lets the browser tell the server which resources are more important. For example, the browser can signal that the main CSS file should be delivered before background images. The server can then allocate bandwidth accordingly. In practice, browser implementations of prioritization vary, and not all servers handle it perfectly, but it still provides meaningful improvements for many sites.
Server Push: This feature allows the server to send resources to the browser before the browser even requests them. When the browser asks for an HTML page, the server can push the CSS and JavaScript files it knows the browser will need next. This eliminates the round-trip delay of the browser discovering it needs a resource, then requesting it. However, Server Push has seen limited adoption in practice. It is tricky to implement correctly (pushing resources the browser already has cached wastes bandwidth), and some CDNs have deprecated support for it. Chrome removed Server Push support in version 106 (2022). The concept lives on in the 103 Early Hints mechanism, which is simpler and more practical.
Why Domain Sharding Is No Longer Needed
In the HTTP/1.1 era, web developers used a trick called domain sharding to work around the 6-connections-per-domain limit. They would serve images from img1.example.com, CSS from cdn.example.com, and fonts from yet another subdomain. This multiplied the number of parallel connections the browser could open.
With HTTP/2, domain sharding is not only unnecessary but actually counterproductive. Because HTTP/2 multiplexes all requests over a single connection, splitting resources across multiple domains forces the browser to establish additional TCP connections and TLS handshakes. Each new connection adds latency. A WordPress site that was optimized with domain sharding for HTTP/1.1 should consolidate its resources onto fewer domains when switching to HTTP/2.
Similarly, concatenating CSS and JavaScript files into single bundles (another common HTTP/1.1 optimization) becomes less important with HTTP/2. Sending many smaller files works efficiently thanks to multiplexing, and it has the added benefit of better caching: when one small file changes, only that file needs to be re-downloaded, not the entire concatenated bundle.
HTTP/2 Requires HTTPS in Practice
The HTTP/2 specification does not technically require encryption. You can have HTTP/2 over plain TCP (called h2c, for HTTP/2 cleartext). However, every major browser (Chrome, Firefox, Safari, Edge) has decided to only implement HTTP/2 over TLS (called h2). This means that for all practical purposes, you need an SSL/TLS certificate to use HTTP/2.
This is not really a limitation anymore. Free certificates from Let's Encrypt have made HTTPS accessible to everyone, and most WordPress hosting providers include SSL certificates in their plans. If your WordPress site is still on plain HTTP, switching to HTTPS is a prerequisite for HTTP/2, and it brings its own security benefits.
HTTP/3 and QUIC: The Next Step
HTTP/3 (RFC 9114, finalized June 2022) is the next evolution. While HTTP/2 runs on top of TCP, HTTP/3 replaces TCP entirely with a new transport protocol called QUIC. QUIC is built on UDP and incorporates TLS 1.3 encryption directly into the transport layer. The key advantages of HTTP/3 over HTTP/2 are:
- Faster connection setup: QUIC combines the TCP handshake and TLS handshake into a single round-trip, reducing connection setup time. For returning visitors, it can even achieve zero round-trip connection resumption.
- No head-of-line blocking: in HTTP/2 over TCP, if a single packet is lost, all streams on that connection stall until the packet is retransmitted. QUIC handles packet loss on a per-stream basis, so one lost packet only delays the affected stream, not everything else.
- Better mobile performance: QUIC handles network changes (like switching from WiFi to cellular) more gracefully because connections are identified by a connection ID rather than by IP address and port.
Major CDN providers like Cloudflare and Fastly already support HTTP/3. Most hosting providers are still in the process of adopting it. For WordPress site owners, HTTP/3 support is largely a server-side concern; you do not need to change anything in WordPress itself.
How to Check if Your Host Supports HTTP/2
There are several ways to verify whether your WordPress site is served over HTTP/2:
- Browser DevTools: open the Network tab in Chrome DevTools, right-click the column headers, and enable the "Protocol" column. You should see
h2for HTTP/2 requests. - Online tools: sites like KeyCDN's HTTP/2 test or the HTTP/2 checker at tools.keycdn.com can verify HTTP/2 support for any URL.
- Command line: run
curl -I --http2 -s https://yoursite.comand look forHTTP/2 200in the response. - InspectWP: the report includes the detected HTTP version for your WordPress site.
If your host does not support HTTP/2, placing a CDN like Cloudflare in front of your site can provide HTTP/2 (and HTTP/3) support even if your origin server only speaks HTTP/1.1. The CDN handles the HTTP/2 connection with the visitor's browser and communicates with your origin server using whatever protocol it supports.
WordPress Performance Implications
A typical WordPress page loads between 20 and 80 individual resources: stylesheets from the theme and plugins, JavaScript files, web fonts, images, and sometimes external resources from CDNs and third-party services. Under HTTP/1.1, loading all these resources was the single biggest contributor to page load time because of the connection and queuing limitations.
After switching to HTTP/2, most WordPress sites see meaningful improvements in Time to First Contentful Paint and overall page load time. The exact improvement depends on how many resources your site loads, but reductions of 20-50% in load time are common for sites that were previously on HTTP/1.1. Sites with many small resources (which is typical for WordPress with multiple active plugins) benefit the most.
Keep in mind that HTTP/2 does not replace other performance optimizations. You still need proper caching, image optimization, and efficient code. But HTTP/2 removes a significant infrastructure-level bottleneck that no amount of WordPress plugin optimization can fix.
What InspectWP Checks
InspectWP detects the HTTP protocol version used by your WordPress site by examining the response headers. If your site is served over HTTP/1.1, the report flags this as a performance concern and recommends upgrading to HTTP/2. If HTTP/2 or HTTP/3 is detected, it is reported as a positive finding. The HTTP version is displayed in the performance section of the report, alongside other server-level metrics like compression and response headers.