SPDY Not As Speedy As Hyped? 135
Freshly Exhumed writes "Akamai's Guy Podjarny reveals after testing: SPDY is different than HTTP in many ways, but its primary value comes from being able to multiplex many requests/responses from client to server over a single (or few) TCP connections. Previous benchmarks tout great benefits, ranging from making pages load 2x faster to making mobile sites 23% faster using SPDY and HTTPS than over clear HTTP. However, when testing real world sites I did not see any such gains. In fact, my tests showed SPDY is only marginally faster than HTTPS and is slower than HTTP."
Amazon Silk (Score:5, Interesting)
Amazon's Silk browser, used in the Kindle Fire, implements SPDY and a reverse proxy cache in the Amazon cloud that is supposedly capable of predictive retrieval and caching. While it occasionally is faster than HTTP, on the whole it doesn't seem to mesh well with my browsing habits and I've disabled the so-called "accelerated page loading" on my KF. Judging from comments in the Amazon forums, my experience is not unusual.
Re:Not so fast...YET (Score:5, Interesting)
No, he proxied the sites through a SPDY proxy, but that's not really a good way to test. Most sites shard domains to improve performance. Unfortunately, that basically destroys SPDY's pipelining advantage. The author tried to compensate by doing simple sub-domain coalescing (which he admits significantly increased SPDY performance where it applied) but that's just too coarse of an approach, as sharding is rarely ever restricted to subdomains. He also doesn't understand how browser parsing and loading works, and specifically that script execution and resource loads can be deferred (which is another key to keeping SPDY's pipeline full).
Basically, his tests showed that SPDY isn't magic faster dust. You will need to modify your site a bit if you want to really see advantages from it. And, you may see a minor performance degradation on an HTTP site that's unoptimized or heavily optimized in a way that doesn't play well with SPDY. However, if your site is optimized correctly, SPDY is still a big win over HTTP/HTTPS.
Current HTTP Speedup Tricks Hurt SPDY (Score:5, Interesting)
As someone who's job it is to work on things like this, there's a few things that must be pointed out.
- SPDY runs over SSL. There isn't an unencrypted version -- note that SPDY was in fact faster than HTTPS.
- Many of the tricks used today to speed up page delivery, such as domain sharding, actually hurt SPDY's performance. SPDY's main benefit is that it opens up a single TCP connection and channelizes requests for assets inside that connection. Forcing the browser to establish a lot of TCP connections defeats this entirely, and the overhead of spinning up an SSL connection is very high. (And again, it should be noted that SPDY *WAS* faster, even if just a little bit, than standard HTTPS.)
There are other features in SPDY that today remain largely untapped, such as a server hinting to a client that it knows it'll need some content ahead of time -- giving the client something to do while it'd normally be idle waiting for the server to respond while it's generating the HTML it requested. (Large DB query, or whatever.)
Web engineers are clever and a smart bunch. While it looks like there's not a lot of gain to rethinking HTTP 1.1 today, given the years of organic growth we've had and time spent optimizing an older protocol, as new technology comes along that take advantage of the new foundation, things this will change. Give it time.
To the folks complaining that this guy doesn't know what he's doing, uh, he's a Chief Product Architect at Akamai. Yes he does. The folks at Akamai know more about web delivery than just about anyone.
- Bunny
What is the big deal with SPDY? (Score:2, Interesting)
From what I read about SPDY it doesn't sound like a big benefit justifying a change in protocols.
HTTP pipeline support has been around for over a decade now and I'm unaware of the extent of it's usage but it produced real benefits back when I was using it in Firefox and apache about a decade ago. SPDY does pipelines; well so did HTTP: OPTIONALLY.
I've read arguments about the benefits of pipelines, been there, done that - it is not new. When you have a scalable solution you CAN'T run everything from 1-2 pipelines on 1 big server, if not for CPU limits it is the bandwidth limitations.
HTTP Deflate encoding has been a little bit of a mess (thank you Microsoft) but I've found huge benefits to gzipping static content on the server. SPDY does gzip; well so did HTTP: OPTIONALLY. Are there benefits to gzipping all your bandwidth? NO! because most of it is JPEG and PNG images; HTTP is mixed mode, I admit it has additional overhead (but its not a huge deal in page loading speed.)
SPDY has too much unnecessary encryption which wastes power and CPU time.
The #1 problem I've seen is EXTERNAL resources, usually AD SERVERS, TRACKERS/social networks. DNS is a huge speed loss even today with my own DNS caching server that bypasses my ISP which has purposely slow DNS. I've also noticed plenty of LARGE image files, not optimized or even oversized for the page. My newer browsers wait for images of unknown sizes while previously the page would visibly reflow also CSS noticeably slowed page rendering. This likely will get worse as people start including larger images as soon as iOS browsers utilize them... since they separate logical resolution from actual resolution (like scalable fonts do.) CSS3 also gives us 150k+ fonts that must be downloaded before page rendering. "web 2.0 / ajax" sites could benefit from web sockets since that seems to be the only way we are going to do intelligent server interaction. I won't even get into all the massive javascript libraries bloating everything. SPDY is not going to help with that stuff.
I VOTE TO KEEP HTTP 1.1 and work on HTTP 2.0 based upon UDP or TCPv2 for the future. We could use something for open connections; web sockets is too much power (and risk) just to solve the stateless problem.