Lovely primer on HTTP/2, but it misses the biggest advantage: Breaking up a big, sequential request into smaller, concurrent parts. Say you have a compound request that takes 200ms... evertpot.com/h2-parallelism/
If you can break that into one initial request that takes 50ms, followed by 3 concurrent requests each taking 50ms, in the HTTP/2 example, you’ll only spend ~100ms on the full request, because the 3 x 50ms requests happen simultaneously over the 1 TCP connection.
And breaking the big compound request into 4 smaller requests have massive cache advantages too. The compound request needs to resend THE WHOLE THING if any of the 4 sub-parts change. The broken up version gets 4 local caches that can live much longer.
This is the problem with essentially HELLO WORLD testing. Most real apps don’t have full, compound requests that only take like 5ms. They often take 50ms, 100ms, 200ms, or maybe even 500ms! Then the HTTP/2 approach with smaller, individual requests is huge.
We’ve been working on some new framework techniques at Basecamp specifically targeted at taking advantage of how HTTP/2 changes the trade-offs. It’s been a massive code simplification AND speed optimization. Excited to share our work later this year!
