HTTP/2 & You
There’s been a new iPhone released every year since 2007, sometimes two per year. In that same timeframe there’s been 17 iOS releases. This has enabled us to be connected to the web 24/7/365. Forever. I wonder what my phone is doing as I’m typing this…sigh.
Yet the protocol used to exchange communications over the web, HTTP, didn't change one bit from 1997 to 2015. Last year HTTP/2 was standardized and it brought a much-needed facelift to how we communicate on the Internet. However it's adoption has been slow (for reasons we'll get to in another post).
HTTP/2 aims to help improve the performance of our web. For people who live their life down to the millisecond you can rejoice. Here are a few ways it’s making things quicker for us.
~It removes the need for front-end acceleration/optimization technologies. In 2012 there were a number of companies, Strangeloop, Aptimize, Blaze & AcceloWeb that all focused on optimizing the loading of web pages to get content to end users more quickly. Google open sourced a now deprecated protocol, SPDY that had the same goal. It was a hot market at the time and each one them got acquired, Strangeloop => Radware, Aptimize => Riverbed, Blaze => Akamai & AcceloWeb => Limelight Networks. Native to HTTP/2 is a lot of the core functionality of these front-end acceleration products like Image Spriting, Concatenating Java script & CSS files, Domain Sharding and Inlining Assets.
~Multiple assets can use a single TCP connection. In HTTP it was a 1:1 relationship. For web pages that have 100+ assets per page that means 100+ TCP connections needed to be opened. With images, java script and CSS all being used more, latency will go down as you can access that content over 1 TCP connection shaving milliseconds off load times.
As more and more sites are built on top of HTTP/2 I’m excited to see the potential performance gains we experience in the clicks to come.
Thanks for the feedback. Good points, especially around image compression. My statement "removes the need for front-end acceleration/optimization technologies" was referring to the functionality provided by the companies/protocols mentioned in my post. Strangleloop supports roughly 30 total sites currently. Aptimze supports 6 and SPDY is deprecated. HTTP/2 does replace a lot of those technologies. That data speaks for itself. Agreed though that web optimizations will never be fully replaced.
Hi Andrew, As most would agree. Nice post. Short and Sweet. Yes, HTTP/2 does remove the need for some FEO techniques which were designed to overcome HTTP /1.1 limitations. However, in my opinion, it does not remove the value of FEO all together and more important it opens opportunities to provide new FEO techniques. FEO optimization such as image optimization/compression/conversion are still very much needed and provide significant performance improvement. Reducing the size of your images by adapting to the user device is still an important FEO technique with HTTP/2. Even with the domain sharding example, since websites and applications have to serve all users, you need to assume that there will still be a significant HTTP/1.1 traffic and therefore might consider an FEO tool that can easily apply sharding only to HTTP/1.1 clients and consolidate resources into a single domain for clients using HTTP/2.0. Lastly, you need to take into account HTTP/2 Server Push and Prioritization features. This opens up opportunity to provide new FEO techniques to intelligently prioritize request and use server push to improve further the performance. For all these reasons, I believe that saying "It removes the need for front-end acceleration/optimization technologies." is misguiding. Laurent