Interesting read, but as far as I can tell this article mostly makes a strong case that using HTTP/2 at all is an "anti-pattern" for most projects[1] today, for at least three reasons.<p>Firstly, the presentation seems to start by arguing that round-trip latency has much more of an impact on perceived performance than bandwidth, but then argues for several techniques whose principle advantage is saving small amounts of bandwidth. So how much improvement will these new techniques really offer over current best practices for "an average web site"?<p>Secondly, the presentation seems to argue that simplifying front-end development processes by avoiding things like resource concatenation is a big advantage of HTTP/2, yet despite repeatedly emphasizing the need for the server to provide just the right responses to make HTTP/2 work well, it almost completely ignores the inevitable challenges of actually configuring and maintaining a server to take advantage of all of these new techniques in a real, production environment, with rapidly evolving site structure and content, numerous contributors, etc.<p>Essentially, this seems to be advocacy for dumping tried, tested, universal "workarounds" for the limitations of HTTP/1.1 in favour of new techniques that work well with HTTP/2 and only HTTP/2, but as an industry we have relatively little experience in what actually works well or doesn't with HTTP/2 and we have relatively few tools and relatively little infrastructure available that support it right now. And crucially, making the shift is not by any means a neutral activity; it is actively and severely harmful to several of the most important tried-and-tested techniques we've used up to now.<p>Finally, there is the simple matter of trust or, if you want to be kinder, future-proofing. The presentation notes that Google are deprecating SPDY from early 2016. That is the supposed HTTP replacement that was the New Shiny... yesterday, I think, or maybe it was the day before. When arguing for fundamental and irreversible changes in the basic development process and infrastructure set-up, you lose all credibility when your so-called standards fall out of favour faster than a GUI or DB library from Microsoft, and when your own browser frequently breaks due to questionable caching and related behaviour.<p>It's certainly true that HTTP/1.1 isn't perfect and there are practical ways it could be improved, but I don't think this presentation makes a strong case for adopting HTTP/2 as the way forward.<p>[1] YMMV if you actually do work for Google/Facebook/Amazon, and you really do have practically unlimited resources available to maintain both your sites and your servers, and you really are making/losing significant amounts of money with every byte/millisecond difference.