Is HTTPS really essential for leveraging HTTP/2 and boosting performance?

Why is HTTPS technically required for HTTP/2?

The HTTP/2 specification itself does not formally mandate HTTPS as a prerequisite. It is a decision made by browser vendors who have chosen to implement HTTP/2 only over an encrypted TLS layer. Chrome, Firefox, Safari—all refuse cleartext HTTP/2.

In practical terms, if your site remains on HTTP, the browser automatically negotiates HTTP/1.1, regardless of whether your server supports HTTP/2. You then lose multiplexing, HPACK header compression, Server Push, and all optimizations that reduce latency. For a modern site with 50+ resources per page, the performance difference is measurable.

What concrete gains does HTTP/2 provide compared to HTTP/1.1?

HTTP/2 allows multiple requests to be sent in parallel over a single TCP connection, whereas HTTP/1.1 enforces a limited pipeline that forces browsers to open 6-8 simultaneous connections. Multiplexing eliminates head-of-line blocking at the application level.

Header compression via HPACK drastically reduces the verbosity of exchanges — particularly useful when each request carries cookies several kilobytes in size. The theoretical Server Push (rarely used in practice) allowed sending resources even before the browser requested them, but its implementation proved problematic and Chrome abandoned it.

Does this HTTPS requirement directly affect Google ranking?

HTTPS has been a confirmed ranking signal since 2014, but its weight remains low. The primary impact is not the direct

Is this statement consistent with real-world observations?

Absolutely. Data shows that over 95% of Chrome traffic is now HTTPS, and this migration coincides with the massive adoption of HTTP/2. Google has been pushing HTTPS for a decade through multiple signals: the "Not Secure" badge in Chrome, the ranking signal, and warnings from Search Console.

What's interesting is that Google presents HTTPS here as a technical prerequisite for performance, not just for security. This is a narrative shift — the argument no longer relies on data protection but on the ability to deliver a fast experience. And that directly impacts business KPIs: conversion, engagement, revenue.

What nuances should we add to this statement?

Google says "higher-performing protocols like HTTP/2," but omits to clarify that HTTP/2 is not always faster in every context. On very high-latency connections or those with significant packet loss, TCP head-of-line blocking can negate the gains of multiplexing. This is, in fact, what motivated HTTP/3 and QUIC.

Another point: Server Push, initially presented as a major advantage of HTTP/2, proved difficult to master and Chrome removed it in 2022. The real gains from HTTP/2 stem largely from multiplexing and header compression — not from flashy features that made it into conference slides. [To be verified] for each use case: measure before/after, don’t rely solely on assumptions.

Are there cases where remaining on HTTP/1.1 is acceptable?

In public production? No. But in local development environments or on intranets without performance constraints, HTTP cleartext simplifies debugging and avoids certificate management. Some proxy or interception tools work better without TLS.

For an e-commerce site, media platform, or SaaS—essentially anything aiming for organic traffic—staying on HTTP is a technical and SEO abomination. You're voluntarily depriving yourself of 20-30% of performance on loading metrics, and displaying a "Not Secure" warning that damages user trust. No commercial argument holds up against this fact.

What concrete steps should be taken to migrate to HTTPS and HTTP/2?

First, obtain a valid TLS certificate. Let’s Encrypt offers free certificates with automatic renewal, eliminating the cost excuse. Install the certificate on the web server, then force all URLs to HTTPS via 301 permanent redirects from the HTTP versions.

Next, enable HTTP/2 in the server configuration. On Nginx, add listen 443 ssl http2; in the server block. On Apache 2.4.17+, load mod_http2 and add Protocols h2 http/1.1. Ensure the CDN (Cloudflare, Fastly, etc.) is properly negotiating HTTP/2 with clients — most do so by default.

What mistakes should be avoided during the HTTPS migration?

The classic error: migrating the site to HTTPS but forgetting to update internal resources (images, CSS, JS) that remain called over HTTP. The result: mixed content, warnings in the console, and resources blocked by modern browsers. Scan all the HTML to catch any remaining src="http:// references.

Another pitfall: not configuring HSTS (HTTP Strict Transport Security) after the migration. Without HSTS, each first visit still goes through HTTP before redirecting, creating a potential attack window and unnecessarily slowing down the first request. Add a header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload as soon as the migration is stable.

How can we verify that HTTP/2 is actually working?

Open the Chrome DevTools, go to the Network tab, and check the Protocol column — it should display h2 for resources served over HTTP/2. If it shows http/1.1, either the server does not support HTTP/2, or TLS is not active, or the browser is not negotiating the protocol.

Also test with tools.keycdn.com/http2-test or CDN diagnostic tools. Verify that the TLS certificate is valid (not expired, no domain mismatch) and that the certificate chain is complete. A poorly configured certificate prevents HTTP/2 negotiation and degrades user experience.

• Obtain and install a valid TLS certificate (Let's Encrypt recommended for automating renewal)
• Configure the web server (Nginx, Apache) to enable HTTP/2 on port 443
• Redirect all HTTP URLs to HTTPS with permanent 301 redirects
• Scan and correct mixed content resources (images, scripts, styles called over HTTP)
• Enable HSTS with a high max-age and preload to enforce HTTPS on all future visits
• Check in DevTools that the h2 protocol is properly negotiated for main resources