The Bottleneck of the Modern Web
Think of the early web like ordering at a diner with a single waiter who can only carry one plate at a time. You order your soup, wait for it to arrive, then order your salad, wait again, then order your main course. Each item must complete its round-trip before the next one begins. For a simple meal, this is fine. For a complex modern web application loading hundreds of assets, it's a disaster.
HTTP/1.1, standardized in 1997, was designed for a web of simple, mostly-text documents. It operates over TCP (Transmission Control Protocol) and, by default, handles one request per connection at a time. A browser loading a modern web page — which might require 100+ separate resources (HTML, CSS, JavaScript files, images, fonts, API calls) — faces a brutal choice: open dozens of parallel TCP connections (each with its own handshake overhead and memory cost) or queue requests and wait. Browsers settled on a compromise: open up to 6 parallel connections per domain. This helped, but it was a workaround, not a solution.
The specific failure mode is called Head-of-Line (HOL) Blocking: if the first request in a queue is slow (a large image, a slow database query), every subsequent request waits behind it, even if those later requests would complete in milliseconds. On high-latency mobile networks, this compounds into seconds of wasted time per page load.
HTTP/1.1 also sends headers — metadata like cookies, authentication tokens, and browser capabilities — as plain text on every single request. A cookie header alone can be several kilobytes, and it gets retransmitted identically hundreds of times per page load. This is pure waste.
The web needed protocols designed for the performance demands of the modern internet: high concurrency, low latency, and efficient use of bandwidth.