Introducing SPDY

We want to acknowledge and thank the amazing team of engineers at NGINX. They have been working on a SPDY implementation for quite some time and their work made it possible for us to roll out SPDY across our network. CloudFlare's core is built on top of the NGINX platform and we recommend it highly for anyone looking for a fast, secure, scalable web server. You can read more about their SPDY extension on their mailing list.

In 2009, Google began work on a new network protocol to make web pages faster. Dubbed SPDY (pronounced "speedy"), the protocol is designed to solve many of the bottlenecks that slow HTTP down. Beginning today, we're rolling out a beta of SPDY to CloudFlare customers. Read this post and then, if you're interested in participating in the beta, complete the beta application form.

Standard HTTP needs to make a new TCP request for all the objects on the page, Because there is significant overhead for each new TCP connection, all these connections slow down performance significantly. SPDY's biggest win comes from what is known as connection multiplexing. This means that mutiple objects from a particular site are requested and retrieved from a single request. Less connection overhead means faster page loads.

HTTP also requests objects in a particular order and one slow resource can block the loading of other resources. SPDY allows the browser to query for multiple objects in one request and for the objects to be sent down the wire as they are ready and out of order. Again, this can increase performance by not holding up the delivery of objects that are available quickly because some take longer to request.

SPDY includes some other performance wins as well. It allows HTTP headers to be compressed, which isn't possible with standard HTTP connections. The compression algorithm uses a HTTP-aware dictionary, which means common strings that appear in headers don't need to be sent across the network. Every byte you don't need to send not only reduces bandwidth use but, more importantly, increases web performance.

While there is a lot of excitement around SPDY, there are some caveats. The first is that only certain browsers support the protocol. Google's Chrome and the latest release of Firefox (version 11+) contain SPDY support. While the Internet Engineering Task Force (IETF) is considering SPDY as an official Internet protocol, it has not yet been adopted so it's not clear whether there will be additional support from browsers such as Microsoft's Internet Explorer and Apple's Safari.

SPDY is built on top of TLS, which means it requires a site to have a valid SSL certificate in order to work. This, unfortunately, limits SPDY only to CloudFlare's paid customers who have enabled Flexible or Full SSL support. Microsoft is working on revised IETF proposal that is SPDY-like, but removes the requirement for SSL/TLS. If the TLS requirement is removed in the future, we'll make SPDY (or whatever it comes to be called) available more broadly.

Very few sites currently support SPDY (Google's sites and Twitter being the most notable to support the protocol). As a result, there haven't been a significant number of real world case studies. A recent article by an Akamai researcher pointed out that for much of the web SPDY's performance wins will be limited. We've confirmed similar findings in our tests. The primary reason for this caveat is that most sites are a collection of objects from multiple sources. Since SPDY's multiplexing only works on a per-domain basis, if a site has objects pulled from multiple sources then even if all those sources support SPDY connections still won't be able to be multiplexed between them.

Finally, SPDY is complicated to setup for a lot of sites. Support on most web servers is nascent and unproven. Because of this, sites have been hesitant to setup SPDY support themselves.

The good news is CloudFlare is making SPDY extremely easy and features like Rocket Loader remove some of the biggest SPDY caveats, making the protocol even speedier. For SPDY support, CloudFlare acts as a gateway. Similar to how CloudFlare's Automatic IPv6 Gateway works, an origin server doesn't need to support SPDY. Instead, visitors with browsers that support SPDY connect to CloudFlare over the protocol. We handle the multiplexing and begin sending down objects we already have in our cache. The request to the origin server for non-cached objects is sent over standard HTTP/S. As a result, CloudFlare customers can implement SPDY support with a single click.

CloudFlare's Rocket Loader also helps with some of the multiplexing limitations. Rocket Loader was built to provide multiplex-like support over a standard HTTP connection. By gathering all scripts, regardless of where they're hosted, into a single HTTP request, Rocket Loader limits the number of HTTP connections that are needed. This also means that even third party scripts that appear on your page are requested under your site's domain. As a result, if you enable SPDY and Rocket Loader together then you will be able to get the benefits of multiplexing even for many of the object that make up your site even if they are hosted outside of your domain.

CloudFlare is rolling out the SPDY beta to select customers over the coming weeks. To be eligible for the beta, you need to have SSL enabled which requires one of CloudFlare's paid plans. As mentioned above, this is a limitation of the protocol and if that limitation is removed in the future then we'll plan on rolling out SPDY support more broadly. If you're interested in trying it, complete the beta application form and we'll send you an invitation as space is available.

At CloudFlare, we're committed to making the web speedier in every way we can. We're excited to offer the first easy way for websites that want to support SPDY to be able to do so easily and in a way that will get the most out of the protocol.