Why has HTTPS become essential for speeding up your web pages?

What is the technical link between HTTPS and HTTP/2?

HTTP/2 is a major revision of the HTTP protocol that drastically improves performance: multiplexing requests over a single TCP connection, HPACK header compression, server push, resource prioritization. However, modern browsers (Chrome, Firefox, Safari, Edge) have all decided to implement HTTP/2 only with TLS — so only HTTPS.

Technically, the HTTP/2 protocol can operate in clear text (h2c), but no mainstream browser supports it. Google and other publishers made this choice to enforce the adoption of encryption, considering that performance gains should go hand in hand with security. The result: a site on HTTP remains stuck on HTTP/1.1, with all its limitations (sequential connections, header overhead, accumulated latency).

Why is Google emphasizing this point now?

This statement is part of Google's long-term strategy to push the entire web towards HTTPS. As early as 2014, HTTPS became a light ranking factor. In 2018, Chrome began displaying “Not secure” on HTTP sites. The argument for performance via HTTP/2 is an additional leverage: it’s no longer just a matter of security or user trust, it’s a technical prerequisite to avoid being handicapped in loading speed.

The Core Web Vitals (LCP, INP, CLS) are directly impacted by network latency and resource loading times. HTTP/2 reduces these latencies. A site that remains on HTTP/1.1 falls behind on these metrics, and Google is well aware of this. By linking HTTPS to HTTP/2, Google creates a clear economic incentive: migrate or lose competitiveness.

Have all sites actually switched?

No. Despite a growing adoption rate, there are still sites using plain HTTP — often legacy sites, intranets, or small sites managed without technical expertise. Some poorly configured CMS, low-cost hosting, and corporate sites that have been stagnant for years are lagging behind. Google mentions a “higher adoption rate year over year,” meaning that the movement is massive, but not universal yet.

For crawling, Googlebot has supported HTTP/2 since 2020. Thus, sites with HTTPS + HTTP/2 can theoretically benefit from more efficient crawling (fewer TCP connections to open, less latency per request). However, Google has never published specific figures on the actual impact of HTTP/2 on crawl budget — it remains a gray area.

• HTTPS is mandatory to enable HTTP/2 in all modern browsers.
• HTTP/2 provides measurable gains in loading speed and potentially in crawling.
• A site in HTTP/1.1 suffers a technical handicap against competitors in HTTP/2.
• Google uses this argument to accelerate the widespread migration to HTTPS.
• Not all sites have migrated yet, but technical and SEO pressure is increasing.

Is this statement consistent with field observations?

Yes, and it’s even one of the few statements from Google that perfectly aligns with technical reality. Laboratory performance tests (WebPageTest, Lighthouse) consistently show loading time gains of between 10 and 30% when moving from HTTP/1.1 to HTTP/2, with equal configuration. Multiplexing eliminates the problem of head-of-line blocking at the HTTP level, and HPACK compression drastically reduces the weight of headers on sites with many requests (media, ads, analytics).

From an SEO perspective, sites that have migrated to HTTPS + HTTP/2 often notice an improvement in their LCP (Largest Contentful Paint), especially on mobile. But beware: HTTP/2 alone doesn’t perform miracles. If the server is slow, if resources are not optimized, if the front end is poorly coded, HTTP/2 won’t compensate. It’s a performance multiplier, not a magic fix.

What nuances should be added to this claim?

Google implies that HTTPS + HTTP/2 is a winning combo, but it doesn’t say it’s sufficient. HTTP/3 (QUIC) is already supported by Chrome, Firefox, and Edge, and is starting to roll out on the server side (Cloudflare, Fastly, Google Cloud). HTTP/3 resolves head-of-line blocking at the TCP level by switching to UDP and brings additional gains on connections with high latency or packet loss. A site that has just migrated to HTTP/2 could already be behind on the next wave. [To be verified]: Google has not communicated whether HTTP/3 is taken into account in ranking or crawling so far.

Another point: transitioning to HTTPS has an initial cost (certificate, server configuration, massive 301 redirects, managing mixed resources). For a large site, the migration can take weeks and carries risks of SEO regression if mishandled. Google never mentions these frictions — it presents HTTPS as an obvious prerequisite, but in practice, it remains a non-trivial technical project.

In which cases does this rule not or barely apply?

If you manage an intranet site or a site with no organic traffic (closed web app, B2B platform on login, etc.), the SEO pressure to migrate to HTTPS is zero. Similarly, some legacy sites nearing the end of their lifecycle may rationally choose not to invest in a costly migration for the few remaining months of existence. But for any site with a stake in Google visibility, remaining on HTTP/1.1 is now untenable.

Be also cautious of poorly managed hybrid configurations: a site on HTTPS that still serves resources (images, scripts, CSS) over HTTP will face “mixed content” warnings in Chrome and will lose some of the security and trust benefits. Google does not directly penalize mixed content in ranking, but the degraded user experience (warning in the address bar) can impact bounce rate and thus indirectly affect SEO.

What concrete steps should be taken to benefit from HTTP/2?

First step: migrate to HTTPS if this has not been done already. Obtain an SSL/TLS certificate (free Let's Encrypt, or a paid certificate depending on your needs), configure it on the server (Apache, Nginx, IIS), and redirect all HTTP URLs to HTTPS with a permanent 301 redirect. Ensure that all resources (images, JS, CSS) are served over HTTPS to avoid mixed content.

Second step: enable HTTP/2 on the server. On Nginx, simply add http2 in the listen 443 ssl http2; directive. On Apache, you need to load the mod_http2 module and add Protocols h2 http/1.1 in the VirtualHost configuration. Cloudflare, AWS CloudFront, Fastly, and most CDNs enable HTTP/2 by default as soon as HTTPS is in place. Test with WebPageTest or Chrome DevTools (Network tab, Protocol column) to verify that requests are indeed passing in h2.

What mistakes should be avoided during the HTTPS + HTTP/2 migration?

Classic error: forgetting to update internal redirects and canonicals. If your site redirects HTTP → HTTPS but your canonical tags still point to the HTTP URLs, Google will waste time crawling unnecessary redirect chains. The same applies to sitemaps: they must all point to the final HTTPS URLs.

Another trap: not monitoring SSL/TLS response times. The TLS handshake adds latency (typically 1 additional RTT). On a poorly configured server or with a heavy certificate, this can negate some of the HTTP/2 gains. Use TLS 1.3 (faster than 1.2), activate OCSP stapling, and configure HTTP/2 Server Push sparingly (poorly calibrated push can saturate bandwidth and degrade LCP).

How can I check if my site is fully leveraging HTTP/2?

Use Lighthouse and look for optimization opportunities: if it still suggests reducing requests or concatenating files, it means your site is not fully utilizing HTTP/2 (which natively handles multiplexing, making concatenation less critical). Also test with WebPageTest by enabling detailed waterfall: you should see parallel requests over the same TCP connection, with no latency gaps between each request.

Monitor your Core Web Vitals in Search Console before and after migration. If your LCP isn’t improving, it means the bottleneck is elsewhere (slow server, unoptimized images, blocking JS rendering). HTTP/2 does not replace a good front-end architecture; it amplifies it.

• Obtain and configure a valid SSL/TLS certificate (Let's Encrypt or paid).
• Redirect all HTTP URLs to HTTPS with a permanent 301 redirect.
• Enable HTTP/2 on the server or via CDN (Nginx, Apache, Cloudflare, etc.).
• Check for the absence of mixed content (HTTP resources on HTTPS page).
• Test the protocol actually used via Chrome DevTools or WebPageTest.
• Update sitemaps, canonicals, and internal links to point to HTTPS.
• Monitor Core Web Vitals post-migration to measure the real impact.