Latency and Bandwidth: The Two Levers of Web Performance
Network performance discussions usually boil down to two fundamental quantities: latency and bandwidth. Latency is the time a packet needs to travel from client to server, physically bounded by how fast signals propagate through cables or air. On Earth, one-way latency typically ranges from 10 to 200 milliseconds, depending on distance. Since most protocol exchanges require a response, what matters more is the round-trip time (RTT) — the time for a packet to go out and come back.
Bandwidth is the other side of the coin: how many packets can be in flight simultaneously. The common pipe metaphor works well here. Latency is the pipe's length; bandwidth is its width. But the Internet is a series of connected pipes, and the end-to-end throughput is constrained by the narrowest segment — the bottleneck link.
These two values interact in ways that matter for HTTP/3. Even modest RTTs of under 50 milliseconds add up quickly when a protocol requires several round trips to complete a single transfer. That cumulative delay is why CDNs exist: they shorten the physical distance, and therefore the latency, between the user and the content. Bandwidth, in contrast, depends on physical medium properties, network congestion, and the processing capacity of intermediary devices — factors far harder to control from a protocol design perspective.
Bandwidth Discovery in QUIC
A transport protocol’s performance depends heavily on how efficiently it can use the full physical bandwidth of a network. Some discussions claim QUIC handles this much better than TCP, but that is not accurate. TCP does not begin sending at full speed because network links can only process a fixed amount of data per second; exceeding that limit leads to packet loss. For a reliable protocol like TCP, lost packets require retransmission, which costs one round trip and can seriously affect performance on high-latency networks.
Another challenge is that the maximum available bandwidth is not known in advance. It depends on a bottleneck somewhere along the end-to-end path, and the Internet has no mechanism to signal link capacities back to endpoints. Even if such information existed, a single connection must share bandwidth fairly with other concurrent users on the network.
To handle this uncertainty, TCP uses congestion control: it starts with a small number of packets (roughly 10 to 100 packets, or about 14 to 140 KB of data) and waits one round trip for acknowledgements. If all packets are acknowledged, it repeats the process with more data, usually doubling the send rate each iteration. This slow start phase continues until packet loss indicates congestion, at which point TCP reduces the send rate and later increases it again in smaller increments. The cycle repeats after each loss event, allowing TCP to continually probe for its ideal fair share of bandwidth.
This description is simplified. Real-world congestion control involves bufferbloat, RTT fluctuations caused by congestion, and fair sharing among many concurrent senders. As a result, numerous congestion-control algorithms exist, and none performs optimally in all situations.
TCP’s cautious approach means it takes time to reach optimal send rates, especially on high-bandwidth, high-latency paths. For web-page loading, slow start constrains how much data can be transferred in the first few round trips, which affects metrics like first contentful paint. This is why keeping critical resources small is often recommended.
QUIC’s Congestion Control Reality
QUIC is frequently misunderstood in this context. Some articles claim that because QUIC runs over UDP—which has no built-in congestion control—it can send aggressively and simply rely on its removal of head-of-line blocking to handle packet loss. In reality, QUIC uses bandwidth-management techniques very similar to TCP. It also starts at a lower send rate and grows over time, using acknowledgements to gauge network capacity. This is necessary because QUIC must be reliable for HTTP, fair to other QUIC and TCP connections, and because its HOL-blocking removal does not eliminate the cost of packet loss.
What QUIC does offer is more flexibility for improvement. TCP’s congestion logic lives in the operating system kernel, which is secure but restricted and often not open source. Tuning it is usually left to a small group of developers, so evolution is slow. QUIC implementations, by contrast, typically run in user space and are open source, encouraging broader experimentation. Facebook, for example, has already explored using reinforcement learning for congestion control in QUIC.
A concrete example of this flexibility is the delayed acknowledgement frequency extension. By default, QUIC acknowledges every 2 received packets; the extension allows endpoints to acknowledge every 10 packets instead. This reduces acknowledgement overhead, providing large speed benefits on satellite and very high-bandwidth networks. Deploying a similar change to TCP would take far longer to gain adoption.
The official QUIC Recovery RFC 9002 specifies the NewReno congestion-control algorithm, which is robust but somewhat outdated. NewReno was chosen because it was the most recent standardized algorithm at QUIC’s inception—more advanced options like BBR were not standardized, and CUBIC only recently became an RFC. Additionally, NewReno is simple enough to make it easy to explain how congestion-control algorithms must be adapted to QUIC’s differences from TCP. In practice, most production-level QUIC implementations use custom CUBIC or BBR variants. Congestion-control algorithms are not protocol-specific; they work with TCP and QUIC alike.
Flow control is a related but distinct concept that is often confused with congestion control. Both are sometimes described using the term “TCP window,” although there are two windows: the congestion window and the receive window. Flow control has less relevance to web-page loading and is not covered here.
Implications for Performance
QUIC remains subject to the same physical constraints and fairness requirements as TCP. It will not magically download resources faster. However, because QUIC is easier to iterate on, experimenting with new congestion-control algorithms becomes more practical, which should improve both TCP and QUIC in the future.
How Fast Is QUIC Connection Setup, Really?
One of the most hyped performance claims about QUIC is how much faster it sets up connections compared to TCP + TLS. The transport and cryptographic handshakes can be combined into a single exchange, since QUIC was designed with TLS built in from the start. That saves roughly one round trip versus a modern TCP + TLS 1.3 setup.
Claims that QUIC is two or three round trips faster usually compare against the worst case: TCP combined with older TLS 1.2, which requires separate handshakes. Against a properly deployed modern stack, the practical gain is just one round trip — barely noticeable on low-latency networks, though more meaningful on connections with high round-trip times.
Reusing Connections With 0-RTT
Session resumption is a TLS feature, not something QUIC invented. It lets a client reuse cryptographic parameters learned during an earlier connection, making it possible to encrypt the very first packets of a new connection. This is the basis of “0-RTT” — the client can send its first HTTP request along with the handshake, avoiding an additional round trip of waiting.
TLS 1.3 supports this fully, and it also works over TCP and HTTP/2. So even with 0-RTT, QUIC remains only one round trip ahead of a well-optimized TCP + TLS 1.3 connection.
There is a catch: the term “0-RTT” is slightly misleading because it still takes one round trip for response data to start arriving. More importantly, the very first request cannot be sent unencrypted, so this optimization only applies once session resumption parameters have been established on a prior connection.
Security Limits on the 0-RTT Advantage
QUIC’s 0-RTT speed boost is constrained by security. In a normal handshake, the server can validate the client’s IP address before sending large responses. With 0-RTT, the server receives an encrypted request without that verification step, and IP addresses can be spoofed.
An attacker could spoof a victim’s IP in a 0-RTT request for a large file. If the server replies without validation, it would flood the victim’s network with unsolicited data. This is a reflection or amplification attack, commonly used in DDoS campaigns. The QUIC server needs to limit its response until the client is confirmed real. As such, responses to 0-RTT requests are capped at three times the amount of data received. A typical client sends one or two packets, limiting the server’s response to roughly 4-6 KB including QUIC and TLS overhead.
Additionally, 0-RTT requests are vulnerable to replay, which narrows what can be sent. Cloudflare, for instance, only permits certain HTTP requests like GET without query parameters in 0-RTT. This curbs the usefulness of the feature further.
Mitigations and Limitations
There are techniques to improve this. A server can check whether a 0-RTT request comes from an IP with which it has had a valid connection, which works as long as the client is on the same network. However, even then, the server’s response is still constrained by slow-start congestion control. The gain is mainly the single saved round trip, not a larger initial data burst.
Other approaches exist but come with trade-offs. Clients could pad their initial packets to allow for a larger reply under the three-times limit. Servers might remember a client’s available bandwidth from prior connections, though that is an area of academic research and proposed extensions rather than standard behavior. It is also possible for a server to simply ignore the limit, but that invites risk.
One more subtlety: the three-times amplification limit also applies during QUIC’s normal handshake. If a server’s TLS certificate chain is too large to fit in the initial response budget, certificate compression becomes critical to keep QUIC’s handshake to a single round trip.
Real-World Value
0-RTT is better described as a micro-optimization than a headline feature. It stands out mainly for users on very high-latency links such as satellite connections, or for applications that send very little data. Heavily cached sites, single-page apps fetching small updates, and certain DNS-over-QUIC setups fit this profile. Google found strong 0-RTT results for its optimized search page, where responses are small.
For most other websites, the advantage will be tens of milliseconds at most — and often less if you are already using a CDN.
What Happens When a Connection Changes Networks
QUIC’s connection IDs (CIDs) allow a connection to survive a switch between entirely different networks — say, from Wi-Fi to cellular — without being torn down. On TCP, such a migration would typically break the connection, potentially aborting an in-progress download or video call.
The practical value of this feature depends heavily on context. Moving between Wi-Fi access points or cellular towers usually does not trigger connection migration, because the device keeps its IP address when the handoff happens at a lower protocol layer. Migration only occurs when moving between completely different networks, which is comparatively rare.
For many use cases, existing mitigations already cover the scenarios where migration would help. Servers offering large downloads can support HTTP range requests for resumable transfers. Video applications can take advantage of the overlap period between an old network dropping off and a new one becoming available to open multiple connections — one per network — and sync them before fully committing to the switch. The user still notices the transition, but the feed does not drop entirely.
Even when migration does occur, QUIC does not simply continue sending at the previous rate. There is no guarantee that the new network offers the same bandwidth as the old one. To avoid overwhelming it, the server resets or lowers its send rate and restarts in the congestion controller’s slow-start phase. That initial rate is often too low to sustain video streaming, meaning some quality loss or hiccups are still likely. In this light, connection migration is less a pure performance win than a way to avoid connection context churn and reduce server overhead.
Did You Know?
As with 0-RTT, advanced techniques can improve connection migration. One idea is to remember the bandwidth available on a given network and ramp up faster to that level after migrating to it. Another is to use both networks at once rather than switching — a concept called multipath, discussed further below.
Passive Migration and NAT Rebinding
Active migration, where the user changes networks, is not the only case. Passive migration happens when the network itself changes parameters. Network address translation (NAT) rebinding is a common example: port numbers can change at any time without warning, and for UDP this occurs more often than for TCP on most routers.
In a NAT rebinding, the QUIC CID does not change, so most implementations assume the user remains on the same physical network and do not reset the congestion window or other parameters. QUIC includes PING frames and timeout indicators to prevent rebinding from disrupting long-idle connections.
Why Two Sets of CIDs
As covered earlier, QUIC does not rely on a single CID for security reasons; it changes CIDs during active migration. In practice, the mechanism is more complex because both client and server maintain separate CID lists, called source and destination CIDs in the QUIC RFC, as shown below.
This separation lets each endpoint choose its own CID format and contents, which is essential for advanced routing and load balancing. With connection migration, a load balancer can no longer identify a connection by its 4-tuple alone. If all CIDs were random, the load balancer would need to store mappings of CIDs to back-end servers, increasing memory requirements — and migration would still break those mappings, since the CIDs change to new random values.
For QUIC servers behind a load balancer, a predictable CID format is therefore important. It allows the load balancer to derive the correct back-end server from the CID even after migration. The IETF’s proposed document on QUIC load balancing describes several options. This design works only because servers can choose their own CID — impossible if the connection initiator, which in QUIC is always the client, selected it. Hence the split between client and server CIDs.
Who Actually Benefits
Connection migration is a situational feature. Google’s initial tests show low percentage improvements for its use cases, and many QUIC implementations do not yet support it. Those that do typically limit it to mobile clients and apps rather than desktop equivalents. Some argue the feature is unnecessary because opening a new connection with 0-RTT should deliver comparable performance in most cases.
The impact depends on the use case and user profile. Websites or apps most often used while on the move — ride-hailing or navigation services, for instance — benefit more than those typically accessed from a desk. Similarly, applications focused on constant interaction, such as video chat, collaborative editing, or gaming, see greater improvement in worst-case scenarios than a news site would.
Does QUIC’s HoL Blocking Removal Actually Speed Up Page Loads?
QUIC’s most-touted feature is its removal of head-of-line (HoL) blocking at the transport layer. In theory, this makes HTTP/3 faster on networks with high packet loss. In practice, however, the benefits for typical web-page loading are likely to be modest, due to how stream prioritization and multiplexing actually work.
Why Multiplexing Strategy Matters More Than Transport
QUIC handles packet loss on a per-stream basis, unlike TCP, which treats all data as a single bytestream. But this capability is only useful if other streams actually have data ready to process while one is stalled. Since QUIC streams are multiplexed onto a single connection, the ordering of that multiplexing is critical.
There are two conceptual extremes for multiplexing streams A, B, and C:
- Round-robin:
ABCABCABCABC...— constantly switching between streams. - Sequential:
AAAAAAAABBBBBBBBCCCCCCCC— completing each stream before starting the next.
Most web performance experts favor the sequential approach. Render-blocking resources — such as CSS files and certain JavaScript in the head — must be fully downloaded before the browser can paint the page. With round-robin multiplexing, these critical files all share bandwidth and finish later. Sequential multiplexing lets high-priority resources like main.js finish much sooner, while not delaying lower-priority resources. Conversely, resources that can be processed incrementally, such as HTML or progressive JPEGs, benefit from more interleaving.
For the majority of web resources, however, sequential multiplexing performs best, which is why Chrome tends to load pages faster in comparisons than browsers using more aggressive interleaving.
The Conflict Between Prioritization and Loss Recovery
This preference for sequential multiplexing undermines QUIC’s HoL blocking removal. Consider a congestion window that allows sending 12 packets at once. If all 12 contain data for stream A — a high-priority, render-blocking resource — then losing any single packet completely stalls the connection. There is no stream B or C data to process in the meantime, so QUIC behaves just like TCP in this scenario.
The result is a fundamental tension:
- Round-robin multiplexing (
ABCABCABCABC) maximizes resilience to HoL blocking but degrades page-load performance. - Sequential multiplexing (
AAAABBBBCCCC) is better for page loads but negates QUIC’s loss-recovery advantage.
Packet loss patterns make the problem worse. Internet packet loss is often “bursty,” meaning multiple packets are dropped simultaneously. If a round-robin pattern (ABCABCABCABC) suffers a burst loss of just four packets, all three streams are impacted — every stream must wait for its own retransmission, and QUIC’s HoL blocking removal offers zero benefit.
To reduce the risk of a loss burst hitting every stream, you need to concatenate more data per stream (e.g., AAAABBBBCCCCAAAA...). This, again, points back toward a sequential multiplexing strategy, which inherently limits the number of concurrent active streams.
Where HoL Blocking Removal Might Actually Help
Predicting the real-world impact of QUIC’s HoL blocking removal is difficult, as it depends on stream count, loss burst frequency and size, and how stream data is consumed. Most current research suggests it will not dramatically improve first-time web-page loads, because those typically want fewer concurrent streams.
However, some scenarios may see tangible benefits, particularly those outside the classic full page-load use case:
- Repeat visits on well-cached pages.
- Background downloads where render-blocking concerns are absent.
- API calls in single-page apps with fully independent streams. Facebook, for example, has observed performance gains from HoL blocking removal when loading data in its native application.
The bottom line: QUIC’s HoL blocking removal should mainly affect users on the slowest, most loss-prone networks (likely the bottom 1%), and even then the effect is uncertain. This remains an active research area, and real-world results are still pending.
UDP and TLS Overhead in QUIC
A less glamorous but significant performance consideration is the cost of actually creating and transmitting QUIC packets. Because QUIC was designed for flexibility and deployability rather than raw speed, its use of UDP and its encryption model have historically made it slower than TCP+TLS — though the gap is closing.
One reason is architectural. TCP and UDP typically live in the OS kernel, where they benefit from years of optimization (see figure below). TLS and QUIC, by contrast, are mostly implemented in user space. That's a choice made for flexibility, not necessity, but it adds overhead when data must cross the kernel boundary via system calls.
TCP has historically received far more attention than UDP in this regard. Kernel APIs for TCP were tuned over time, and many network interface controllers include hardware offload features for it. UDP, being less widely used, lacked such optimizations — until roughly the last five years, when most OSes added faster UDP paths as well.
QUIC also pays a penalty for encrypting each packet individually. TLS over TCP can encrypt data in chunks of up to about 16 KB (roughly 11 packets at a time), which is far more efficient. QUIC intentionally avoids bulk encryption because it can reintroduce its own form of head-of-line blocking, but the trade-off is inherent and permanent: QUIC will always be at some disadvantage to TCP+TLS in this regard. In practice, optimized encryption libraries and bulk header encryption help close the gap.
The numbers tell the story. Google's earliest QUIC implementations were about twice as slow as TCP+TLS. Microsoft's heavily optimized MsQuic stack, running on Windows with recently improved UDP support, achieved 7.85 Gbps versus 11.85 Gbps for TCP+TLS — about two-thirds the throughput. Google's most recent QUIC stack is roughly 20% slower than TCP+TLS. Earlier Fastly tests on less advanced hardware reported parity at around 450 Mbps, showing that results depend heavily on the use case.
Even a 2x disadvantage might not matter much in practice. QUIC and TCP+TLS processing is rarely the dominant workload on a server; HTTP logic, caching, and proxying all compete for CPU. So doubling QUIC's processing cost won't necessarily double the number of servers required. Real data-center impact remains unclear, as no major company has published such measurements.
There is also room for future optimization. Some QUIC implementations may migrate partially into the kernel, as TCP did; some already bypass it, as MsQuic does. QUIC-specific hardware offload is also anticipated. Still, some scenarios will probably stay on TCP+TLS. Netflix, for instance, has said it will likely stick with its heavily customized FreeBSD TCP+TLS stacks for video streaming. Facebook has indicated QUIC will mainly be used between end users and CDN edges, not between data centers or upstream origins, because of its overhead. Very high-bandwidth workloads will likely favor TCP+TLS for the foreseeable future, with large-scale deployments potentially using a mix of both protocols.
Did You Know?
Network stack optimization is a deep rabbit hole. If you want to understand terms likeGRO/GSO,SO_TXTIME, kernel bypass, andsendmmsg()andrecvmmsg(), Cloudflare and Fastly have published detailed articles on accelerating QUIC, Microsoft offers a code walkthrough, and Cisco and Google engineers have given in-depth talks on the subject.
What Does It All Mean?
QUIC's reliance on UDP and per-packet encryption has made it slower than TCP+TLS, though optimizations have narrowed the gap over time. For typical web-page loading, users won't notice the difference, but operators of large server farms might. The trade-off buys the substantial latency and multiplexing benefits discussed elsewhere in this series.
HTTP/3 Features
Much of this series has focused on QUIC's improvements over TCP. But what about HTTP/3 itself versus HTTP/2? As established in part 1, HTTP/3 is effectively HTTP/2 running over QUIC — no major new high-level features were added. The shift from HTTP/1.1 to HTTP/2 introduced header compression, stream prioritization, and server push. HTTP/3 keeps all three, but their implementations had to change because of how QUIC works.
QUIC's removal of head-of-line blocking means that packet loss on stream B no longer stalls streams A and C. Consequently, data from those streams may arrive and be processed out of order — say A, C, B. HTTP/2 relied heavily on TCP's strict ordering for its control messages, which are interspersed with data. Over QUIC, such control messages could be applied in the wrong sequence, potentially reversing their intended effect.
Consider HTTP header compression, which reduces the overhead of repeated headers such as cookies and user-agent strings. HTTP/2 used HPACK for this. HTTP/3 reimplements it as QPACK, a more complex design that accounts for QUIC's relaxed ordering. Both deliver the same feature through quite different mechanisms. The Litespeed blog offers detailed diagrams and analysis of the differences.
Stream prioritization has also been redesigned. HTTP/2 used a complex "dependency tree" to model how page resources relate to one another. That approach doesn't map cleanly onto QUIC: adding each resource to the tree would require a separate control message, and out-of-order delivery could produce incorrect tree states. Worse, the HTTP/2 dependency-tree system proved error-prone in practice, leading to implementation bugs and poor performance on many servers. HTTP/3 replaces it with a much simpler prioritization scheme. The new design makes some scenarios, like proxying multiple clients over a single connection, more challenging — but it covers the common web-page-loading cases and should reduce implementation bugs.
Server push — where the server sends responses before being asked — survives in HTTP/3's specification, though few implementations support it. Its mechanics were adapted for QUIC's non-deterministic ordering, but its long-standing usability and implementation issues remain. It was already hard to use correctly and inconsistently supported; Google Chrome may even remove it entirely.
What Does It All Mean?
Most of HTTP/3's value comes from QUIC, not the HTTP layer itself. While HTTP/3's internals differ greatly from HTTP/2's, its high-level features and the way developers should use them remain unchanged. The protocol is best understood as HTTP/2 adapted for QUIC's concurrency model.
What’s Next for HTTP/3 and QUIC
QUIC was designed to evolve faster and with more flexibility than TCP, and that promise is already paying off. Researchers and browser vendors are actively developing extensions that will push the protocol beyond what QUIC version 1 delivers today. Here are the main areas to watch.
Extensions in the Pipeline
Forward error correction (FEC) aims to reduce QUIC’s sensitivity to packet loss. Instead of waiting for a retransmission, the sender includes redundantly encoded copies of the data. If a packet is lost but the redundant data survives, no retransmission is needed. FEC was part of Google’s original QUIC but was cut from the standardized version 1 because its performance benefits were not yet proven. Active experiments are under way now, and you can participate through the PQUIC-FEC Download Experiments app.
Multipath QUIC takes connection migration a step further: instead of switching from Wi-Fi to cellular, a device would use both networks simultaneously, increasing available bandwidth and robustness. Google also experimented with this but left it out of QUIC version 1 due to complexity. Researchers have since demonstrated its potential, and it could land in QUIC version 2. Notably, TCP multipath has taken nearly a decade to become practically usable, so QUIC’s design may help here too.
Unreliable data over QUIC is another proposed extension that plays to QUIC’s strengths. Because QUIC runs over UDP, a datagram extension can add a way to send data without reliability guarantees. This is not useful for web resources, but it matters for gaming and live video streaming, where users get UDP-like behavior with QUIC-level encryption and optional congestion control.
WebTransport is the browser-facing API for this low-level access. Browsers do not expose raw TCP or UDP to JavaScript, so developers currently rely on Fetch, WebSocket, and WebRTC. WebTransport would allow HTTP/3 (and QUIC) to be used in a more granular way, with a fallback to TCP and HTTP/2 if necessary. It will include support for unreliable data over HTTP/3, which should simplify browser-based gaming implementations. For ordinary JSON API calls, Fetch remains the tool, and it will automatically use HTTP/3 when available. WebTransport is still under active discussion, and Chromium is the only browser with a public proof-of-concept implementation so far.
DASH and HLS video streaming could also benefit from QUIC’s design. These protocols chop video into chunks of 2–10 seconds at multiple quality levels, and the browser estimates the best quality to request based on network conditions. Since browser code does not have direct access to the TCP stack, those estimates can be wrong or slow to react, causing stalls. QUIC, being implemented in the browser itself, gives streaming estimators access to low-level protocol information like loss rates and bandwidth estimates. Some researchers are also experimenting with mixing reliable and unreliable data for video, with promising results.
Beyond HTTP itself, QUIC is a general-purpose transport that other application-layer protocols will likely adopt. Work in progress includes DNS-over-QUIC, SMB-over-QUIC, and SSH-over-QUIC. These protocols have very different requirements than web page loading, and QUIC’s performance features may be far more beneficial there.
What This Means for You
QUIC version 1 is just the beginning. Many of the advanced performance features that Google originally tested did not make it into the first standardized iteration, but the goal is to introduce new extensions at a high frequency. Over time, QUIC and HTTP/3 are expected to become clearly faster and more flexible than TCP and HTTP/2.
At the same time, the performance story is more nuanced than the headlines suggest. QUIC’s use of UDP does not grant it more bandwidth than TCP, and 0-RTT saves only one round trip with roughly 5 KB of data in the worst case. Head-of-line blocking removal is less effective with bursty packet loss or render-blocking resources. Connection migration is situational, and HTTP/3 has no major new features that would make it inherently faster than HTTP/2.
None of that is a reason to skip deployment. The protocols matter most for highly mobile users and people on slow networks. Even in regions like Western Europe, where fast devices and high-speed cellular are common, 1% to 10% of your user base can fall into these categories—someone on a train waiting 45 seconds for a page to load is a real scenario. The situation is far worse in many other parts of the world, where the average user looks like the slowest 10% in Belgium and the slowest 1% may never see a page load at all. In those regions, web performance is an accessibility and inclusivity issue.
Testing only on your own hardware misses these users. Services like WebpageTest give a broader view, and deploying QUIC and HTTP/3 can make a world of difference for users who are on the move or on constrained connections. Even if the benefits are not obvious on a cabled MacBook Pro, early experience with the protocols will pay off as they evolve and gain features. QUIC also enforces security and privacy best practices in the background, which helps everyone.
