Speed at the Tail: How Dropbox Tested HTTP3 for Search
Dropbox’s Retrieval Experiences team faced a familiar problem: users found search too slow. A July 2022 study revealed that it took roughly 400–450ms (p75) for a search webpage to submit a query and get a response. The team’s analysis showed that network latency—the time packets spend in transit between the client and Dropbox servers—accounted for about half of that delay, with server-side query processing making up the rest.
Network latency is inherently more erratic than server latency. It fluctuates with local connection quality, geographic distance from Dropbox’s predominantly North American data centers, and even the time of day. Users in Europe typically see latencies twice as high as North Americans; users in Asia see three times as high. Given that 25% of search requests come from Europe and 15% from Asia, a meaningful share of Dropbox’s user base stood to benefit from a protocol-level fix.
Search’s total latency is comprised of server time and network time
The Case for HTTP3
Dropbox’s web traffic currently runs over HTTP2, which is built on TCP. HTTP3, by contrast, uses UDP and offers two major theoretical advantages for connection setup and parallel request handling:
- Zero Round Trip Time (0RTT): HTTP3 skips the TCP three-way handshake, saving one round trip on the first connection. On subsequent connections, the secure connection handshake and the actual request can be sent in the same packet, whereas HTTP2 has to send these separately.
- No head-of-line blocking: TCP processes packets in strict order, so a single lost packet can stall unrelated streams queued behind it. UDP allows each stream to deliver data independently to the application when another stream is blocked.
Head-of-line blocking: In HTTP2, a blocked stream also delays subsequent streams, whereas in HTTP3, a blocked stream only affects that stream
The promise was compelling, but the real-world outcome was not guaranteed. To avoid an unvetted leap, the Traffic team set up a controlled experiment to measure how HTTP3 actually behaved on Dropbox’s infrastructure.
Experiment Design
The Traffic team built a test subdomain that served the main website over HTTP3. It hosted a no-op API endpoint, which returns a response without performing any operations, making server-side latency essentially zero and isolating any remaining delay as network latency.
The test simulated typical request traffic, including search interactions, in three phases:
- Cache warm-up: Two sequential HTTP3 requests were fired and their timing discarded. This pre-warmed networking caches for both HTTP2 and HTTP3 equally. Notably, the first connection is always HTTP2 because that’s how the client initially learns HTTP3 is available.
- HTTP2 control: Five parallel HTTP2 requests hit the no-op and each request’s network time was logged. This served as the baseline for current behavior.
- HTTP3 experiment: Another five parallel requests, this time over HTTP3, with elapsed network times recorded for comparison against the control.
Parallel requests were central to the design. They mirror real Dropbox web usage, where multiple requests fire per interaction, and they specifically test whether eliminating head-of-line blocking yields tangible gains. To avoid impacting real users, the test ran only once per page load and only after a search was completed. Over roughly two weeks from December 2022 to January 2023, the experiment collected data from a wide global sample, with traffic exceeding 1,500 queries per second at peak.
Results: Negligible Median Gains, Big Wins at the Tail
The experiment logged about 300,000 HTTP3 requests per day. For most users worldwide, HTTP3 trimmed network latency by 5–15ms, or roughly 5%—an improvement imperceptible in normal use. The real impact showed up at the upper end of the distribution:
- At p90, latency fell by 48ms (13%).
- At p95, latency fell by 146ms (21%).
This outcome aligns with how HTTP3 handles packet loss. Weaker networks are more prone to dropped packets, which is exactly where head-of-line blocking in TCP punishes parallel requests most. HTTP3’s ability to let unaffected streams continue explains the outsized benefit at higher percentiles.
| HTTP3 vs. HTTP2 | |
|---|---|
| p25 | -4.23ms / -4.73% |
| p50 | -5.55ms / -4.15% |
| p75 | -13.1ms / -5.78% |
| p90 | -47.6ms / -12.5% |
| p95 | -146ms / -20.9% |
Regional splits reinforce that pattern. Users in Asia—who face the highest baseline latencies—saw reductions of about 77ms at p90 and 200ms at p95. Although Europe and North/Central America showed smaller absolute gains, the relative improvements were consistent across regions, hovering around 22% at p95.
| HTTP3 vs. HTTP2 | North and Central America | Europe | Asia |
|---|---|---|---|
| p25 | -3.20ms / -6% | -2.34ms / -2% | -3.73ms / -2% |
| p50 | -4.21ms / -5% | -3.84ms / -3% | -5.12ms / -2% |
| p75 | -9.03ms / -8% | -11.1ms / -6% | -15.0ms / -4% |
| p90 | -44.9ms / -17% | -47.3ms / -13% | -77.3ms / -14% |
| p95 | -118ms / -22% | -141ms / -21% | -200ms / -22% |
Two Takeaways and a Production Rollout
The experiment produced two major insights for Dropbox’s engineering teams:
- 0RTT mattered less than expected because nearly all connections to dropbox.com are already long-lived.
- HTTP3’s elimination of head-of-line blocking was the dominant factor in reducing latency, particularly on networks where packet drops are frequent.
Although only 10% of users notice the improvement, these are exactly the users who experience the worst slowdowns, disproportionately those outside North America. With the performance benefits now quantified, Dropbox’s Traffic team is moving forward with a production-ready HTTP3 buildout, with effects expected to extend beyond search to file operations and machine-learning content suggestions.
