Check if your server supports HTTP/2

SiteCurl connects to your server over TLS and checks which HTTP protocol it supports using ALPN (Application-Layer Protocol Negotiation). If the server responds with h2, it supports HTTP/2. If it responds with http/1.1, it does not.

The check requires HTTPS. HTTP/2 is only available over encrypted connections. If your site uses plain HTTP, SiteCurl skips this check and notes that HTTPS is needed first.

The connection test has a 5-second timeout. If your server does not respond in time, SiteCurl reports that HTTP/2 support could not be determined rather than marking it as a failure.

HTTP/1.1 has a fundamental limitation: one request per connection at a time. If your page needs 20 files (CSS, JS, images), the browser opens multiple connections and queues requests. Each connection has setup overhead: DNS lookup, TCP handshake, TLS negotiation. That overhead adds up, especially on mobile networks.

HTTP/2 fixes this by multiplexing. One connection carries all requests at the same time. The browser asks for 20 files, and they all travel over the same connection in parallel. No queuing, no extra handshakes. The result is faster page loads, particularly for pages with many assets.

HTTP/2 also compresses headers. In HTTP/1.1, every request sends the full set of headers (cookies, user-agent, accept) as plain text. On a page with 30 requests, the same headers are sent 30 times. HTTP/2 compresses them and only sends the differences between requests, saving bandwidth on every page load.

Most modern servers and CDNs support HTTP/2 by default. If your server still uses HTTP/1.1, it is likely running an older config or a hosting provider that has not updated. The fix is usually a setting change, not a code change.

Pages with many assets load measurably faster over HTTP/2. A typical page loads 20-50 resources. Under HTTP/1.1, browsers open 6 connections and queue the rest. Under HTTP/2, all resources flow over one connection in parallel. The difference is most visible on high-latency connections.

Mobile visitors benefit the most. Mobile networks have higher latency than wired connections. Each new TCP connection adds 50-200ms of overhead. HTTP/2 eliminates most of those extra connections, shaving hundreds of milliseconds off mobile page loads.

HTTP/2 is also a signal of server maintenance. Hosts that still serve HTTP/1.1 in 2026 are running outdated setups. That can raise questions about other aspects of site security and upkeep.

Sites hosted on older or self-managed servers are the most likely to lack HTTP/2. Shared hosting plans from smaller providers may still default to HTTP/1.1. If you manage your own Nginx or Apache install, you may need to enable HTTP/2 manually.

Sites with many assets per page (images, scripts, stylesheets, fonts) see the biggest gains from HTTP/2. A minimalist site with 3 resources notices less difference than a page loading 30.

Agencies that manage client sites across different hosts should check each client's protocol support. A client on a modern CDN likely has HTTP/2 already. A client on a legacy shared host may not.

Step 1: Check your current protocol. Run a SiteCurl scan or use your browser dev tools. In Chrome, open the Network tab, right-click the column headers, and enable 'Protocol.' Reload the page and check the protocol column for each request.

Step 2: Enable HTTP/2 on Nginx. In your server block, change the listen directive to: listen 443 ssl http2;. Restart Nginx with nginx -s reload. This requires Nginx 1.9.5 or later.

Step 3: Enable HTTP/2 on Apache. Load the mod_http2 module and add Protocols h2 http/1.1 to your virtual host config. Restart Apache. This requires Apache 2.4.17 or later.

Step 4: Use a CDN that supports HTTP/2. Cloudflare, AWS CloudFront, Fastly, and Vercel all serve HTTP/2 by default. Putting a CDN in front of your server gives you HTTP/2 without changing your server config. The CDN handles the browser connection while talking to your origin over whatever protocol it supports.

Step 5: Verify HTTPS is active. HTTP/2 requires HTTPS. If your site does not have a valid SSL certificate, fix that first. See the SSL certificate check page for details.

Enabling HTTP/2 without HTTPS. Browsers only use HTTP/2 over encrypted connections. If your site serves HTTP (no S), enabling HTTP/2 on the server has no effect. Set up HTTPS first.

Assuming your CDN handles it. Most CDNs do support HTTP/2, but check that it is enabled in your CDN settings. Some setups proxy requests back to HTTP/1.1 on the origin, which is fine. The important thing is the connection between the browser and the CDN.

Not testing after server updates. Server package updates can reset config files. After any major update to Nginx or Apache, verify that HTTP/2 is still enabled by checking the protocol in your browser dev tools.

Bundling all assets into one file. Under HTTP/1.1, bundling reduced connection overhead. Under HTTP/2, multiplexing makes many small files just as fast as one large bundle. If you already use HTTP/2, aggressive bundling may not help and can hurt caching (one changed module invalidates the entire bundle).

After making changes, run another SiteCurl scan. The HTTP/2 finding should show that your server supports h2. You can also check in Chrome: open dev tools, go to the Network tab, add the Protocol column, and reload. Every request should show h2 instead of http/1.1.

For a command-line check, run: curl -sI --http2 https://yoursite.com and look for HTTP/2 200 in the first line of the response.

HTTP/2 lets browsers download all your page's files over one connection instead of queuing them across many. Most modern hosts and CDNs support it by default. If your server still uses HTTP/1.1, enabling HTTP/2 is usually a single config change that speeds up every page on your site.