Posted on by & filed under infrastructure, performance, Tech, Web Development.

Why HTTP/2?

HTTP/2 is an upcoming standard that will significantly improve web page delivery. It’s coming in February 2015 according to the HTTP/2 working group and is expected to be widely adopted because it’s an easy way for sites to make web pages load quicker and save bandwidth – meaning a better customer experience and money saved. I learned about it by watching the chair of the HTTP/2 working group, Mark Nottingham, talk at O’Reilly Velocity 2014. Some of the features he discussed are:

  • Pushing multiple resources for a single request
  • Header compression
  • Serving multiple page elements over a single TCP connection

More information can be found at the HTTP/2 working group site.

The ability to serve multiple resources over a single TCP connection was most interesting to me, because I can immediately measure that with a simple change. Since HTTP/2 isn’t out yet, I implemented a test environment using its predecessor: SPDY 3.1, on Nginx 1.6.2 and Chrome 38.

Performance Testing

To do my tests I created a simple page with elements totaling 903 kilobytes, containing 100 images of various sizes of ~ 300 bytes to 1.7 kilobytes. This is to simulate the content sizes that you’d download from a typical Internet site. I wanted to keep the page simple for this test, so I opted to put images on it rather than CSS and Javascript. It looked like this: spdy-vs-http11-nginx-page I used the following Python code to generate images of multiple sizes:

Turning on SPDY in nginx.conf was simply changing:


This allows both SPDY and HTTP/1.1 TLS, in case the browser doesn’t support SPDY.


The number of TCP sessions and packets transferred were captured by Wireshark running on my workstation. The server was running on a remote host on my local network. I used Chrome’s Developer tools to get the page load times. spdy-vs-http-test-results


When using SPDY, load time improved by about 6%. Only one TCP connection was used, and fewer packets were transferred than without using SPDY. The connection was established once to the web server, and all of the data (the index.html page plus 100 images) was sent over that single connection.

These results imply that fewer resources (memory, bandwidth, and connection processing) will be required when using SPDY as opposed to HTTP/1.1. A nice side-effect is that when SPDY (and ultimately HTTP/2) is implemented on the Internet, it won’t be only your web browser and web server that benefit. So do all of the proxies, load balancers, and firewalls in the delivery path between them! Less congestion across the Internet a win-win-win scenario for your site visitors, your company, and the rest of the web.

Next Steps

HTTP/2 is coming, and brings with it significant performance improvements. Much like HTTP/1.1 superseded HTTP/1.0 with its implementation of keep-alive-by-default, HTTP/2 will improve performance by reducing latency between the browser and server. If you want to get ahead of the curve, I’d suggest the following:

  1. Implement SPDY on your development environment, to measure performance like was done in this article. You might want to generate load from multiple clients.
  2. Ask your CDN and load balancer vendors if they are planning to support HTTP/2. A good sign would be that they currently support SPDY.
  3. Look at your site assets to see if they are spread amongst multiple servers, and consider consolidating them to one server – which will reduce the number of overall connections being made to load your site.
  4. If you are currently using image sprites, you might want to split those back out into multiple files, which could improve page rendering time.
  5. Some big companies are already supporting SPDY on their production environments to prepare for the HTTP/2 roll-out. Consider doing that to your own production environment.


Comments are closed.