Our key findings are as follows.
• In the desktop environment, QUIC outperforms TCP+HTTPS
in nearly every scenario. This is due to factors that include
0-RTT connection establishment and recovering from loss
quickly—properties known to provide performance benefits.
• However, we found QUIC to be sensitive to out-of-order packet
delivery. In presence of packet re-ordering, QUIC performs
significantly worse than TCP in many scenarios. This occurs
because QUIC interprets such behavior as loss, which causes
it to send packets more slowly.
• Due to its reliance on application-layer packet processing and
encryption, we find that all of QUIC’s performance gains are
diminished on phones from 2013 and late 2014. It is likely that
even older phones will see worse performance with QUIC.
• QUIC outperforms TCP in scenarios with fluctuating bandwidth. This is because QUIC’s ACK implementation eliminates
ACK ambiguity, resulting in more precise RTT and bandwidth
estimations.
• We found that when competing with TCP flows, QUIC is unfair
to TCP by consuming more than twice its fair share of the
bottleneck bandwidth.
• QUIC achieves better quality of experience for video streaming,
but only for high-resolution video.
• A TCP proxy can help TCP to shrink the performance gap with
QUIC in low latency cases and also under loss. Furthermore, an
unoptimized QUIC proxy improves performance under loss for
large objects but can hurt performance for small object sizes
due to lack of 0-RTT connection establishment.
• QUIC performance has improved since 2016 mainly due to a
change from a conservative maximum congestion window to
a much larger one.
• We identified a bug affecting the QUIC server included in
Chromium version 52 (the stable version at the time of our
experiments), where the initial congestion window and Slow
Start threshold led to poor performance compared with TCP.

Google-reported QUIC performance. The only large-scale
performance results for QUIC in production come from Google.
This is mainly due to the fact that at the time of writing, Google
is the only organization known to have deployed the protocol in
production. Google claims that QUIC yields a 3% improvement in
mean page load time (PLT) on Google Search when compared to
TCP, and that the slowest 1% of connections load one second faster
when using QUIC [18]. In addition, in a recent paper [26] Google
reported that on average, QUIC reduces Google search latency by
8% and 3.5% for desktop and mobile users respectively, and reduces
video rebuffer time by 18% for desktop and 15.3% for mobile users.
Google attributes these performance gains to QUIC’s lower-latency
connection establishment (described below), reduced head-of-line
blocking, improved congestion control, and better loss recovery