What Is HTTP/2? How to Check It and Enable It on Your Site

What Is HTTP/2 and Where Did It Come From?

What is HTTP/2, in plain terms? Think of HTTP as the language a browser and a web server speak to swap pages, images and scripts. HTTP/2 is the revision that followed HTTP/1.1, and it keeps the vocabulary you already know: the same methods such as GET and POST, the same status codes such as 200 and 404, the same headers and the same URLs, so a request for /about still returns a 200 with the same Content-Type header. Only the packing changes, meaning how the messages travel between the two machines. Your HTML, links and canonical tags stay as they were. Turning it on is a server setting, not a rebuild.

You will run into a few labels in tools and logs. The name h2 means HTTP/2 running over TLS, which is the version every browser uses. The name h2c means HTTP/2 in cleartext with no encryption, and browsers do not use it, so you can ignore it for website work. HTTP/1.1 is the older version that most servers still fall back to whenever the visitor's software or the connection setup cannot manage h2. Search queries and some tools write it as HTTP2 without the slash, which names the same protocol.

From SPDY to RFC 9113

It began as SPDY, a Google experiment aimed at cutting page load time, which Chrome supported early on. The IETF took that work as its starting point and published HTTP/2 as RFC 7540 in May 2015. In June 2022 a clearer rewrite, RFC 9113, replaced it and made the older document obsolete. The core design stayed the same, so a guide that cites either number is describing the protocol you are enabling today.

What changed on the wire

HTTP/1.1 sends readable text lines, and each connection carries one request at a time. HTTP/2 uses binary framing, which splits every request and response into small frames, and each frame is tagged with a stream number. Many streams share a single TCP connection to an origin, and the receiving side puts the frames back together. A packet capture is no longer readable by eye, but DevTools hides all of this and shows you the same headers either way.

How HTTP/2 Differs From HTTP/1.1 and Why It Loads Pages Faster

The practical difference is how many things can happen at once. The table below sets the two versions side by side on the points that affect a real page load.

Multiplexing is the headline feature. In HTTP/1.1 a browser that wants forty files has to queue them across a handful of connections, so one slow response stalls everything behind it on that connection. A 400 KB hero image, for example, can hold up the stylesheet queued right behind it. HTTP/2 lets all forty requests travel at once, and the server answers them as each becomes ready. The old queue disappears, and that is where most of the gain comes from.

Header compression comes second. HPACK header compression, defined in RFC 7541, keeps a table of headers that both sides have already seen, so a long cookie or user agent string is sent in full once and then referenced by a short index. On a page with dozens of requests to the same host, that saves a real amount of upload traffic. HTTP/2 also lets the browser signal which streams matter most, such as render blocking CSS. The original weighting scheme was deprecated in RFC 9113, and how much a server honors priority hints varies, so treat it as a small bonus.

Server push is the feature to skip. A server could send a stylesheet before the browser asked, but it often wasted bandwidth on files the visitor had cached. Chrome turned push off by default in version 106, so do not plan around it.

What the speed gain looks like

A page with 80 small assets viewed over mobile data gains the most, because latency dominates and multiplexing hides it. A single large download gets little from HTTP/2 because there is nothing to multiplex. TCP is still underneath, so head of line blocking remains: one lost packet stalls every stream until it is resent.

For SEO: according to Google's documentation, its crawlers support both HTTP/1.1 and HTTP/2 and pick whichever gives the best crawling performance, with HTTP/1.1 as the default. Crawling over HTTP/2 may save your server some CPU and memory, but Google says it gives no ranking benefit. The real payoff is a faster page for people, which supports your Core Web Vitals.

You can read the details in the Google crawler documentation. Once HTTP/2 is on, old workarounds such as sprites stop paying off. Our guide on how to reduce HTTP requests explains which request habits still matter, because fewer and lighter files load faster over any protocol.

How SEO Site Checker Tests for HTTP/2

Our scanner does not download your page to find out. It opens a connection to port 443 of the host you scanned, from the scanner itself and outside the headless browser that renders your page, and it gives the server 3 seconds to respond. During the secure TLS handshake it offers two protocols, h2 and http/1.1, through a step called ALPN (application layer protocol negotiation). The server then names the one it wants to use, and the scanner reads that answer. The handshake is verified, which means the certificate has to be trusted, unexpired and valid for the host name. Nothing is guessed from headers.

Because no page is requested, redirects play no part and the path and any trailing slash are ignored. If you type an address that begins with http://, the report still tests port 443 of that same host name.

Our rule: the HTTP2 Test row passes only when the server selects h2. The row then shows Passed, the value HTTP/2 and a message saying the page is using the HTTP/2 protocol. Any other outcome fails.

Any outcome other than h2 fails: an http/1.1 answer, a failed certificate check, a refused connection, a timeout or any other error. The row shows the same red message for all of them, which is a limit of the row and not a hint about the cause. To tell them apart, run the curl command in the next section. It prints the real version when the connection works and shows an error message when the connection or the certificate is the problem. Also remember that the host tested is the one you scanned, so an apex address that redirects to a CDN fronted www address is judged on the apex, not on wherever the redirect lands.

Re-run before you edit: a slow or overloaded server can miss the 3 second limit while still supporting HTTP/2 when it is not busy. Run the free report a second time, and run the curl test below, before you touch a config file. Reports generated before the check was rebuilt in October 2026 may also show a failed row for a site that does support HTTP/2, so scan again to get a current result.

• Pass: the server selects HTTP/2 (h2) during the TLS handshake on port 443.
• Fail: the server selects http/1.1, the verified handshake fails, the connection is refused, it times out after 3 seconds, or any other error occurs.
• Not tested: any page or file (only the TLS handshake to the main host is checked), files served from other hosts, HTTP/3, h2c, and whether a CDN or your origin answered.

Run the free SEO report

How to Check If Your Website Uses HTTP/2

One tool can mislead you, so confirm the result in a second place. Two checks confirm the protocol, and a third header check shows whether HTTP/3 is also offered. All of them take about two minutes.

1. Look in your browser. Open Chrome DevTools, go to the Network tab, right click any column header and tick Protocol, then reload the page. A value of h2 on the first document row means HTTP/2, while http/1.1 means it is not in use. If you see h3, the browser used HTTP/3 because the server advertised it. That almost always means HTTP/2 is available too, because HTTP/3 deployments keep h2 as the fallback, but confirm it with the curl command below.
2. Ask curl. Run the command shown below from a terminal. It prints the negotiated version, so you see 2 for HTTP/2 and 1.1 for the older protocol, along with the time the request took.
3. Read the response headers for HTTP/3. This one does not test HTTP/2 itself. An alt-svc header that mentions h3 means the server also advertises HTTP/3. That is a bonus on top of HTTP/2 and not a replacement for it.

# Prints the negotiated HTTP version and total time
curl -sS -o /dev/null --http2 --max-time 10 -w "version %{http_version} in %{time_total}s\n" https://example.com/

# Shows whether HTTP/3 is advertised
curl -sI https://example.com/ | grep -i alt-svc

Because that first command asks for HTTP/2 without forcing it, the version curl prints is the protocol the server really chose. A 2 means HTTP/2 and 1.1 means the server, or something in front of it, declined to negotiate it. A 0 with an error message means the connection or certificate failed, so that is not a protocol problem.

Keep one trap in mind. A CDN or proxy can speak HTTP/2 to your visitors while your origin server still talks HTTP/1.1 behind it. What you see in DevTools, curl and our report is the front door, meaning whoever answers the public hostname, and all three methods measure that same front door. A good CDN usage test tells you whether such a layer exists, and in that case enabling HTTP/2 at the CDN is what changes the result.

How to Enable HTTP/2 on Nginx and Apache

Browsers use HTTP/2 only over HTTPS, so you need a working certificate on a server whose TLS library supports ALPN, which means OpenSSL 1.0.2 or newer. If HTTPS is not sorted yet, start with our HTTPS encryption guide. In both cases the safe routine is the same: change the config, test the syntax, reload the server and then run the check again. Always test first: a broken config can stop Apache from restarting, and on Nginx the reload simply fails and leaves you thinking the change applied.

Nginx

Support lives in the ngx_http_v2_module, which most distribution packages include. Run nginx -v to see your version. If you compile Nginx from source, build it with --with-http_v2_module, which nginx -V will confirm. From version 1.25.1 onward, HTTP/2 is a separate directive: keep the normal listen line and add http2 on; inside the HTTPS server block. The Nginx HTTP/2 module reference documents it in full.

# /etc/nginx/sites-available/example.conf (HTTPS server block only)
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
}

On Nginx older than 1.25.1, put the parameter on the listen line instead, as in listen 443 ssl http2;. Newer releases still accept that form but treat it as deprecated. Run nginx -t to check the syntax, then reload with sudo systemctl reload nginx. Do not add http2 to the port 80 block that redirects to HTTPS, because browsers never use cleartext HTTP/2 and the setting would achieve nothing.

Apache

You need Apache 2.4.17 or newer with mod_http2, which in turn relies on the libnghttp2 library. The command apache2ctl -v shows your version. The official Apache HTTP/2 guide lists the requirements and the Protocols directive. On Debian and Ubuntu, enable the module with a2enmod, and then add the Protocols line inside the HTTPS virtual host, as the second block shows.

sudo a2enmod http2
sudo apache2ctl configtest
sudo systemctl restart apache2

<VirtualHost *:443>
    ServerName example.com
    Protocols h2 http/1.1
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example/privkey.pem
</VirtualHost>

List h2 first, because the order in the Protocols line sets the preference. Keeping http/1.1 after it lets older clients connect normally. Prefer the event MPM too. Under prefork, requests on one connection are handled one at a time, which weakens the benefit, and switching away from prefork usually means moving PHP from mod_php to PHP-FPM. After the restart, run the check again.

Turn On HTTP/2 on a CDN, Shared Hosting or IIS

Not everyone can edit server files. These are the usual routes when someone else controls the machine, and the hosting checker will tell you which provider runs your site before you contact them.

• Content delivery networks. Most edge networks, Cloudflare among them, offer HTTP/2 to visitors by default or behind a single dashboard switch. The CDN answers the browser even when your origin is old, which is usually the quickest way to get a pass.
• Shared hosting and control panels. LiteSpeed and recent cPanel stacks normally enable it once HTTPS is active. If your report still fails, ask the host which web server version and PHP handler your plan uses.
• WordPress. There is nothing to install, because HTTP/2 is a server matter. Ask your host and ignore plugins that promise to turn it on.
• Microsoft IIS. HTTP/2 arrived with Windows Server 2016 and IIS 10, and it works over HTTPS only.

Why Your Site Still Shows HTTP/1.1 After You Enabled It

When the setting seems to do nothing, the cause is almost always one of the items below. Work through them in order, because the early ones are the most common.

• The config was never reloaded. A saved file changes nothing until the server reloads, so run the syntax test and then the reload command, and confirm the service came back up.
• The directive is in a different server block than the one answering your domain. On Nginx, run nginx -T to print the full merged configuration and find the block whose server_name matches your hostname, then make sure http2 on; is in that block. Before 1.25.1 the setting came from the listen line and applied to the whole address and port, so check every listen line for port 443.
• The page is served over plain HTTP. If the certificate is missing or the chain is broken, the browser never negotiates h2. Check the https:// address directly, because an http:// request can only ever answer over HTTP/1.1. Our HSTS guide covers the next hardening step once HTTPS is solid.
• The TLS library is too old. Without OpenSSL ALPN support, the handshake cannot agree on h2 and the connection quietly stays on HTTP/1.1, a plain fallback with no error shown.
• A proxy sits in front. A reverse proxy, load balancer or security layer can speak HTTP/1.1 to visitors even though your origin supports h2. A DNS record lookup shows whether the hostname points at a CDN instead of your server.
• A weak cipher suite is allowed. HTTP/2 rejects a list of older TLS 1.2 ciphers (RFC 9113 section 9.2.2 names them). Apache's documentation warns that a browser may then fall back to HTTP/1.1, while a server that forces h2 anyway makes Chrome show ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY instead of a quiet downgrade.
• Chrome shows an HTTP/2 error name. ERR_HTTP2_PROTOCOL_ERROR points to a proxy or server that broke the protocol rules, so look at what sits between the visitor and the origin. ERR_HTTP2_SERVER_REFUSED_STREAM is a server limit problem and not a missing feature, which the FAQ below explains.