In prior articles, we've written extensively about website performance and securing your website, both factors Google has publicly announced as search ranking factors. These articles provide extensive tips using existing tools and technologies to improve your site performance and security (tips we highly recommend you follow). But did you know Google also developed and is championing a new web transport protocol called SPDY that addresses many of the inherent performance and security flaws in the web today?
In this article I will dive into more detail on how this new protocol works, why it is important to you, and how you can get started using it today.
From experiment to standard
Google created the SPDY protocol as a multi-year experiment to find a faster way for browser and servers to communicate. The results have been so positive that the Internet Engineering Task Force (IETF) is using SPDY as the basis for HTTP/2, a replacement to the current network protocol that powers all Internet web traffic today. While technically HTTP/2 is still an evolving specification, many web browsers, web servers, networking devices, and websites already support both SPDY and HTTP/2 in its current form.
While there are some subtle differences between SPDY and HTTP/2, for the purposes of this article it's safe to use those terms interchangeably. As HTTP/2 rises to prominence in the popular vocabulary, the SPDY vernacular will fall out of use in favor of HTTP/2. For this reason, I will simply refer to SPDY as HTTP/2 for the remainder of this article.
What problem is HTTP/2 trying to solve?
To understand why Google and the IETF are creating a new version of HTTP, we need to understand the fundamental performance limitations we have today. It helps to consider this analogy:
Imagine if all the roads in the modern world were built back during the age of horse drawn carriages: narrow, bumpy and with low speed limits (still true in some cities...). Sure it took a while to get anywhere, but the delay was mostly due to the speed of your horse. Flash forward to today: same bumpy roads, but now everyone is driving a car. Now the horse is not the bottleneck, but instead all those cars piling up on the same log jammed road!
Believe it or not, most website traffic today is not far from this analogy. The original HTTP protocol dates back nearly 25 years. The most recent update is HTTP/1.1 which was standardized back in 1999. That is a lifetime in Internet time!
Like those narrow, bumpy roads of yore, the web back then was a very different place: smaller web pages, slower Internet connections, and limited server hardware. In a sense, the "horse" was the bottleneck. HTTP/1.1 was very much a product of those times.
For example, when web browser loads a web page using HTTP/1.1 it can requests resource (like an image, JavaScript file, etc) one at a time, per connection to the server. It looks like this:
You'll notice the browser is spending a long time waiting on each request. While HTTP/1.1 won't let us make multiple requests at the same time over the same connection, browsers can try and speed things up by making two connections to the same server, as shown in the diagram below:
Using two connections is a little better, but the browser still spends a lot of time waiting to get a download. And we can only download two resources at a time. We could try and making more connections to download more resource in parallel. Modern browsers try to do this and can make between 2-6 connections per server. Unfortunately this is still an poor approach, because each connection itself is used so inefficiently. Since the average web page has over 100 resources, the delay in making all those individual requests one at a time over just a few connections added up and your page loads slowly.
You can actually see this inefficiency by looking at a waterfall chart. We discussed waterfalls in a previous Moz post on optimizing Time To First Byte, and we also have a detailed guide on how to read waterfall charts. Most waterfall charts will show long green sections which represents the time the browser is waiting to download a resource. All that time wasted on waiting instead of downloading is a major reason why websites load slowly.
This inefficient waiting on resources is why optimizations like combining JavaScript or CSS files can help your site load faster. But optimizations like this are just stopgap measures. While you can (and should) continue to optimize our pages to make fewer and smaller requests, we're not going to truly evolve to the next level of performance until we "fix the roads" and improve the fundamental way in which the web communicates. Specifically, we need to find a better way to utilize those network connections.
This is where HTTP/2 comes in.
The solution: HTTP/2
At its core, HTTP/2 is about using the underlying network connections more efficiently. HTTP/2 changes how requests and responses travel on the wire, a key limitation in the prior versions of HTTP.
HTTP/2 works by making a single connection to the server, and then "multiplexing" multiple requests over that connection to receive multiple responses at the same time. It looks like this:
The browser is using a single connection, but it no longer requests items one at a time. Here we see the browser receives the response headers for file #3 (maybe an image), and then it receives the response body for file #1. Next it starts getting the response body for file #3, before continuing on to file #2.
Think of multiplexing like going to the grocery store and calling your spouse just once to get the full list: "Okay we need milk, eggs, and butter. Check." Compare this to HTTP/1.1 which is like calling your spouse over and over: "Do we need milk? Okay, bye." "Hello me again—do we need eggs too? Yep, okay.", "Okay sorry one last question, do we need flour too? Nope, good."
All of that data is interwoven much more efficiently on that single connection. The server can supply the browser with data whenever it is ready. There is no more "make request; do nothing while waiting; download response" loop. While slightly more complex to understand, this approach has several advantages.
First of all, network connections don't sit idle while you are waiting on a single resource to finish downloading. For example, instead of waiting for one image to finish downloading before starting the next, your browser could actually finish downloading image 2 before image 1 even completes.
This also prevents what is known as head-of-line blocking: when a large/slow resource (say for example a 1 MB background image) blocks all other resources from downloading until complete. Under HTTP, browsers would only download one resource at a time per connection. HTTP/2's multiplexing approach allows browsers to download all those other 5 KB images in parallel over the same connection and display as they become available. This is a much better user experience.
Another great performance benefit of HTTP/2 is the "Server Push" feature: this allows the server to proactively push content to a visitor without them requesting it. So for example, when a browser visits your website, your server can actually "push" your logo image down to the browser before it even knows it needs it. By proactively pushing needed resources from the server, the browser can load pages much quicker then was previously possible.
Last, but not least: HTTP/2 works best with HTTPS. As we mentioned before, both performance and security are an ever increasing component of search ranking. While the HTTP/2 specification technically allows for use over non-HTTPS connections, Google's earlier SPDY protocol required HTTPS. For compatibility reasons, most web server software will only use HTTP/2 over an encrypted HTTPS connection. Getting on the HTTPS bandwagon not only protects the security of your users and is good for your search ranking, but also is the most effective way to adopt HTTP/2. For more information, see our prior post on enabling HTTPS.
The future, today!
So clearly HTTP/2 offers some great benefits for both speed and performance, but what does this mean to you right now? Well, you may be surprised to learn, HTTP/2 is already available, and can be supported by you without impacting your old users running on HTTP/1.1.
You can think of HTTP/2 just like any other protocol, or even a spoken language. For it to work, you just need an agreement from both the sender and receiver to speak the same language. In this case, the "sender" is the web browser and the receiver is your web server.
Browser support
Since it's unlikely you will create your own web browser like Microsoft, Google, Apple or Mozilla, you will not need to worry about the "sender" side of the equation. Support for HTTP/2 in the web browser is already in widespread use across the modern browsers of today, with adoption only increasing as older browser versions age out.
In fact, the latest versions of all the major desktop web browsers already support HTTP/2. Chrome and Firefox has supported it for several years. Apple added support to Safari in fall of 2014 with Safari 8. IE 11 supports HTTP/2, but only if you are running Windows 8.
Similarly, there is already widespread HTTP/2 adoption on smart phones as well. Android's older web browser, helpfully named Browser, has support HTTP/2 for several years. The current default browser for Android is Google's Chrome browser. Mobile versions of Chrome use the same networking code as Desktop Chrome. This means that both Chrome on Android devices, as well as Chrome on iOS devices, both support HTTP/2. Apple added support to the iOS version of Safari with iOS 8.
Your best best is to look at your website analytics and see what web browsers your visitors are using. Chances are, the majority of visitors have HTTP/2 capable web browsers (you can check against this list of desktop and mobile browsers that support HTTP/2). In that case, you can safely move on to the next step.
Web server support
While you have little control over which browsers your visitors use, you do have direct control over your web server. Put quite simply, to support HTTP/2 you need to select a web server that supports HTTP/2 and enable it. And of course, that server should also continue to support HTTP/1.1 as well because you will always have users using older browsers.
Continuing our "spoken language" analogy from before, you can think of HTTP/1.1 and HTTP/2 as different languages like English or French. As long as both parties can speak the same language, they can communicate. If your server only supports HTTP/1.1, then visitors can only speak to it with HTTP/1.1. But, if your server also supports HTTP/2, then your users browser will also choose to speak (the faster) HTTP/2. And finally if your server does speak HTTP/2, but your users browser does not, then they will continue to speak HTTP/1.1 just as before, so there's no danger in "breaking" your older users.
Right now, both the Apache and nginx web servers support HTTP/2. nginx supports HTTP/2 natively, and Apache supports it via the mod_spdy module. Since Apache and nginx serve traffic for 66% of all active web servers, chances are good that your website's server can support HTTP/2 right now.
If you aren't using nginx or Apache you still have other options. There are a number of smaller, more specialized projects that support HTTP/2. You can also place a reverse proxy that support HTTP/2 like HAProxy in front of your existing web server to get the same benefit as having a web server that directly supports HTTP/2.
If you run your site through a hosting provider, check with them to see which web server version they are running. Major sites like WordPress.com and CloudFlare all already offer HTTP/2 support. If your provider is not yet supporting HTTP/2, let them know this is important!
Adding HTTP/2 support
As I mentioned, HTTP/2 is simply another language your web server can use to communicate. Just as a person can learn a new language while remembering their mother tongue, your web server will continue to know how to communicate HTTP/1.1 after you add support for HTTP/2. You aren't in danger of shutting anyone out from speaking with your site. People using newer browsers will communicate using HTTP/2, and older browsers will continue using the older HTTP/1.1—nothing breaks. If you have the time, there really is no reason not to update your site to support HTTP/2.
Remember, HTTP/2 is just a better way to transmit web content than HTTP/1.1. Everything else about your website (the URLs, your HTML markup, your redirects or 404 pages, your page content, etc) all stays the same. This makes adding support for HTTP/2 fairly straight forward:
- Make sure your website is using HTTPS. See our previous article on implementing HTTPS without sacrificing performance.
- Verify your server software or infrastructure can support HTTP/2.
- Update and configure your server software or infrastructure to support HTTP/2.
That's it. Your website is now using HTTP/2.
Well hopefully it is. The steps involved to update/configure your website will vary depending on your what software you use, so we cannot provide you with detailed guide. However, we did built a free tool, SPDYCheck, which you can use to verify you have properly configured your website to HTTP/2 (aka SPDY). SPDYCheck works like a checklist, verifying each step of how a browser negotiates with your server to communicate via HTTP/2. It can tell you where in the process things are not working, and it also provides helpful recommendations like enabling Strict Transport Security. With SPDYCheck, you can be sure that everything is functioning properly, and verify that you site supports HTTP/2.
Conclusion
We all know that faster sites help improve search engine rankings, but faster sites also offer better user experiences. Faster sites engage your users longer, and promote sharing further sharing and linking. HTTP/2 is an amazing leap forward that can help improve the performance and user experience of your website. However, HTTP/2 is not a silver bullet. Optimizations like losslessly optimizing your website's images can have a big effect on your site's performance and will still be needed. In short, while you should add HTTP/2 support to your website, make sure you are doing other optimizations and following performance best practices to ensure the best possible user experience. If you are looking for a place to start, or want to see how your site is doing, Zoompf's free performance report is a great way to understand what you can do to make your website faster.
The main benefits of HTTP/2 are lot:
Of course the real problem there it HTTP/1.1 and it's old age of almost 15 years. Many things was changed and today isn't optimal anymore. The problem is that HTTP/2 still providing almost all with backward compatibility with HTTP/1.1
Honestly i expect something new like removing cookie spam, stop wasting bandwidth and so on. But probably will see this with HTTP/3. I only hope that will not wait another 15 years for it.
Hey Peter,
Great summary of HTTP/2 benefits. Keep in mind that HTTP/1.1 isn't bad just because it is old. TCP, IP, and SMTP are all examples of 30+ year old technology that is still going strong and work fairly well.
The problem with HTTP/1.1 is that it was designed with certain assumptions about the network that are no longer true today. This means that HTTP/1.1 does a poor job of fully utilizing your network connection.
I think you did a great job of taking something that's pretty technical and explaining it in a way that makes sense in layman's terms. I always appreciate this place for finding ways to explain things in a way that everyone can grasp. Incredible tool for keeping non-tech SEO's "in the know". Thanks much!
It lloks like this protocol is custom build for Google and large operators/ISPs. Smaller operators will face resource starvation with SPDY links much like keepalives starve an apache server from new connections. In other words it enforces persistent connections and that is a killer for small sites when their traffic inches upward.
Implementations will have to take into account the number or parallel requests they can serve then they should force a link tear-down.
As for the binary aspect of the communication, I am vehemently against it. Interoperability requires clear text transports. will we now have to buy the debugging tools ?
Just thinking
.A.
Kangelos,
Actually, SPDY will *prevent* resource stravation, since only a single TCP connection is made to a server. HTTP/1.1 allows multiple TCP connections to be made to a website per visitor, meaning an HTTP/1.1 website can only support 1/2 or 1/4 the number of uses as a HTTP/2 website before exhausting available port numbers.
I also understand your concerns about binary vs. clear text transport, but to say that "Interoperability requires clear text transports" is patently false. The very fabric of the Internet, TCP and IP, are both binary protocols. TLS is a binary protocol. However interoperability clearly exists at those levels. If you are concerned with debugging, tools like WireShark make it easy to see what is happening to a SPDY connection.
While encryption is a great thing, the de-facto requirement for SSL kills HTTP/2 for small site owners.
I have 30 small sites. How much do 30 SSL certificates cost each year ?
Alot probaly. But if they are so small then speed will probaly not be a issue anyway
You don't necessarily have to buy them, but it gets tricky when it comes to the implementation. Especially if you cross-link those websites, and one of them isn't using https. However, while HTTP/2 works best with HTTPS, it works fine with HTTP too.
Gerond,
Unfortunately it does not. Right now, stable, non-development versions of Chrome and Firefox only support SPDY/HTTP2 over TLS encrypted connections.
The EFF has a proposed solution for the cost and complexity of setting up SSL. If everything works the way they say, it should largely be a non-issue after Summer 2015. See https://letsencrypt.org
https://www.startssl.com/?app=1
https://buy.wosign.com/free/
Cloudflare.com also provides with free ssl certificates.
Billy, thanks for this really easy-to-understand breakdown of HTTP/2 and SPDY. It's crazy to think this technology hasn't been adopted and pushed onto the scene earlier... it's common sense and good for everybody involved.
Why hasn't HTTP/2 become the mainstream adaptation already? Can you speak to why this took so long (~15 years)?
Thanks Brady! Couldn't agree more, but inertia always takes energy to overcome. We've also gotten very good about working around the problem (faster network connections, more connections in parallel, faster computers, etc.) which have made the problem more bearable, but still it's avoiding the fundamental problems. With more efficiency in our network connections AND faster connections, we'll get a true jump in performance...Which i'm sure we'll fine new ways of filling up in no time :-)
This is one of the best posts I have read in recent times. Not preachy and to the point and complicated concepts explained in simple terms.
Definitely deserves more than 27 thumbs up.
Thanks a lot Billy.
Thanks,
Sajeet
There is not much relevant information on this topic on the internet, thanks for sharing some knowledge and very well explained.
Is it just me or Google pushes intensively for HTTPS? Why else developing a protocol that requires a TLS connection?
Good post !
I shall not know many in http / 2, but your article helped me to understand his holding and outs.
This is an amazing piece. Thanks for making it so well-written and easy to understand
Hi Billy,
Great article and very useful. I especially liked you bumpy road example, awesome explanation. According to Cloudflare more than 88k of the Alexa top 2 million websites are now HTTP/2-enabled which is great and the number of these websites are increasing day by day. At Kinsta we are pretty obsessed with website performance and load time optimization so we created this in-depth ten chapter long guide about the HTTP/2 technology. What it is, how does it work and how to enable it on your server. We cover everything you need to know. You can take a look st it I hope you will find it useful:
How HTTP/2 Will Speed Up the Web - The Ultimate Guide
Looking forward to more tutorials from you Billy!
ey there…First of all I just want to thank you to you guys for sharing such a wonderful information with us and believe me these information is very valuable for me and I am surely try those tips.
Does HTTP/2 also provide for faster download speeds, like if your site sells downloads of programs, videos, music, etc?
We tried out SPDY for a while but ultimately found that the SSL handshake added more to page load time than the speed improvement gained through SPDY. Anyone else found that?
Hi Fergus, you should check out our prior Moz post on that very topic: https://moz.com/blog/enabling-https-without-sacrificing-web-performance.
Great post, Billy! I too lament the lack of support for http2 on IIS 7. Sigh. I guess it's to be expected from the company that didn't think the internet would really take off :-p
Michael,
The IIS team has said they plan to include HTTP/2 support in upcoming versions. In the mean time, I suggest using HAProxy to terminate TLS and to provide support for HTTP/2.
https://blogs.msdn.com/b/ie/archive/2014/10/08/http-2-the-long-awaited-sequel.aspx
Was a great article, got me excited to go take a look at implementation. I can't find anything about how to set this up on IIS. Any thoughts?
HTTP/2 will be available only in Windows Server 10:
https://blogs.iis.net/nazim/archive/2014/10/29/http-2-for-iis-in-windows-10-technical-preview.aspx
I saw that same thing but was hoping it could be put on IIS 7 somehow. Looks like any SPDY support that was on IIS is being shut off as well. Keep trying to find ways to speed up the site but hitting dead ends with IIS.
Well you can't put HTTP/2 on IIS 7 or 7.5 due implementation issues. But you can build reverse proxy using nginx to cover IIS and taking benefits.
I know this will require Linux or BSD for nginx. I'm not recommending using Windows port.
Correct, SPDY/ HTTP/2 is not currently supported on IIS, but it's inevitable Microsoft will cave to pressure as the HTTP/2 spec continues to gain traction. Remember originally SPDY was proposed by Google, so you can draw your own conclusions on why Microsoft has or has not embraced the protocol earlier, but as it gets adopted into HTTP/2 it becomes inevitable that everyone will need to play on the same field.
Great article! Looking into doing some testing with Zoompf as well! Thank you!
HTTP/2 can be a great leap forward, but still I have figured out in many cases people are not even optimizing there websites to decrease the load time, even the websites of big brands show the signs of load time discrepancies. That simply means we are not utilizing HTTP/1.1 to its fullest extent. However, the combination of two can be great!
Salman,
You are absolutely correct! There are a lot of websites, from really big brands, that are making some pretty terrible performance mistakes. HTTP/2 is an improvement certainly, but there are many other performance optimizations you should be making first to your website.
This is something to look forward to!
Wah, what an article over HTTP/2, I am really impressed. HTTP/2 will really make website downloading faster. I think if HTTP/2 will be available for all in recent future, SEO don't have to bother about speeding up websites through GZIP, image size decrease, leverage browser caching. I really want opinion from others. I know the writer suggested to keep those good practice to minimize downloading speed. I am really interested to know how faster it will download a website comparing to http/1.1 ( if a website loaded in 2.5 seconds in HTTP/1.1 how much time in HTTP/2, if it is possible to give an approx time).
But how HTTP/2 works it is clear to me. Thank you.
Zoom,
HTTP/2 simply alters how data is transmitted on the wire to be more efficient. However, bloated images will always make a website slower. HTTP/2 doesn't change that. Same thing applies with client-side caching. As I said at the end of the article, HTTP/2 doesn't alleviate the need to be smart about how you create your content.
How does this fit with cloud server solutions? (such as AWS and Azure)
Richard,
I'm not sure I understand your question. It doesn't matter where your web server software is, or who is hosting or managing that system. You want to upgrade/update that software to something that supports HTTP/2, or use a reverse proxy like HAProxy in front of your website to provide HTTP/2 functionality. The process is the same for real vs. virtual systems.
Hi Billy, Great informative piece. So quick question here, if we enable Cloudflare and it uses HTTP/2 we do not have to worry about or own server updates say with Apache? Thanks
True.
But it's better to invest time in local infrastructure too.
Thank you for your good information