According to Chrome the difference is "waiting" for the server response (47 ms Vs. 473 ms). You can tell that nginx is configured very differently between the two response types just by looking at the response headers.
I suspect the author set out to prove this and then made the environment fit their agenda. Nothing to see here. I'm sure Spdy is faster than HTTP/1.1 but nowhere near what this site claims.
The "Waiting" time listed in the Network panel of Chrome is actually the TTFB for each HTTP request/response. It is the latency from browser to server, server processing, and latency coming back. And because of the difference between latency and our huge bandwidth connections, your browser spends most of its HTTP networking time waiting.
This is exactly where the "SPDY vs HTTP" factor comes in. With HTTP, you request each item, and wait for a response. This can only be done one item at a time[1] per HTTP/TCP connection, with a limit of 2-6 (depending on the browser) HTTP/TCP connections per unique hostname. As I mentioned in a comment below, this benchmark is using a single hostname, which is the worse possible situation for HTTP.
SPDY, or HTTP/2, instead using a single TCP connection, and multiplexes all the requests over it. In other words it can be downloading pieces of many other responses, all while waiting on other requests.
[1] - Yes, I am ignoring HTTP pipelining, because every other person who implemented a piece of HTTP software did as well. And no, neither I nor anyone else cares about older Opera supporting it :-)
I increased the NGINX/ubuntu ulimit and work_connections, so you should see a fast test now without errors. Not prioritizing one protocol vs the other, I promise.
I suspect the author set out to prove this and then made the environment fit their agenda. Nothing to see here. I'm sure Spdy is faster than HTTP/1.1 but nowhere near what this site claims.