Tuesday, May 22, 2012

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 ( 56(84) bytes of data.
64 bytes from localhost.localdomain ( icmp_req=1 ttl=64 time=100 ms
64 bytes from localhost.localdomain ( 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:

TrialTime (s)
spdy/3 push0.74
spdy/2 push1.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


  1. Well, I'd like to see a fair bench :

    SPDY + no image domain sharding (best config)
    HTTP + image domain sharding (best config : img1.yoursite.com, img2.yoursite.com ...)

    I just want to be sure that over optimized SPDY site is really faster than an over optimized HTTP site.

    Because many SPDY tricks can be done with HTTP. Multiplexing can be emulated with image domain sharding, for example.

    1. I did a bit of that last year:

      * http://japhr.blogspot.com/2011/07/spdy-and-good-ssl.html
      * http://japhr.blogspot.com/2011/07/spdy-vs-ssl.html
      * http://japhr.blogspot.com/2011/07/spdy-vs-rtt.html

      It's a pain to set that up with reasonable settings so I didn't bother doing that again this time around.

      FWIW I think the authors of SPDY still favor the idea of CDNs even with SPDY.

      That said, you're never going to beat SPDY server push with HTTP -- regardless of CDNs or any other HTTP workaround. No RTT and hot tubes can not be beat :)

  2. Hi,

    I am very much new to Web development and I have to do a comparison of http, https and spdy (or http 2.0).

    how can I test and compare the page load time from a browser (client) by switching to different versions of http? e.g. I want to test what is the PLT for http 1.0 versus 1.1 and 2,0.. how can I configure my browser?