Most of the web runs on a protocol that was designed in 1997. HTTP/1.1 has served us remarkably well for nearly three decades, but it was never built for the complexity of modern websites - pages that routinely make 80 to 100 separate requests to load fonts, scripts, stylesheets, images, and tracking pixels. HTTP/2 was designed to fix that, and understanding it helps explain why your server choice and HTTPS setup matter more than you might think.
The Problem with HTTP/1.1
To understand what HTTP/2 fixes, you need to understand how HTTP/1.1 works.
When a browser loads a webpage, it discovers all the resources that page needs - images, CSS files, JavaScript files, fonts - and requests them from the server. Under HTTP/1.1, each request-response cycle happens sequentially over a single connection. The browser can open multiple parallel connections (usually six per domain), but each connection handles only one request at a time.
This creates a problem called head-of-line blocking. If a large JavaScript file is loading on connection one, nothing else can use that connection until the file finishes. The browser opens more connections, but there are limits, and each new TCP connection has its own setup overhead.
For modern websites with dozens of resources, this is like trying to stock a grocery store by making a separate trip to the warehouse for each individual item.
What HTTP/2 Changes
HTTP/2 addresses the fundamental architecture of HTTP/1.1 with three major improvements.
Multiplexing
HTTP/2 allows multiple requests and responses to travel simultaneously over a single connection. A browser can request the CSS file, the hero image, three fonts, and two JavaScript files all at once, and the server can send them back interleaved over the same connection. Head-of-line blocking is eliminated at the HTTP layer.
This is the biggest practical gain. Sites with many small resources - which describes virtually every modern website - see the most improvement.
Header Compression
Every HTTP request includes headers: the browser telling the server what it wants, what cookies it has, what content types it accepts, and so on. In HTTP/1.1, these headers are sent as plain text with every single request, even when they are identical to the last request. On a page with 80 requests, this is a surprising amount of redundant data.
HTTP/2 uses a compression algorithm called HPACK that compresses headers and allows both sides to maintain a shared dictionary of header values they have already seen. Subsequent requests only need to send the changes - dramatically reducing overhead.
Server Push
HTTP/2 allows the server to proactively send resources the browser has not asked for yet. If the server knows that every request for index.html will be followed by a request for main.css, it can push main.css before the browser even knows it needs it.
In practice, server push has proven less impactful than multiplexing and is less commonly used - browsers have become better at preloading resources through HTML hints, which is often more controllable.
Do You Need to Do Anything?
For most website owners on a modern hosting provider: no. HTTP/2 is supported at the server level and enabled automatically.
The one firm requirement is HTTPS. While the HTTP/2 specification technically allows unencrypted HTTP/2, no major browser implements it - they only use HTTP/2 over TLS. In practice, HTTP/2 means HTTPS.
If your site has an SSL certificate and you are on a host that supports HTTP/2 (like dotCanada, which enables HTTP/2 across all plans), you are already using it.
How to Verify HTTP/2 Is Active
You can confirm in a few ways:
- Open Chrome DevTools, go to the Network tab, reload your page, and look at the "Protocol" column. You should see
h2for HTTP/2 requests. - Use KeyCDN's HTTP/2 test tool at tools.keycdn.com/http2-test - enter your domain and it will confirm whether HTTP/2 is enabled.
- In GTmetrix's waterfall view, HTTP/2 requests are grouped together visually because they share a single connection.
What About HTTP/3?
HTTP/3 is the next generation, replacing TCP with a protocol called QUIC. It solves remaining head-of-line blocking issues at the transport layer and is particularly beneficial on unstable connections. Support is growing, and dotCanada is actively evaluating HTTP/3 deployment.
For now, if your site is on HTTPS with a host that supports HTTP/2, you are in good shape. Focus your performance efforts on image optimization, caching, and reducing unnecessary JavaScript - those will move your numbers more than any protocol-level tuning.
