SPDY

I can’t help thinking of Speedy Gonzales when I read “SPDY.” You know, the cartoon mouse belting out “Andale! Andale! Arriba! Arriba!”

Speedy Gonzales is the fastest mouse in all of Mexico. But this article isn’t about him. It’s about speed, protocols and the web.

SPDY is a networking protocol built primarily by Google (with help from other organisations). It tackles the problems baked into HTTP/1.1, a protocol that’s roughly 15 years old. The internet looked very different back then. HTTP/1.0 and HTTP/1.1 did their job: static sites, basic HTML pages stitched together with images, tables and forms. Now we’re shipping web applications that pull in megabytes of JavaScript, stacks of CSS files, and we’re consuming them on phones and tablets as much as desktops.

Bandwidth has grown, and so have people’s expectations. Studies have measured how long the average user will wait for a page to load, and the number lands in the single-digit seconds. If a site takes longer than about 10 seconds, most people bail. (This doesn’t count people refreshing their email or chasing a specific site.) (This paper covers the topic in depth.)

Consider Facebook: roughly 757 million logins per month. Imagine how many synchronous HTTP requests that translates to. And the problem sits in the word “synchronous.” Chrome’s DevTools show these requests stacking up even on a simple site:

That’s the classic waterfall timeline. Every CSS file, custom font and JavaScript file loads one after the other. At the protocol level, the conversation between browser and server goes like this:

#Request 1:
Browser: GET index.html
#Response 1:
Server: 200 OK

#Request 2:
Browser: GET main.css
#Response 2:
Server: 200 OK

#Request 3:
Browser: GET app.js
#Response 3:
Server: 200 OK

#Request n:
...
#Response n:
...

But high-traffic sites like Facebook and Twitter don’t actually take 20 seconds to load. They load fast. How? Hacks. There are several tricks for shrinking the number of requests to the server:

• minification of CSS and JS files
• concatenation of CSS and JS files
• using data URLs for images
• using CSS sprites

These techniques are valid, but even after concatenating everything, you’re still making multiple HTTP connections. Which brings the second problem: congested TCP connections. Every TCP request goes through a three-step handshake (SYN, SYN-ACK, ACK) before a connection is established. TCP also uses a congestion control strategy called “slow-start.” Modern browsers either open multiple connections simultaneously or reuse a single connection for all files, but both approaches have drawbacks.

Enter SPDY. The good news: the official HTTP/2.0 specification is based on SPDY, and it brings a pile of improvements for developers and users alike.

SPDY implements the existing HTTP API, so there are no code changes required. Your site runs on HTTP/1.1 just as well as on SPDY and HTTP/2.0.

SPDY uses a single TCP connection between the browser and the server, and that connection is multiplexed. What does that mean?

The browser requests all resources at once and receives responses in any order. Here’s how the earlier example looks over SPDY:

#Request(s):
Browser: GET index.html
Browser: GET main.css
Browser: GET app.js

#Response(s):
main.css 200 OK
app.js 200 OK
index.html 200 OK

That’s the standout feature, in my view. There’s more in the spec too: TLS/SSL is now mandatory, every request is gzipped by default. HTTP requests get processed, tokenised, simplified and compressed, which means the protocol can track requests and skip resending unchanged headers.

This will change development practices. Concatenating CSS and JS files, for instance, won’t be necessary any more.

SPDY and HTTP/2.0 are genuinely exciting. I hope the draft spec gets finalised soon and becomes the standard. Browsers are already on board: the latest versions of all major browsers support SPDY, and web servers aren’t far behind. Apache, Nginx and Node.js all support it at the time of writing.