If you’re still on HTTP/1.1, you’re making performance harder than it needs to be
A lot of people get pulled toward the shiny stuff in SEO: the hot topics, the newest tooling, the endless debate about which metric matters most this week. Meanwhile, some of the most effective improvements are the boring ones — the kind that don’t make for exciting LinkedIn posts, but do change the baseline of how a site behaves.
One of those: protocol support.
In the last year or so I’ve seen more than a few client sites still running on HTTP/1.1, while teams are spending serious time (and budget) trying to “optimise performance” and improve Core Web Vitals. That’s not inherently wrong — plenty of CWV work is valid — but it’s worth stating the obvious: if the site is still on HTTP/1.1, you’re optimising on top of an outdated delivery layer, and it is worth testing whether modernising the transport removes a constraint before committing to weeks of smaller frontend changes.
Not because it’s trendy. Because it changes the mechanics of how the browser fetches your site.
Why HTTP/1.1 quietly makes modern sites slower
HTTP/1.1 was designed for a web that looked nothing like today’s. Modern pages routinely load dozens (sometimes hundreds) of resources: CSS, JS, images, fonts, third-party scripts, API calls, tracking, consent tooling — the usual pile. HTTP/1.1 can deliver all that, but it tends to do it inefficiently because it hits limits that were never a real problem 20 years ago.
In practice, the issues usually show up as:
- Request queuing and bottlenecks, because only so much can happen in parallel before requests start waiting.
- A higher number of connections, which brings extra handshake overhead (TCP + TLS) and more moving parts under load.
- Repeated header overhead, which sounds minor until you look at what bloated cookies and headers are doing across a page with lots of requests.
- Legacy “workarounds” that used to be common practice (sharding, sprites, awkward bundling decisions) and often still leave a mess behind.
The net result is that even if you’re doing sensible optimisation work elsewhere, the underlying delivery model is still slower and more fragile than it needs to be.
What HTTP/2 changes, and why it often helps CWV without heroics
HTTP/2 doesn’t fix a heavy frontend or magically make bad implementation choices disappear. What it does do is remove some structural inefficiencies in how resources are delivered.
The headline improvement is multiplexing, which means the browser can request and receive multiple resources over a single connection without HTTP/1.1’s application-level request queuing. It does not eliminate every bottleneck: because HTTP/2 still runs over TCP, packet loss can temporarily hold up all the streams sharing that connection. Alongside that you get header compression, which reduces repeated overhead across the many requests modern pages generate.
The reason this matters for Core Web Vitals is simple: CWV is often where delivery inefficiency becomes visible in real user data, especially on mobile networks or on pages with lots of assets competing for attention. When the protocol lets the browser fetch resources more efficiently, you often see improvements in how quickly key resources arrive and how consistent load behaviour is across real sessions.
To be clear, HTTP/2 isn’t a standalone “ranking factor” in the way people sometimes wish these things were. The SEO value is indirect. Better delivery can improve user experience and may help relevant Core Web Vitals, but the protocol itself is not a ranking signal and improved Core Web Vitals do not guarantee better rankings.
And what about HTTP/3?
HTTP/3 can be an extra step forward, but it’s not automatically a win in every context, and it’s not where I’d start if a site is still on HTTP/1.1.
The practical reason HTTP/3 can help is that it runs over QUIC, which avoids TCP-level head-of-line blocking between independent streams and can behave better in certain real-world conditions, particularly where there’s packet loss or inconsistent connectivity. That tends to describe… well, a fair amount of mobile browsing and consumer Wi-Fi.
If field performance is materially worse than lab testing, network conditions may be part of the explanation. HTTP/3 can help where latency, packet loss or changing connections are significant, although it will not fix all the other reasons field and lab data diverge. If a network does not support it, browsers generally fall back to HTTP/2, so it is often low risk when enabled correctly.
What this means for SEO, in practical terms
The honest framing is that protocol upgrades support SEO by improving the things that sit underneath it, rather than by directly “boosting rankings”.
If you upgrade from HTTP/1.1 to HTTP/2 (and enable HTTP/3 where it makes sense), the likely SEO-relevant benefits are:
Better load performance and resource delivery, which can influence LCP and overall perceived speed.
More consistency under real conditions, because fewer requests get stuck waiting behind others and delivery tends to be less fragile.
Potentially more efficient crawling on larger sites. Googlebot can use HTTP/2 to transfer multiple files over fewer connections, reducing some server and crawler resource use. That does not mean more crawling or better indexation, and for most sites it should be treated as an operational benefit rather than an SEO outcome.
And, bluntly, fewer wasted hours. If performance work is taking weeks of incremental change, it’s worth checking you’re not ignoring a foundational upgrade that could make everything else easier.
The caveats (because there always are caveats)
A protocol upgrade won’t rescue a site that is fundamentally bloated, poorly architected, or weighed down by third parties firing at the worst possible moment. If you’re shipping huge JS bundles, loading five tag managers, and running half a dozen “essential” marketing scripts before anything meaningful renders, HTTP/2/3 won’t fix the underlying problem.
Also worth noting: HTTP/3 isn’t universal. Some corporate environments block UDP/QUIC. That’s not a disaster — it just means those users fall back to HTTP/2, which is still a meaningful improvement over HTTP/1.1.
Finally, treat this as part of basic operational hygiene. Keep your server/CDN stack patched and properly configured. You’re upgrading plumbing; don’t do it carelessly.
How to check what a site is running (quickly, without turning it into a project)
If you want the simplest check, use Chrome DevTools:
Open DevTools → Network, right-click the column headers, enable the Protocol column, then reload. You’ll see http/1.1, h2, or h3 against requests.
If you prefer command line checks:
curl --http2 -I https://example.comcurl --http3 -I https://example.com(if your curl build supports it)
This isn’t about being clever. It’s about confirming reality before you spend weeks chasing marginal CWV gains.
The usual “lowest risk” upgrade path
In many cases, the easiest route is enabling HTTP/2 (and optionally HTTP/3) at the CDN/edge, because it avoids complicated origin changes and gives you immediate coverage across your site. A lot of setups make this a toggle, but don’t assume — check what your host/CDN actually supports and how they implement it.
Remember that this only confirms the client-to-edge leg. Depending on the setup, the CDN may still communicate with the origin over HTTP/1.1, and an overloaded or slow origin remains an overloaded or slow origin.
Once enabled, don’t judge success by a single Lighthouse run. Watch field trends where you can:
Search Console’s CWV report, CrUX data (if you have enough traffic), and any real user monitoring you trust.
The point most teams miss
Performance work tends to become a grind when it’s treated as endless “tuning” rather than fixing structural constraints. If you’re still on HTTP/1.1, you’re living with one of those constraints, and it often makes everything else harder: slower delivery, more overhead, more inconsistency, and more time spent squeezing small gains from the wrong layer.
To uncover protocol issues and other technical roadblocks holding your site back, my Technical SEO Audit identifies what matters, what does not, and what your developers should fix first.
So yes — optimise assets, reduce JS, improve caching, tackle third parties. But before you disappear into weeks of micro-optimisation, do the unglamorous check: what protocol is the site actually using?
If the answer is HTTP/1.1, you have probably found a performance constraint worth testing before you disappear into smaller, more expensive optimisations.