History of SPDY
After failed attempts to start development of new protocol or change the existing HTTP/1.1 protocol, Google had decided to work harder on this topic and they have executed the project called SPDY (pronounced as Speedy). Thy focused on resolving most common issues with obsolete protocol which is primarily faster page load with backward compatibility with existing infrastructure still active on internet worldwide.
Around 2012/2013 public has started to get involved more in developing HTTP2 and, eventually, IETF (Internet Engineering Task Force) which made pretty strong majority of earlier mentioned public started a lead on this project which was the official start of development on HTTP2. Base idea was taken from existing SPDY. Final protocol adoption has taken place in February 2015.
This was the green light for web servers and web browsers developers to start including HTTP2 in their own products even though it was planned to have HTTP2 officially adopted in August of 2015. As developers of web servers and browsers continued building products with HTTP2 support included the actual effect will can now be seen more clearly as we go into the future.
What HTTP brings on table?
To explain the need for HTTP2 it is good to review certain behavior of HTTP1. Let us see what happens when a page is being opened in browser asking for HTTP1 connection type to be completed. Browser asks for a resource on the server and then server returns HTML (or other) code base which then browser needs to render and make some sense out of it. HTML contains list of tags in ti where each tag loads a resource or anyways adds a property to the page. A short overview of what HTML can contain (usually) lists CSS, JS, Images, Webfonts,… Now, browser starts requesting one after the other resource opening separate connection for each resource. This means that the simple page of 3 css files, 5 js files and 10 images will make browser open 18 connections to deliver 18 files. This is not effective way of serving content, obviously. One way, before HTTP2 was worked on, web developers were using browsers ability to make parallel requests if resources were coming from different domains thus web developers were often using up to 4 (not more than 6) domains to deliver static resources to web browser. This is called domain sharding. This will tell browser to open parallel requests for up to 6 different resources at the same time – just because different domains are used.
HTTP2 solves this gap by not providing one resource at the time when browser requests index.html, it will send everything associated with this HTML file. Not just file itself.
To bring the importance of HTTP2 closer lets list out some of the importnat features HTTP2 provides.
Given that HTTP2 was derived from SPDY which is google product and now, we are seeing how google requires more and more that websites have HTTPS support due to security aspect this will fall on HTTP2 as a requirement to lead this migration from HTTP to HTTPS. HTTP2 can’t be used without HTTPS support which completes the circle and wraps all features into the whole. It goes without saying that most of good ranked websites will have to migrate to HTTPS if they want to keep the ranking on Search list.
This is one of the best features HTTP2 has to offer and one of the key ingredients which made HTTP2 very desirable after it was announced for the first time. I’ve mentioned that HTTP1 was serving one file at the time while other files were not delivered until the previous one was loaded/delivered. Multiplexing allows browser to receive all associated resources in a single request/connection thus reducing loading time drastically.
Aside from regular compression inherited from HTTP1, HTTP2 supports headers compression. HTTP1 was working with headers in plain text form while HTTP2 will use binary code to define headers which makes delivery much more effective by reducing the size of traffic making speed of delivery significantly increased.
Third most important feature is ability of the server supporting HTTP2 to send data before browser even asks for it. We were attending one of the WP meetups in Belgrade when respectable developer explained the difference between HTTP1 and HTTP2 on an example of a waiter in a restaurant:
HTTP1: You call a waiter, waiter approaches you, you ask for a slice of bread, waiter gets you one, then ask for a salami, waiter gets it for you, you order slice of cheese, waiter gets it for you, you order another slice of bread and waiter gets it for you. Eventually you have got yourself a sandwich.
HTTP2: You call a waiter and as for a sandwich, waiter gets a sandwich for you, brings you coffee and waits in case you need anything else.
Why is HTTP2 good for CSS and small images ?
One of cool approaches in web development was in usage of “stripes”. Stripe is a large image with sets of smaller ones on it and then we’ve used positioning definitions to slide big image up-down, left-right to show through some viewport small one that was nested on the big image. This way, regardless of size, we are still saving time on not requesting several images (how my big image can hold) but only one (big image). This way, transfer is a bit larger but, number of connections is significantly lower and with small files the less connections you have – the better. What makes next step in web performance evolvement is usage of webfonts holding small graphics showed to user based on different element class loaded. Here is where HTTP2 jumps in with even more performance boost. Instead of loading entire element and then showing only what needs to be shown to end user, HTTP2 is sending only the part that is going to be shown to end user – no unnecessary stuff.
CSS and JS delivery is very optimized in a way that not entire css of js file is delivered on request of HTML file that will be populated by definitions in css and js files. When HTML is requested HTTP2 supporting server will serve only parts of css and/or js fiels that are going to be used on the page in question.