Slashdot Mirror

← Back to Stories (view on slashdot.org)

SPDY Not As Speedy As Hyped?

Posted by timothy on from the but-it-stays-late-on-weekends dept.

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."

80 of 135 comments (clear)

  1. Re:Different benchmarking environments? by dmacleod808 · · Score: 5, Funny

    I use Mycleanpc.bulshit for all my benchmarking needs!

    --
    There Can Be Only One...
  2. Not so fast...YET by jampola · · Score: 1, Insightful

    You're not going to see the potential of SPDY before we have environments (browsers, CPU and your internet speed) that can take full advantage of it. Only in the most recent version of Firefox did we see SPDY support.

    What's the moral of all this? It's early days yet. Let's talk in a few years when the rest of us catch up.

    1. Re:Not so fast...YET by bakuun · · Score: 5, Insightful

      You're not going to see the potential of SPDY before we have environments (browsers, CPU and your internet speed) that can take full advantage of it. Only in the most recent version of Firefox did we see SPDY support.

      SPDY does not depend at all on CPUs or your "internet speed". It does depend on the browser (with both Firefox and Chrome supprting SPDY now) and, critically, the server. That last is also why the article author did not see much of a speedup - most content providers don't support SPDY yet. Going to non-SPDY servers and believing that it will evaluate SPDY for you is absolutely ridiculous.

    2. Re:Not so fast...YET by Samantha+Wright · · Score: 1

      Personally I'm a little sceptical about the testing methodology:

      For a proxy, I used the Cotendo CDN (recently acquired by Akamai). Cotendo was one of the early adopters of SPDY, has production-grade SPDY support and high performance servers. Cotendo was used in three modes – HTTP, HTTPS and SPDY (meaning HTTPS+SPDY).

      Surely that means that the proxy would have to download at least some of the pages from non-SPDY servers on demand, rendering this entire thing suspect? He said that he ran 5 replicates, but no attempt is offered at explaining why SPDY should be slower than plain ol' HTTP, only why it might not be faster. I could be wrong, but it looks like the protocol is more concise on average even for a single-page request. Maybe Cotendo just has a bad implementation?

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    3. Re:Not so fast...YET by Anonymous Coward · · Score: 5, Informative

      I came here to say something like "read the article, the guy is from Akamai and would know to only use servers that serve SPDY - such as many of the Google properties". But then, I read the fine article (blog) and realized the guy doesn't know enough to do that and just used "the top 500 sites" - which means a very large chunk of them don't know what SPDY is and he only used it between himself and his proxy. Great test that was. So your point is well taken. Bogus test means bogus results.

    4. Re:Not so fast...YET by Anonymous Coward · · 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.

    5. Re:Not so fast...YET by Anonymous Coward · · Score: 1

      You are not a very good reader then. He put a proxy in front of the web sites that implements the protocol.

    6. Re:Not so fast...YET by dave420 · · Score: 5, Informative

      And unless that proxy used SPDY to talk to the servers, or had them entirely cached, that means nothing.

    7. Re:Not so fast...YET by Anonymous Coward · · Score: 2, Informative

      The reason SPDY doesn't help much is that your average web site now requires connections to a dozen other domains (each with only one or two requests), meaning that consolidating the requests to the main domain into a single connection just isn't that beneficial.

      dom

    8. Re:Not so fast...YET by Samantha+Wright · · Score: 1

      Yes, but that shouldn't slow things down beyond 100% of HTTP's speed... should it?

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    9. Re:Not so fast...YET by Wierdy1024 · · Score: 1

      It is approximately valid. He put a bandwidth simulator between him and his proxy.

      His comment about the average site requiring ~ 30 different SPDY connections seems excessive though. I suspect this is why he's seeing such bad results. Maybe he is assuming no benefit from the removal of domain sharding which providers would likely do if they rolled out SPDY.

    10. Re:Not so fast...YET by buddyglass · · Score: 1

      SPDY does not depend at all on CPUs or your "internet speed".

      CPU is mostly irrelevant, true, but the characteristics of one's network connection are likely very relevant to the sort of speedup one should expect to see from SPDY. My understanding is that the greater the latency between client and server the greater the benefit the client is likely to experience from using SPDY.

    11. Re:Not so fast...YET by butlerm · · Score: 2

      no attempt is offered at explaining why SPDY should be slower than plain ol' HTTP, only why it might not be faster

      The author was testing SPDY over TLS, which has a significant connection startup overhead. That probably explains all the performance degradation relative to regular HTTP.

      In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason. SPDY+TLS isn't likely to be used for that without _major_ standards modifications to allow third party content to be transparently proxied through first party sites cookies and all.

    12. Re:Not so fast...YET by Samantha+Wright · · Score: 1

      Ah, that explains it. In retrospect it seems rather silly to complain that an encrypted protocol is not more efficient than an unencrypted one.

      --
      Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    13. Re:Not so fast...YET by petermgreen · · Score: 1

      mmm, tfa doesn't make it clear whether the latency figures they are using are one-way latency or round trip time. Either way though 200ms is a pretty low value to use as the highest latency testcase. UK to australia is about 300ms round trip time datacenter to datacenter and a sattelite connection or crappy cellular connection can easily have over a second's latency.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    14. Re:Not so fast...YET by rekoil · · Score: 1

      In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason.

      Good news here: Google's DoubleClick and AdSense ads are served over SPDY today. In fact, I'm not aware of any Google properties that don't use SPDY, since they're all routed through the same GFE (Google FrontEnd) proxy farms.

  3. Single domain? by ThePhilips · · Score: 1

    SPDY optimizes on a per-domain basis. In an extreme case where every resource is hosted on a different domain, SPDY doesn’t help.

    So the whole CDN thing has to be redone for SPDY to deliver on the promises?

    --
    All hope abandon ye who enter here.
    1. Re:Single domain? by Skinkie · · Score: 1

      Like the CDN had to be redone for the opendns stuff (non-geographic queries). And the HTTPS stuff had to be redone because Google thought FalseStart was a great idea :)

      --
      Support Eachother, Copy Dutch Property!
    2. Re:Single domain? by Anonymous Coward · · Score: 2, Informative

      This is not at all true. There were numerous stories about how Google worked with CDNs to ensure compatibility with OpenDNS. Here's one example from last year:
      http://arstechnica.com/tech-policy/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup/

      As for SSL False Start, the problem was a handful of SSL terminators that violated the spec. Unfortunately, most of the manufacturers of those devices showed no interest in making a trivial fix to their implementations, and the few that did make the fix didn't bother to deploy it to existing customers. So, everyone had to suffer because 0.5% of SSL servers were broken:
      http://arstechnica.com/business/2012/04/google-abandons-noble-experiment-to-make-ssl-less-painful/

    3. Re:Single domain? by dmomo · · Score: 1

      Maybe that work could be given to browsers?

      If a page used these resources:

      http://static1.js.cdn.com/resource1.js
      http://static2.js.cdn.com/resource2.js
      http://static3.css.cdn.com/resource3.css

      perhaps the browser could automatically look for some file, the way it does with favicon:

      http://static1.js.cdn.com/spdy.txt

      That would pass back a file containing a spdy domain to use?
      spdy.cdn.com

      It would mean more requests on a single page load, I guess. But they could be cached.

    4. Re:Single domain? by rekoil · · Score: 1

      That only works if all of those hostnames resolve to the same IP addresses. The main optimization in SPDY is the elimination of the need to make multiple TCP connections simultaneously, but all of those resources must live on the same server. If the resources have different hostnames, you might be able to detect hostnames that point to the same IP and then interleave those, but I don't know if the current implementations do that yet.

      Most CDNs, however, return different IPs for nearly every query, and web developers use multiple hostnames pointing to the same resources to get non-SPDY multiplexing today. This sounds like an optimization that's easy to accomplish dynamically, though (if request is SPDY, don't spread the resources across different hostnames).

  4. Amazon Silk by yelvington · · Score: 4, 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.

  5. the problem with SPDY... by Anonymous Coward · · Score: 1, Insightful

    ...is the usual problem you have when a single self-centred company which believes itself to be awash with superstars tries to take over a standard protocol: some ideas seductive but much questionable.

    There are some good ideas in SPDY which have been proposed elsewhere and which could be introduced into the next version of HTTP: not repeating headers, header compression. There are some questionable ideas (consider cost and implementation complexity at both ends - some problems are illustrated by the rules re what can be multiplexed): multiplexing over a single connection, new security layer. There are some downright googlish ideas: pushing resources to the client which aren't requested.

    In short, no thanks, Google.

    1. Re:the problem with SPDY... by dave420 · · Score: 1

      And server hints only tell the client what it might need, and it's up to the client to accept it.

  6. The average is meaningless by MobyDisk · · Score: 2

    The average is meaningless without the raw data. Suppose it averaged 5%: is that because all sites were 5% faster, or because one site was 500% faster and the others were 2% faster? The former would mean that SPDY is mostly useless. The latter would mean that SPDY is immensely useful, but just not in all cases.

  7. It's the advertising out of control by Skapare · · Score: 5, Insightful

    Web browsing experiences are slowing down from advertising. But it's not an issue around the images that advertising loads. Instead, it is a combination of the extra time needed to load Javascript from advertisers (whether it is to spy on you or just to rotate ads around), and programming defects in that Javascript (doesn't play well with others). Browsers have to stop and wait for scripts to finish loading before allowing everything to run or even be rendered. You can have a page freeze in a blank state when some advertiser's Javascript request isn't connecting or loading.

    The solution SHOULD be that browsers DISALLOW loading Javascript (or any script as the case may be) from more than one different hostname per page (e.g. the page's own hostname not being counted against the limit of one). This would remain flexible enough to reference scripts from a different server, or even an advertising provider, without allowing it to get excessive. Browsers should also limit the time needed to load other scripts, though this may be complicated for scripts calling functions in other scripts. Perhaps the rule should be that even within a page, scripts are not allowed to call scripts loaded from a different hostname, except the scripts from the page's hostname itself can call scripts in one.

    I've also noted quite many web sites that just get totally stuck and refuse to even render anything at all when they can't finish a connection for some script URL. Site scripting programmers need to get a better handle on error conditions. The advertising companies seem to be using too many unqualified programmers.

    --
    now we need to go OSS in diesel cars
    1. Re:It's the advertising out of control by Anonymous Coward · · Score: 1

      If you have a better suggestion on how to finance all the free content out there, I'd like to hear it.

      The current "everything is free" model on the web is only possible because of that advertising.

    2. Re:It's the advertising out of control by Anonymous Coward · · Score: 1

      If you had actually read the post you'd have seen that he considers advertising acceptable in itself.

    3. Re:It's the advertising out of control by swillden · · Score: 2

      The solution SHOULD be that browsers DISALLOW loading Javascript (or any script as the case may be) from more than one different hostname per page (e.g. the page's own hostname not being counted against the limit of one). This would remain flexible enough to reference scripts from a different server, or even an advertising provider, without allowing it to get excessive.

      This would cause problems for lots of sites that use javascript libraries, like jQuery et al, and load them from the canonical library sources. Of course, sites could host their libraries themselves, but that would require them to keep them up to date, and it would keep them from being cached and reused across different sites.

      Plus, your suggestion basically boils down to "let's break sites of clueless web developers so they'll get a clue". I don't object to that on principle, but it's not practical. What happens when a browser implements your ideas? Lots of crappy web sites don't work any more for users of that browser. What you want is the developers to fix their site. What will happen is that users will switch to a browser that works.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:It's the advertising out of control by PIBM · · Score: 2

      Actually, a lot of sites refuses to load the content if the advertisement is not yet displayed to prevent showing the content for free; they prefer you to reload the page and obtain that advertisement rather than risk losing that display.

    5. Re:It's the advertising out of control by Anonymous Coward · · Score: 1

      Life was fine before advertising blew up on the web, more of the content was generated by people than content farms and shills so the signal-to-noise was much better

    6. Re:It's the advertising out of control by Johann+Lau · · Score: 2

      The current "everything is free" model on the web is only possible because of that advertising.

      It's not free, it's paid for by advertising. Hidden costs don't mean "no costs". Here's an idea: I pay my ISP for the downstream bandwidth. What if some of that money went to the owners of the servers I peruse, automically, AKA built-in micropayment? Dunno about you, but if that would double the price of my interwebs, it would still be fucking cheap interwebs. It wouldn't be a way to earn money with traffic either, just a way to not LOOSE money from it. Sure, it's sketchy and it involves no actual calculations (I wouldn't know where to start with those), who knows if it would work. But fuck it, I would be up for trying that.

      Consider how public transportation is also partly paid for by ads. You pay for the ticket, yet you still get ads. However, I don't even want to know how much worse it would be if tickets costed no money at all. Just like I'd be interested if we can't make the internet an interesting place again, by putting advertisement, the mental product of those who HAVE no mental products, back in its place: last place. Which is still generous and you know it.

      But more importantly, saying advertising shouldn't really on horrible clusterfucks of javascript, isn't even arguing against advertising. Even arguing that ads shouldn't spy, not even count views, and simply pay for click-throughs (then they're your customers, agreeing to your privacy policy, and you can do whatever the fuck you want), wouldn't be arguing against advertisement as a whole. I bit anyway, because this topic does interest me.

      By the way, if anyone here is in advertising or marketing, kill yourself.

      Just a little thought. I'm just trying to plant seeds. Maybe one day, they'll take root. I don't know. You try. You do what you can. Kill yourself.

      Seriously, though. If you are, do. No, really. There's no rationalisation for what you do, and you are Satan's little helpers, okay? Kill yourself. Seriously. You are the ruiner of all things good, seriously. No, this is not a joke, if you're going: "There's going to be a joke coming." There's no fucking joke coming. You are Satan's spawn, filling the world with bile and garbage. You are fucked, and you are fucking us. Kill yourself, it's the only way to save your fucking soul. Kill yourself. Planting seeds.

      I know all the marketing people are going: "He's doing a joke." There's no joke here whatsoever. Suck a tail-pipe, fucking hang yourself, borrow a gun from a Yank friend - I don't care how you do it. Rid the world of your evil fucking machinations.

      I know what all the marketing people are thinking right now, too. "Oh, you know what Bill's doing? He's going for that anti-marketing dollar. That's a good market, he's very smart." Oh man. I am not doing that, you fucking evil scumbags! "Oh, you know what Bill's doing now? He's going for the righteous indignation dollar. That's a big dollar. Lot of people are feeling that indignation, we've done research. Huge market. He's doing a good thing." God damn it, I'm not doing that, you scumbags. Quit putting a goddamn dollar sign on every fucking thing on this planet! "Oh, the anger dollar. Huge. Huge in times of recession. Giant market, Bill's very bright to do that." God, I'm just caught in a fucking web. "Oh, the trapped dollar. Big dollar, huge dollar. Good market, look at our research. We see that many people feel trapped. If we play to that and then separate them into the trapped dollar ..."

      How do you live like that? And I bet you sleep like fucking babies at night, don't you? "What did you do today, honey?" "Oh, we made arsenic childhood food. Now, good night. Yeah, we just said, you know, is your baby really too loud? You know ... yeah, the mums will love it, yeah." Sleep like fucking children, don't you? This is your world, isn't it?

      Bill Hicks (I'll never tire of posting this, until and even for a while after it came to pass)

    7. Re:It's the advertising out of control by DavidTC · · Score: 1

      I don't know about your solution, but you're dead right about the problem.

      I work as a fairly-technically-inclined web developer, and I can't count how many times I've seen other developers say 'I can't figure out how to make my Joomla or Wordpress or whatever give out pages faster, perhaps I need some sort of caching or something'. I check, and it's a ten second load time.

      And then I look at it in Firebug and point out their HTML arrives in half a second, and their images arrive in three seconds and are cached on all but the first page, and they were smart enough to include image dimensions to allow the page to render without them. The actual slowness is because they're loading loading a javascript from another server that is not cached, and that script has to get downloaded, and run, and then, at that point it goes and gets an actual ad...at which point the damn page finally renders. So there's nothing anyone can do about the speed.

      Can we please figure out something besides this paradigm? I have no problem with ads, but this is insane. Could Google not set it up where you make the ads like <img id='google_ad1' src='/transparent.gif' height... />, and then asynchronously load some javascript after page load that swaps that with an ad?

      All this Javascript is bad enough, but ads are specifically three times as bad simply because of the entire process of 'Connect to another server, download ad Javascript code, run that, it connects back to that server and downloads actual ads, and when it gets the actual ads the page can _finally_ render'.

      --
      If corporations are people, aren't stockholders guilty of slavery?
    8. Re:It's the advertising out of control by fa2k · · Score: 1

      It has gotten a bit better for me over the last 6 months. I used to see "Waiting for google-analytics.com" for 1-2 seconds all the time, but it doesn't happen as much now. It could be because I moved to a different country and Google has more servers there.

    9. Re:It's the advertising out of control by icebraining · · Score: 2

      Loading from a canonical source means the client is much more likely to have it in cache and skip the whole download. How the fuck is that retarded?

      --
      Dilbert RSS feed
    10. Re:It's the advertising out of control by KingMotley · · Score: 1

      There is nothing stopping you from doing that david. We do that and it works quite well for the off-site content.

    11. Re:It's the advertising out of control by tepples · · Score: 1

      Then why can't they include the advertisement as text in the page, rather than as a script that inserts an Adobe Flash Player object into the page?

    12. Re:It's the advertising out of control by Lazy+Jones · · Score: 1

      Instead, it is a combination of the extra time needed to load Javascript from advertisers (whether it is to spy on you or just to rotate ads around), and programming defects in that Javascript (doesn't play well with others). Browsers have to stop and wait for scripts to finish loading before allowing everything to run or even be rendered. You can have a page freeze in a blank state when some advertiser's Javascript request isn't connecting or loading.

      It is also a result of plain stupidity of some (major) ad server operating companies - here in Austria, we've heard things like "we try to disable caching for served media [images, swf etc.]" and we've actually seen images, animations, 200KB+ flash being loaded at every request because of this. Needless to say, the slow document.write() method of displaying ads is also still the norm ... If the W3C had any sense, it would have come up with an <AD> tag that worked like a restricted IFRAME (with mandatory caching) but could be turned on and off by the users (browsers). But like so many committees, the W3C is not interested in good technical solutions, but rather in the commercial interests of particular contributing corporations.

      --
      "I love my job, but I hate talking to people like you" (Freddie Mercury)
    13. Re:It's the advertising out of control by jonbryce · · Score: 1

      Serve all the scripts from your own website rather than from loads of different third party websites? The actual bandwidth requirements of a script file are not that great, most of the time is spent trying to contact all the different websites.

    14. Re:It's the advertising out of control by PIBM · · Score: 1

      Sometimes you have multiple providers of ads and you must rotate them yourself in (which is nice as you know from whom you will request the ad), and sometimes even those providers fill in blanks for specific regions/ips or too many request for a user by using subproviders, so the final 'page in a page in a page' can be pretty long and ugly, and totally impossible to predict at the first server level.

    15. Re:It's the advertising out of control by BronsCon · · Score: 1

      Another solution that could (should?) be implemented is: Use a locally-hosted script to load any externally-hosted scripts. Your page will load and render faster because everything required to render the page is loading from your own server, and you still get the 3rd-party-hosted shit^H^H^H^Hscripts on the page, just *after* it has rendered, so your users can, you know, actually start using the damned site.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
    16. Re:It's the advertising out of control by Anonymous Coward · · Score: 1

      Web was around before it became the polluted cesspit it is today. We don't need a billion images per page, of which 1 is related to the page you're looking at. We don't need instantly playing media divs for TV adverts as soon as you land on a page. We don't need a billion wanker bloggers and old media portals trying to be l337 and bring in ad dollars. If they all disappeared right now, nothing of value would be lost.

    17. Re:It's the advertising out of control by buddyglass · · Score: 1

      I just encountered this today, in fact. A blog I read uses Disqus to manage its comments. For some reason, on this particular blog, the comments wouldn't display until I selectively turned off blocking certain items on the page that part of the default list in Adblock Plus. Even then I could see the comments but not add my own. Had to create exceptions for a few additional items before the Disqus section would actually let me post.

    18. Re:It's the advertising out of control by jfengel · · Score: 1

      Of course, sites could host their libraries themselves, but that would require them to keep them up to date, and it would keep them from being cached and reused across different sites.

      I haven't done much work with jQuery, but in my experience library updates nearly always require somebody to at least examine the code. Something nearly always breaks.

      It seems to me that maintaining jQuery must be an extraordinary responsibility. Any change to its semantics risk breaking thousands or millions of sites. And the point seems to be to be able to make it unannounced, without any assistance from those who rely on it.

    19. Re:It's the advertising out of control by guardian-ct · · Score: 1

      It's probably because Disqus is using web-tracking-like technology (third-party cross-site scripts?) to do the comment display, and some of the adblock plus filter subscriptions block those things whenever possible. I had to set ghostery to have an exception for disqus if I wanted to read the comments on any page with Disqus commenting system on it.

    20. Re:It's the advertising out of control by buddyglass · · Score: 1

      It must be something added in a newer version of Disqus, then, because other blogs that use it seem to work fine w/ no exceptions. It's only this particular one that's jacked up. volokh.com, btw, is the blog.

  8. Or maybe the proxy was the limit by gstrickler · · Score: 2

    I used a Chrome browser as a client, and proxied the sites through Cotendo to control whether SPDY is used. Note that all the tests – whether HTTP, HTTPS or SPDY – were proxied through Cotendo, to ensure we’re comparing apples to apples.

    Since they all ran through the same proxy, it might be the limiting factor. We would need to see tests the bypass the proxy to determine if his results have any meaning beyond that specific proxy.

    Likewise, you have to ask the question, do all of the 500 sites he tested support SPDY?

    --
    make imaginary.friends COUNT=100 VISIBLE=false
  9. Why not BEEP? by Anonymous Coward · · Score: 1

    For the umpteenth time, if the main advantage of SPDY is multiplexing multiple streams over a single socket, why not use BEEP http://en.wikipedia.org/wiki/BEEP?

    1. Re:Why not BEEP? by rekoil · · Score: 1

      Because no one's bothered to ship a BEEP implementation in a major browser release?

  10. Err, no by gaspyy · · Score: 1

    If you take the time to analyse a modern page, you'll see that the ads usually represent a relatively small chunk.

    What really slows the pages down is over reliance on javascript frameworks. Pages that use both jquery and another framework such as scriptaculous are not uncommon. What's worse is that the developers often use these libraries for trivial effects, stuff that can easily done directly in javascript. Then most pages have scripts for at least 3-4 social media sites (Facebook Like box, Twitter counter, G+ counter, etc.), live tweet box, 5-8 different css files...

    And then they spend a fortune on bandwidth, CDN services and faster servers, when by optimizing content they'd get more performance.

    1. Re:Err, no by KingMotley · · Score: 1

      For the sites that I've worked on, it's mostly the social media plugin crap that slows then down, with facebook being one of the worst offenders. As such, I take great pains to load the social media stuff only after the entire page has been rendered, which helps responsiveness greatly. Multiple css files = negligible. Multiple javascript frameworks = negligible.

  11. Too many connections by chriswaco · · Score: 1

    SPDY solves *a* problem, but not *the* problem. The root of the problem today is that loading a simple web page requires 20 or more separate connections: images, ad networks, tracking systems, social network links, 3rd party comment systems, javascript libraries, css, etc. Somehow all of that content needs to be coalesced into fewer connections.

    1. Re:Too many connections by Lazy+Jones · · Score: 1

      Somehow all of that content needs to be coalesced into fewer connections.

      We did use fewer connections before CDNs, CDN-hosted JS libraries and cookie-less content domains became the norm and before web developers were advised by PageSpeed and other "authorities" to put content on multiple hosts to facilitate parallel access by browsers. Yes, it was a stupid idea to fix a minor implementation problem of browsers on the web server side.
      Also, what contributes most to web page slowdown is ads and tracking code, both areas dominated by Google - who pretends to be somehow interested in speeding up the web (haha!).

      --
      "I love my job, but I hate talking to people like you" (Freddie Mercury)
    2. Re:Too many connections by rekoil · · Score: 1

      The good news there is that connections to Google's ad networks DO run over SPDY now, assuming a compatible browser.

    3. Re:Too many connections by ls671 · · Score: 1

      SPDY solves *a* problem, but not *the* problem. The root of the problem today is that loading a simple web page requires 20 or more separate connections: images, ad networks, tracking systems, social network links, 3rd party comment systems, javascript libraries, css, etc. Somehow all of that content needs to be coalesced into fewer connections.

      You are wrong use netstat and a modern browser to test it out. With servers configured to do HTTP request keepalives, most browser open a maximum of 2 connections to one server and keep them up and everything is sent through those persistent connections.

      The browser also needs to open at least one connection to any third party server without regards for the protocol used.

      I see an average of 5 to 20 seconds timeout on most sites. The the server waits for other requests on the SAME connection. Use telnet and watch for the "close connection" delay after entering the query:

      telnet www.yahoo.com 80
      Trying 98.139.183.24...
      Connected to www.yahoo.com.
      Escape character is '^]'.
      HEAD / HTTP/1.1
      host: yahoo.com

      HTTP/1.1 301 Moved Permanently
      Date: Sun, 17 Jun 2012 18:49:19 GMT
      Location: http://www.yahoo.com/
      Vary: Accept-Encoding
      Content-Type: text/html; charset=utf-8
      Cache-Control: private
      Age: 0
      Connection: keep-alive
      Server: YTS/1.20.10

      Connection closed by foreign host.

      Yahoo's server took about fifteen seconds to close the connection.

      http://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout

      --
      Everything I write is lies, read between the lines.
    4. Re:Too many connections by ls671 · · Score: 1

      The SPDY whitepaper suggest an keep alive timeout of 500ms while most sites do 5 to 20 seconds ?

      No wonder why they think they are going to be so fast ;-)

      Seriously although, I still see the point of this protocol but it might have been over-hyped a bit. Established things are hard to change without revolutionary gains to be expected.

      http://www.chromium.org/spdy/spdy-whitepaper

      Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.

      --
      Everything I write is lies, read between the lines.
  12. The problem with the test ... by sharepass11 · · Score: 3, Informative

    IMHO, there is a huge issue with this test. On one hand its author claims : "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." But on the other hand at bottom lines it states : "This means SPDY doesn’t make a material difference for page load times, and more specifically does not offset the price of switching to SSL." SSL ? Wait a minute doc ... there is something wrong with the flux capacitor ! In fact to "SPDY"-fy the sites, the guy clarifies the technique he used : "For a proxy, I used the Cotendo CDN (recently acquired by Akamai). Cotendo was one of the early adopters of SPDY, has production-grade SPDY support and high performance servers. Cotendo was used in three modes – HTTP, HTTPS and SPDY (meaning HTTPS+SPDY)." You get it ? No, not the advertisement for cotendo ... ... He did not tested SPDY at all but tested TLS+SPDY !!! WTF ?!? Either the guy should upgrade all his article replacing SPDY with TLS+SPDY or he should trash it and make another one only with SPDY. Then we will start to discuss about some of his strange benchmark decision... Sad that such a odd article get so much press here :(

    1. Re:The problem with the test ... by Anonymous Coward · · Score: 1

      SPDY mandates TLS. Go read the spec.

    2. Re:The problem with the test ... by rekoil · · Score: 5, Informative

      SPDY as implemented requires SSL, since the protocol capability is negotiated by a TLS extension on port 443. There's no spec for negotiating SPDY on a standard HTTP port - it would only work if the capability was assumed on both sides before the connection (for example, URLs that start with spdy:// instead of http:/// which connects to a different TCP port on the server).

  13. Fixing the problem on the wrong layer by Lisandro · · Score: 3

    Shouldn't we be working on adopting SCTP instead?

    1. Re:Fixing the problem on the wrong layer by kangsterizer · · Score: 1

      it's more effort, thats why people use SPDY.
      Changing all the gear to support SCTP is hard. Specially those pesky hp/cisco/juniper/you-name-it proprietary network hardware

      That's also why Google is sometimes pushing for open source software on top of network hardware IMO.

    2. Re:Fixing the problem on the wrong layer by rb12345 · · Score: 1

      While that's true, a standard (and popular library) for SCTP-over-UDP could be created. At most, you'd need a single well-known UDP port for inbound SCTP-over-UDP (9989 is suggested by the Internet draft for this). SCTP ports would be used to distinguish between separate SCTP-using services on the server. I'm sure that the existing Linux and BSD SCTP stacks could support this with little effort. Firewalls that only permit HTTP/HTTPS would block this variant, but it would work well enough through NATs, especially if the multiple-endpoint parts of standard SCTP were left out.

    3. Re:Fixing the problem on the wrong layer by complete+loony · · Score: 1

      SCTP's a neat protocol. But by itself, it won't help to accelerate HTTP. SDPY is designed to quickly load all of the different resources you'll need to render a web page with a much lower latency. Standard HTTP over SCTP wouldn't have as much of an impact on latency.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  14. Testing in multiple versions of IE by tepples · · Score: 1

    What's worse is that the developers often use these libraries for trivial effects, stuff that can easily done directly in javascript.

    Doing it directly in JavaScript would take valuable programmer time to code and test for proper HTML5 browsers and for each of the past few versions of IE.

    Then most pages have scripts for at least 3-4 social media sites (Facebook Like box, Twitter counter, G+ counter, etc.), live tweet box

    How would you recommend accomplishing the visibility that sharing of pages by users of social media sites gives without incurring the delay of loading those scripts?

    5-8 different css files

    One approach is to have one huge CSS file that covers all browsers and all parts of the site, forcing users to download a lot of data that does not pertain to a particular page. Another is to have one main CSS file for the site, one for the section, and one "fixes" file for each particular flavor of user agent. Assuming each is cached to expire a week in the future, which is better and why?

    1. Re:Testing in multiple versions of IE by Anonymous Coward · · Score: 1

      How would you recommend accomplishing the visibility that sharing of pages by users of social media sites gives without incurring the delay of loading those scripts?

      Right, because users can't possibly make posts on their favourite faggot site by themselves without the help of some ridiculous time-wasting script.

  15. SPDYs main issue: it's not needed by Lazy+Jones · · Score: 1

    HTTP and HTTPS are fast enough, it's the web servers / content generation (and ads) that limit the user experience and make web pages load slowly, followed by low bandwidth in some areas. If you really want to fix old protocols that actually need fixing, go look at SMTP first.

    --
    "I love my job, but I hate talking to people like you" (Freddie Mercury)
  16. Current HTTP Speedup Tricks Hurt SPDY by _Bunny · · 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

  17. What is the big deal with SPDY? by bussdriver · · Score: 1, 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.

    --
    Democracy Now! - uncensored, anti-establishment news
    1. Re:What is the big deal with SPDY? by rekoil · · Score: 5, Informative

      1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.

      2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.

      3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.

      4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.

      5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).

      But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.

      The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).

    2. Re:What is the big deal with SPDY? by Bengie · · Score: 2

      HTTP 1.1 pipelining does not allow more than one command to be outstanding. HTTP allows you to re-use the connection for your next command, but does not allow multiple commands at the same time.

      HTTP1.1 is actually quite horrible for modern networks/computers. Choosing between HTTP1.1 and 1.0 is choosing between a giant douche and a turd sandwich. UDP won't happen because of the lack of congestion avoidance, which should be left up to the OS, not the app.

      The biggest issue with HTTP is it does not allow multiplexing communication without opening up more connection, which is hard on servers, firewalls, and messes with TCP congestion detection.

    3. Re:What is the big deal with SPDY? by petermgreen · · Score: 1

      The parent is semi-correct, HTTP pipelining allows the client to send multiple requests sent at a time but the responses to those requests have to be sent sequentially and in the same order that the requests were sent.

      This means that if one request is slow then all requests behind it in the queue are also held up.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    4. Re:What is the big deal with SPDY? by jaymemaurice · · Score: 1

      Except even with piplining, your browser usually opens more then one connection to each server - it then round robins the requests through the sockets which are ready for a request. The requests do not need to be in any particular order - just the responses obviously come in the same socket as the request, and after the request.

      --
      120 characters ought to be enough for anyone
    5. Re:What is the big deal with SPDY? by BZ · · Score: 1

      That's the theory. The practice is that the web is full of transparent proxies that fall down when you try to pipeline through them (e.g. returning responses partially on the on the wrong socket in the setup you describe above, the last time I dealt with debugging a bug that was only reproducible with pipelining enabled in the browser).

      Which is why pipelining remains off in Chrome and Firefox today: turning it on breaks too many sites for too many users....

    6. Re:What is the big deal with SPDY? by jaymemaurice · · Score: 1

      It's enabled by default in IE... and if such transparent proxies are the issue the appropriate response isn't to cover up the problem. There should be no way a transparent proxy could/should screw it up as a transparent proxy should simply only forward the request to the server or serve from the cache. The fact they do not open another TCP connection should be irrelevant and if it was relevant that means such transparent proxies would also serve invalid responses without pipelining - the same flow information is available to a transparent proxy as a regular proxy or web server. Pipelining does not give the proxy a magical ability to send incorrect responses on another tcp socket.

      --
      120 characters ought to be enough for anyone
    7. Re:What is the big deal with SPDY? by dave420 · · Score: 1

      Server hints work with caching. They simply tell the client about other assets before everything's sent, which the browser can then check against their own cache before downloading.

    8. Re:What is the big deal with SPDY? by BZ · · Score: 2

      > It's enabled by default in IE.

      Citation please? It wasn't last I checked, precisely because of issues like the ones I describe.

      > if such transparent proxies are the issue the
      > appropriate response isn't to cover up the
      > problem.

      What is the appropriate response? To ship software that doesn't actually work right when the user tries to use it?

      > as a transparent proxy should simply only forward
      > the request to the server or serve from the cache.

      That's the theory. In practice, many such proxies are buggy. The rest if your comment is all about how a proxy is supposed to work. I know all that. My point was that many do NOT work like that. They do all sorts of internal request coalescing and reordering logic that works OK when the client is not using pipelining but makes the proxy behave in totally bogus ways when pipelining is present.

      Here's a simple example: some proxies use a threadpool and every time they get a request they hand it off to some thread to service; that thread does a request on to the destination server and when the response comes back hands the data back down the socket the original request came in on.

      With no pipelining, this setup is fine. With pipelining, the proxy gets a bunch of requests in a row on a single socket, and hands them out to different threads. These threads then run in parallel and start handing back data in parallel, all on the same socket. It's not what a proxy is _supposed_ to do with a pipelined connection, but it's what some proxies _do_. Theory and reality just don't always agree...

    9. Re:What is the big deal with SPDY? by bussdriver · · Score: 1

      1. Buggy proxies should not get so much power that we can't progress HTTP

      2. OPTIONAL compressed headers would be nice. One reason HTTP and HTML got big is they are simple and easy to use-- obviously we could replace them with binary formats for huge technical gains as competing technologies did. I do not know SPDY but I would oppose whole protocol compression if that is what they are doing, most traffic is already compressed images or video. I don't want the extra work of having to encode headers into gzip just to do something simple.

      3. Smart proxies and other interesting ideas using HTTP are impossible with an SSL wrapped protocol. It also uses extra CPU power. If SPDY is going to be used it should be part of HTTP v2.0 and go down an open standards route instead of 1 company's idea of an enhancement.

      4. My point exactly, web developers should continue to easily scale up with multiple servers without being penalized / limited by the protocol. We are seeing MORE divergence on websites with time, not less. Distributed solutions and cross site integration.

      5. Server push would be nice. HTTP could have this added; it had a form of server push (with issues) already. There is no reason a webserver using HTTP couldn't include unofficial headers now for giving the browser prefetch hints to use in it's typical 2nd or 3rd parallel connections. Multiple commands per connection would require big changes; in which case, I'd be for something that helps AJAX type uses without being as powerful as web sockets.

      If we are going to go all binary anyhow and kill HTTP for some totally different thing why not multiplex our data too? (I do realize the network stack does this already but that adds more overhead than us multiplexing within fewer data streams - sure we lose the hardware serial multiplexing support and doing it manually uses more CPU but it saves us bandwidth and CPUs just get better... we are already compressing and encrypting everything so we obviously don't care. )

      --
      Democracy Now! - uncensored, anti-establishment news
  18. Re:Tor switched TBB FF to 10.0.5 ESR! by allo · · Score: 1

    yeah. SPDY is on SSL, which cannot be filtered by privoxy (between firefox and tor)

  19. It has to be one-click easy by tepples · · Score: 1

    Right, because users can't possibly make posts on their favourite faggot site by themselves without the help of some ridiculous time-wasting script.

    This is correct, as I understand it. Unless users can "make posts on their favourite faggot site" with one click, users won't feel inclined to "make posts on their favourite faggot site" at all, and your web site will not reap the benefit from exposure in "posts on their favourite faggot site".

  20. Why can't the server fetch the ads? by tepples · · Score: 1

    The script must run to retrieve the ad contents from the ad server

    I understand that the script must run, but I disagree that it must run as a JavaScript script on the viewer's computer. The server could run it, make the call to the ad server, and send the advertisement to the end user.

    whether the contents is flash, image, or text.

    Why do web sites have image ads when the article is not an image, or Flash ads when the article is not Flash?