Over the last three years, the average page weight has grown by at least 15 percent per year. This is due to several trends such as increases in ad-related content, more images and more videos — as well as a lack of emphasis by designers and developers on reducing page weight. Google (along with other companies) has been on a mission to accelerate the Web across several fronts. One of the most interesting efforts is the Quick UDP Internet Connections (QUIC) project. The Web is built on top of HTTP/HTTPS, which typically uses TCP as a transfer protocol. TCP was recognized a long time ago is sub-optimal for the request-response model of the Web. An average Web page makes about 100 HTTP requests to tens of different domains to load all of its content. That causes significant latency issues due to TCP’s design.

QUIC

QUIC is based on the connection-less UDP and doesn’t suffer from the same design limitations as TCP. It requires building its own infrastructure for ordering and re-transmission of lost packets and dealing with congestion, but has a lot of interesting tricks. The ultimate goal is to improve TCP and incorporate ides from QUIC into an improved TCP protocol. Since TCP evolution is very slow, working with QUIC allows faster iteration on novel ideas such as innovative congestion management algorithms without disrupting the larger Web.

Where to Get Started

There is currently QUIC support in Chromium and Opera on the client side and Google’s servers support QUIC on the server side. In addition, there a few libraries such as libquic and Google has released a prototype server for people to play around with QUIC. One of the major concerns was that the UDP protocol could be blocked for most people, but a survey conducted by Chromium showed that it is not a common occurrence. If UDP is blocked, QUIC falls back to TCP.