17 June 2026

If you’ve run a Lighthouse audit recently, you’ve probably seen a recommendation to “use HTTP/2 or later” buried in the diagnostics. What that line doesn’t tell you is that “later” now means something specific: HTTP/3, the protocol that finally retires TCP as the web’s default transport and replaces it with QUIC. For UK businesses competing on Google.co.uk, this matters less as a checkbox and more as a structural shift in how your site talks to browsers, CDNs, and Googlebot itself — with knock-on effects for the metrics Google actually rewards. This article unpacks what HTTP/3 and QUIC actually do differently, separates the genuine SEO impact from the noise around it, and gives you a practical adoption path, whether you’re running WordPress on shared hosting or a headless stack behind Cloudflare. A quick refresher: HTTP/3 is not “HTTP/2 but faster” Every HTTP version up to and including HTTP/2 ran on TCP (Transmission Control Protocol). TCP guarantees ordered, reliable delivery, which is exactly why the web was built on it. But that guarantee creates a structural cost: if a single packet goes missing, every stream multiplexed over that connection stalls until the lost packet is retransmitted. This is head-of-line blocking, and it’s the single biggest reason HTTP/2’s multiplexing promise was never fully delivered on lossy or congested networks — including the 4G and patchy office Wi-Fi that a large share of UK mobile searchers are actually using. HTTP/3 solves this by abandoning TCP altogether. It runs over QUIC, a transport protocol originally built inside Google and now standardised by the IETF, on top of UDP rather than TCP. Three changes fall out of that decision, and all three matter for performance. Independent stream multiplexing. QUIC maps each HTTP request to its own stream, and packet loss on one stream no longer blocks the others. A dropped packet carrying a lazy-loaded image no longer holds up the critical CSS that’s also in flight on the same connection. 1-RTT and 0-RTT handshakes. TCP plus TLS 1.3 typically needs two to three round-trip times before the first byte of your page arrives: one for the TCP handshake, one or two more for TLS negotiation. QUIC folds the cryptographic handshake into the transport handshake itself, getting a first-time visitor to one round trip, and a returning visitor who already holds a valid session ticket to zero round trips before the request goes out. On a connection with 150ms of latency (not unusual for someone in rural UK connecting to an under-optimised origin server), that’s a real, measurable chunk of time off Time to First Byte before a single byte of HTML has even arrived. 2-Connection migration. Because a QUIC connection is identified by a Connection ID rather than a source IP and port pair, a user moving from office Wi-Fi to mobile data — or a phone switching cell towers — doesn’t force a fresh handshake. The connection survives the network change. This is genuinely significant for mobile UX given how much organic traffic in the UK is now mobile-first, and how often a real browsing session crosses network boundaries mid-page. None of this is theoretical. Google’s own QUIC research reported roughly an 18% reduction in YouTube rebuffering after rolling QUIC out at scale, and that data point, more than any marketing material, is what convinced the rest of the industry this wasn’t just a Google pet project. The SEO question everyone gets wrong Here’s the part that needs stating plainly, because a lot of content on this topic gets it backwards: HTTP/3 is not a Google ranking factor. There is no algorithmic check for “does this origin support QUIC” that feeds into rankings. If you migrate to HTTP/3 and your content, backlink profile, and search intent match stay exactly the same, you should not expect a ranking bump from the protocol switch alone. In fact, Google’s own crawler documentation is more conservative on this than most SEO content acknowledges. Googlebot’s crawling infrastructure currently supports HTTP/1.1 and HTTP/2, defaults to HTTP/1.1, and explicitly states that crawling over HTTP/2 carries no ranking benefit for your site — only a potential resource saving for both your server and Google’s. HTTP/3 doesn’t even appear in that documentation as a crawling protocol option at the time of writing. So the crawl itself — the act of Googlebot fetching your page — almost certainly still happens over HTTP/1.1 or HTTP/2 regardless of what protocol you’ve enabled for human visitors. What HTTP/3 actually changes is the experience of the people loading your pages, not the bot indexing them. And that’s where the real SEO connection lives: through Core Web Vitals. The real mechanism: HTTP/3 → faster delivery → better Core Web Vitals → ranking signal Core Web Vitals are a confirmed part of Google’s page experience signals, made up of three metrics measured at the 75th percentile of real Chrome users via the Chrome UX Report (CrUX): Largest Contentful Paint (LCP, the “good” threshold sits at 2.5 seconds), Interaction to Next Paint (INP, threshold 200 milliseconds, having replaced First Input Delay as the responsiveness metric in March 2024), and Cumulative Layout Shift (CLS, threshold 0.1). Google has been explicit that these act as a tie-breaker rather than an override: strong content with poor Core Web Vitals will still usually outrank thin content with perfect Core Web Vitals, but among pages of genuinely comparable relevance and quality, speed and stability earn a measurable edge. This is where QUIC’s mechanics translate into something Google does reward. Faster handshakes and the removal of head-of-line blocking shrink the time before your largest content element paints — a direct LCP input, particularly for visitors on higher-latency or lossy mobile connections, where TCP’s retransmission penalty was always worse. Connection migration reduces the chance that a layout-shifting reconnection event interrupts a session mid-load. None of this rewrites your content relevance score. All of it nudges the loading-speed half of the equation in your favour, on exactly the device class and network conditions where most UK searches now originate.