HTTP/3 (Hypertext Transfer Protocol 3)

HTTP/3 (Hypertext Transfer Protocol version 3) is the latest major version of HTTP, the protocol that carries web pages between browsers and servers. Its defining change is the transport it runs on: instead of TCP, HTTP/3 runs over QUIC, a newer transport protocol built on UDP. QUIC was standardized first (in 2021), with HTTP/3 following as a standard in 2022. The point of moving to QUIC is to cut the delays that remained even after HTTP/2. Like HTTP/2, HTTP/3 multiplexes many streams over a single connection — but because QUIC handles those streams natively, a single lost packet no longer freezes all of them. QUIC also folds connection and encryption setup together, so connections start with less round-trip delay, and it handles network changes (like switching from Wi-Fi to mobile) more gracefully. In short, HTTP/3 keeps HTTP's behavior but delivers it over a faster, more resilient transport designed for real, imperfect networks.

HTTP/3 matters to marketers because it reduces latency and improves resilience, especially on the lossy, changeable connections real users have — mobile networks, congested Wi-Fi, long distances. Those conditions are exactly where pages feel slow, and where the transport-layer stalls of older protocols bite hardest. By avoiding the head-of-line blocking that TCP imposes and by starting connections faster, HTTP/3 can make pages feel quicker and more reliable for users on imperfect networks, which supports Core Web Vitals, user experience, and the conversion and SEO outcomes that ride on speed. The benefit, like HTTP/2's, is largely automatic once a site's server or CDN and the user's browser support it. For a growth team, HTTP/3 is the next step in the quiet, protocol-level performance work that makes the same page reach users faster, particularly on the mobile connections where so much traffic now lives.

HTTP/3 is best understood as the answer to a problem HTTP/2 left unsolved. HTTP/2 multiplexes many streams over a single connection, which fixed the request queuing of HTTP/1.1. But HTTP/2 still runs over TCP, and TCP delivers data as one ordered stream — so if a single packet is lost, TCP stalls everything until it is recovered, freezing all the multiplexed streams even though only one was affected. This is transport-layer head-of-line blocking. HTTP/3 removes it by running over QUIC on UDP, where each stream is independent: a lost packet only delays its own stream, and the others keep flowing. QUIC also merges the connection and TLS handshake, cutting setup latency, and survives network changes better. So HTTP/2 fixed application-layer queuing; HTTP/3 fixes the transport-layer blocking HTTP/2 inherited from TCP.

The practical difference shows up most on imperfect networks. On a fast, clean connection, HTTP/2 and HTTP/3 perform similarly, and HTTP/2 remains perfectly good. But on lossy or high-latency links — typical mobile reality — HTTP/3's independence between streams and faster setup give it an edge, because packet loss no longer freezes the whole page. The two are not rivals so much as successive steps: HTTP/3 is HTTP/2's behavior delivered over a better transport. Adoption follows support — a site benefits only when its server or CDN and the visitor's browser both speak HTTP/3, usually with HTTP/2 as a fallback. The honest framing is that HTTP/3 is an incremental but real improvement, largest where networks are worst, and it sits one rung above HTTP/2 on the same ladder of reducing web latency.

Using HTTP/3 well mostly means enabling it where your infrastructure supports it — typically through a modern CDN or server that offers HTTP/3 over QUIC — and letting browsers that support it negotiate up, with HTTP/2 as the fallback for those that do not. Because the benefit is automatic and largest on poor networks, the main work is configuration and verification, not page changes. It pairs with the same performance discipline as HTTP/2 and AVIF: lean pages, efficient assets, and good delivery, with the protocol layer as one contributor to speed rather than a cure-all. For a growth team serving a lot of mobile traffic, HTTP/3 is worth enabling, since that is where its latency and resilience gains help most. The aim is faster, steadier delivery on real networks, supporting the experience and SEO metrics tied to speed.

The failures are expecting HTTP/3 to transform a site that is slow for other reasons (heavy pages, unoptimized images, blocking scripts), enabling it without verifying support and fallback, and treating it as a substitute for sound performance work rather than a complement to it. Its gains are real but incremental and concentrated on lossy, high-latency networks. The discipline is to enable HTTP/3 where infrastructure allows, keep HTTP/2 as the fallback, verify it is working, and combine it with lean pages and efficient assets — so the protocol layer contributes its share of speed, especially for mobile users, without being mistaken for a fix for deeper performance problems.

HTTP/3 (Hypertext Transfer Protocol version 3) — the latest HTTP version, run over QUIC on UDP — cuts latency and head-of-line blocking, improving on HTTP/2 most on lossy, real-world networks.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where http/3 (hypertext transfer protocol 3) is a core concern: