Simple Comparisons of HTTP, HTTPS, SPDY/2 and SPDY/3

‹prev | My Chain | next›

tl;dr SPDY rules speed tests.

Amazingly, the average web page includes 85 resources (per httparchive.org). My "real world" web page only has a dozen images:

So I add separate copies to the bottom of the page:

I add an artificial 100ms round trip time:

➜  ~  sudo tc qdisc add dev lo root netem delay 50ms
[sudo] password for chris: 
➜  ~  ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=1 ttl=64 time=100 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=2 ttl=64 time=100 ms

That is a little higher than is typical in the wild. I like it because it makes math easier and is not too far off.

Now, when I load the vanilla SSL site and watch in Speed Tracer, I see:

A total of 5.03 seconds (5.98 - 0.995) for SSL.

The "real world" SPDY running on the spdy-v3 branch of node-spdy:

SPDY/3: 1.1 seconds.

And finally, a push version that uses SPDY server push to push all of the images directly into Chrome's chache after the first request:

SPDY/3 push: 0.74 seconds.

Since I am doing all of this comparing, I might as well see what vanilla HTTP looks like:

HTTP: 2.7 seconds.

Important the SPDY vs HTTP comparison is not a fair one. Because of some deficiencies in Speed Tracer, it is not possible to include the SSL handshake in addition to the initial SPDY connection. The SPDY connection is from a cold start (I stop the server before each). Still, the SSL handshake would add ~0.5 seconds to the entire conversation, meaning that SPDY is still an easy winner.

For completeness' sake, spdy/2 looks like:

SPDY/2: 1.25 seconds.

And SPDY/2 with push:

SPDY/2: 1.03 seconds.

So the final tally is:

Trial	Time (s)
SSL	5.03
spdy/3	1.1
spdy/3 push	0.74
HTTP	2.7
spdy/2	1.25
spdy/2 push	1.03

I am unsure why the spdy/3 numbers both beat the corresponding spdy/2 numbers. I would expect them to be about the same since spdy/3 adds flow control, but little to speed up this particular page. For now, I chalk it up to small number statistics—I only ran one run for each.

Regardless, the clear winner is SPDY. Tomorrow, I will repeat the spdy/3 part of the experiment with Chrome and Firefox—this time watching TCP traces. That should serve as a nice last word on spdy/3 flow control.

Day #394