Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web

Posted by timothy on from the sufficient-disclosure dept.

grmoc writes "As part of the 'Let's make the web faster' initiative, we (a few engineers — including me! — at Google, and hopefully people all across the community soon!) are experimenting with alternative protocols to help reduce the latency of Web pages. One of these experiments is SPDY (pronounced 'SPeeDY'), an application-layer protocol (essentially a shim between HTTP and the bits on the wire) for transporting content over the web, designed specifically for minimal latency. In addition to a rough specification for the protocol, we have hacked SPDY into the Google Chrome browser (because it's what we're familiar with) and a simple server testbed. Using these hacked up bits, we compared the performance of many of the top 25 and top 300 websites over both HTTP and SPDY, and have observed those pages load, on average, about twice as fast using SPDY. Thats not bad! We hope to engage the open source community to contribute ideas, feedback, code (we've open sourced the protocol, etc!), and test results."

7 of 406 comments (clear)

  1. and faster still.. by Anonymous Coward · · Score: 4, Insightful

    remove flash, java applets ad's
    20X faster!

    1. Re:and faster still.. by commodore64_love · · Score: 4, Insightful

      Ye are joking, but ye are correct. Take this slashdot page. I used to be able to participate in discussion forum with nothing more than a 1200 baud (1kbit/s) modem. If I tried that today, even with all images turned off, it would take 45 minutes to load this page, mainly due to the enormous CSS files

      It would be nice if websites made at least *some* attempt to make their files smaller, and therefore load faster.

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
  2. How about telling Analytics to take a hike? by rho · · Score: 5, Insightful

    And all other "add this piece of Javascript to your Web page and make it more awesomer!"

    Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".

    Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?

    I want my old Internet back. And a pony.

    --
    Potato chips are a by-yourself food.
  3. Re:Solving the wrong problem by HBI · · Score: 4, Insightful

    IAWTP. With NoScript on and off, the web is a totally different place.

    --
    HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
  4. Cool.... but it's not http by Colin+Smith · · Score: 4, Insightful

    So which ports are you planning to use for it?

     

    --
    Deleted
  5. Re:Slashdot could use the help by Anonymous Coward · · Score: 4, Insightful

    They need start with practicing what they preach...

    http://code.google.com/speed/articles/caching.html
    http://code.google.com/speed/articles/prefetching.html
    http://code.google.com/speed/articles/optimizing-html.html

    They turn on caching for everything but then spit out junk like

    http://v9.lscache4.c.youtube.com/generate_204?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor&fexp=903900%2C903206&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1258081200&key=yt1&signature=8214C5787766320D138B1764BF009CF62A596FF9.D86886CFF40DB7F847246D653E9D3AA5B1D18610&factor=1.25&id=ccbfe79256f2b5b6

    Most cache programs just straight up ignore this. Because of the '?' in there. It ends up being a query to static data.

    Then never mind the load balancing bits they put in there with 'v9.lscache4.c.'. So even IF you get your cache to keep the data you may end up with a totally different server and the same piece of data just served from another server. There have been a few hacks to 'rewrite' the headers and the names to make it stick. But those are just hacks and while they work they seem fragile.

    The real issue is at the HTTP layer and how servers are pointed at from inside the 'code'. So instead of some sort of indirection that would make it simple for the client to say 'these 20 servers have the same bit of data' they must assume that the data is different from every server.

    Compression and javascript speedups are all well and good but there is a different more fundamental problem of extra reload of data that has already been retrieved. As local network usage is almost always faster than going back out to the internet. In a single user environment this is not too big of a deal. But in a 10+ user environment it is a MUCH bigger deal.

    Even the page that talks about optimization has issues
    http://code.google.com/speed/articles/
    12 cr/lf right at the top of the page that are not rendered anywhere. They should look at themselves first.

  6. Re:Oh that's wonderful by D'Sphitz · · Score: 5, Insightful

    People take their slashdot comments way too seriously. Mod me whatever, it means nothing and I'll move on.