4 ms·

HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web

17 points by spahl 17y ago

jacquesm 17y ago
The quickest way for a 'dramatic' speedup of the web is to install an ad blocker. Also, 'dramatic' speedups will only lead to pages that get loaded up with more junk. If that had not happened we'd already have an extremely fast browsing experience. It's like memory and disk space, if the budget increases then there will be some way to spend that budget. If web pages load in under one second they'll be 'improved' until they load in 3 to 4 seconds again. spdy:// ? I don't think so. Let's drop some of that flash and turn on gzip compression (if you haven't done that already) and make sure your cache headers are set properly. That alone will probably give you a 50% boost.
- dazzawazza 17y ago
  While your points are valid in order for webapps to continue their march in to desktop app territory they need to decrease latency. I think this is what spdy is there for. I'm sure a lot of fat will be added to apps but if my AJAX requests are snappier I am more then happy to support this.
  - jacquesm 17y ago
    from: http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepa... "To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below)." The bigger chunk of which seems to come from header compression. SPDY is targeted to be placed between HTTP and TCP. It 'only' requires changes to the client and the webservers. That makes me a little skeptical about the value of their tests, I can't imagine they got the top 500 websites to change their server architecture to allow this test to take place. They are very much focused on the latency issues but the only references they give are for things related to page load time, which are affected peripherally by latency, but latency is much more of an effect on single connections. And the only gain from that would be to compress the headers. If header compression is that much of a deal then I would suggest to add optional header compression to the http standard, not to place layers in between http and tcp. And that layer would have to add 0 overhead all by itself on single connections or the results would be negative instead of positive. You can't really support this unless the client supports it as well, think of it as a specialized gateway function inside the browser that knows how to tunnel HTTP over SPDY to hosts that support it, the key factor is interleaving frames of content from different sources. Essentially a packet multiplexer/demultiplexer if I read it all right, that will pack all the requests on the sending side and unpack them at the receiving end to go to their respective handlers. By the way, the 'server pushes resources before the client has asked for it' is what has been making my webcam software functional for the last 15 years or so. I clued in to that in '95 or so using the server-push technology and figured out that since I already knew that the next request would be for another frame of the same cam why not send it right now instead of waiting for the browser to ask for it...
- confuzatron 17y ago
  Good parody of the internet curmudgeon, there.
  - jacquesm 17y ago
    Have a look at how the large majority of the top 500 web servers are set up and see if you disagree. A large portion of them could be sped up by simply configuring them properly, using nothing but the facilities that are available today. I'm not sure if this link will 'live' for other others, but it is an analysis of cnn.com, it shows the homepage clocks in at a whopping 1.1M! http://www.webpagetest.org/result/091113_2YFS/ http://www.webpagetest.org/result/091113_2YFS/ And has tons of caching and compression issues. Feel free to try out any other 'large' website and you'll find that only very few of them actually come in green across the board.
    - neilc 17y ago
      A large portion of them could be sped up by simply configuring them properly, using nothing but the facilities that are available today. Probably true, but not relevant to SPDY: you can't assume that every website in the world is going to be configured "properly." SPDY's improvements are orthogonal to other improvements that might be made to site configurations.
- RyanMcGreal 17y ago
  > Also, 'dramatic' speedups will only lead to pages that get loaded up with more junk. Jevon's paradox in action?
- bumblebird 17y ago
  >> "The quickest way for a 'dramatic' speedup of the web is to install an ad blocker." Because most websites would go out of business and there wouldn't be much left to browse?
  - jacquesm 17y ago
    Possibly. But then again, I don't see any ads on HN, and I do remember a version of the web that did not have advertising on it. It also had a significantly better signal to noise ration than the current one does.
    - dkarl 17y ago
      That web still exists, if you can keep your eyes off the flashy pretty stuff.
    - tptacek 17y ago
      I had dialin access in '93, and my first browser was Mosaic on Win3.1 under Trumpet Winsock, and I ran the tech side of an ISP from 95-97, and under no circumstances would I ever trade the web of '97 for the one I have today, where I can watch TV, browse Cooks Illustrated, learn Calculus, and read entire books. I wouldn't even trade Hacker News for Usenet. The signal to noise ratio in '97 was high because there was very little signal, and not as many people cared.
      - jacquesm 17y ago
        > The signal to noise ratio in '97 was high because there was very little signal I don't agree with that at all, there was plenty of signal, it just wasn't in 'rich media' format. Pages were static and simple instead of having a multi-media circus to put across a simple point. RiderOfGiraffes has a neat little page up elsewhere right now that could have existed in exactly the same form in '96. The web changed dramatically when 'big money' moved in and started turning the whole thing into a shopping mall / advertising space and I really think that that is degrading the medium. The internet has certainly improved in many ways since then as you rightfully illustrate but there was lots of good in those early days (of the web) as well, and plenty of it got destroyed. Usenet is a good example, there are those who argue that usenet had had it's run and that the web killed it, but it is my opinion that the spam is what killed it, not the competition from the web. Probably I prefer to have less signal but of a higher quality rather than an absolute overload where you have to sift for the bits that are worth your time.
nalbyuites 17y ago
Wow. A slashdot link in many months on HN. Telling.
RiderOfGiraffes 17y ago
Out of interest I downloaded the page with curl, then stripped out the JS and other stuff, leaving mostly just formatting and text. Before: 178845 bytes After : 33604 bytes That's just the page, and doesn't include images or ads, but it does include the text of the comments. Just an observation.
seshagiric 17y ago
Compressing http content also means extra processing on both the client and the server side. While this might not be as noticeable on a PC, for mobile phones it sure can be a concern. It will be interesting to see some data on it.

17 points by spahl 17y ago

The quickest way for a 'dramatic' speedup of the web is to install an ad blocker. Also, 'dramatic' speedups will only lead to pages that get loaded up with more junk. If that had not happened we'd already have an extremely fast browsing experience. It's like memory and disk space, if the budget increases then there will be some way to spend that budget. If web pages load in under one second they'll be 'improved' until they load in 3 to 4 seconds again. spdy:// ? I don't think so. Let's drop some of that flash and turn on gzip compression (if you haven't done that already) and make sure your cache headers are set properly. That alone will probably give you a 50% boost.

dazzawazza 17y ago
While your points are valid in order for webapps to continue their march in to desktop app territory they need to decrease latency. I think this is what spdy is there for. I'm sure a lot of fat will be added to apps but if my AJAX requests are snappier I am more then happy to support this.
- jacquesm 17y ago
  from: http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepa... "To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below)." The bigger chunk of which seems to come from header compression. SPDY is targeted to be placed between HTTP and TCP. It 'only' requires changes to the client and the webservers. That makes me a little skeptical about the value of their tests, I can't imagine they got the top 500 websites to change their server architecture to allow this test to take place. They are very much focused on the latency issues but the only references they give are for things related to page load time, which are affected peripherally by latency, but latency is much more of an effect on single connections. And the only gain from that would be to compress the headers. If header compression is that much of a deal then I would suggest to add optional header compression to the http standard, not to place layers in between http and tcp. And that layer would have to add 0 overhead all by itself on single connections or the results would be negative instead of positive. You can't really support this unless the client supports it as well, think of it as a specialized gateway function inside the browser that knows how to tunnel HTTP over SPDY to hosts that support it, the key factor is interleaving frames of content from different sources. Essentially a packet multiplexer/demultiplexer if I read it all right, that will pack all the requests on the sending side and unpack them at the receiving end to go to their respective handlers. By the way, the 'server pushes resources before the client has asked for it' is what has been making my webcam software functional for the last 15 years or so. I clued in to that in '95 or so using the server-push technology and figured out that since I already knew that the next request would be for another frame of the same cam why not send it right now instead of waiting for the browser to ask for it...
confuzatron 17y ago
Good parody of the internet curmudgeon, there.
- jacquesm 17y ago
  Have a look at how the large majority of the top 500 web servers are set up and see if you disagree. A large portion of them could be sped up by simply configuring them properly, using nothing but the facilities that are available today. I'm not sure if this link will 'live' for other others, but it is an analysis of cnn.com, it shows the homepage clocks in at a whopping 1.1M! http://www.webpagetest.org/result/091113_2YFS/ http://www.webpagetest.org/result/091113_2YFS/ And has tons of caching and compression issues. Feel free to try out any other 'large' website and you'll find that only very few of them actually come in green across the board.
  - neilc 17y ago
    A large portion of them could be sped up by simply configuring them properly, using nothing but the facilities that are available today. Probably true, but not relevant to SPDY: you can't assume that every website in the world is going to be configured "properly." SPDY's improvements are orthogonal to other improvements that might be made to site configurations.
RyanMcGreal 17y ago
> Also, 'dramatic' speedups will only lead to pages that get loaded up with more junk. Jevon's paradox in action?
bumblebird 17y ago
>> "The quickest way for a 'dramatic' speedup of the web is to install an ad blocker." Because most websites would go out of business and there wouldn't be much left to browse?
- jacquesm 17y ago
  Possibly. But then again, I don't see any ads on HN, and I do remember a version of the web that did not have advertising on it. It also had a significantly better signal to noise ration than the current one does.
  - dkarl 17y ago
    That web still exists, if you can keep your eyes off the flashy pretty stuff.
  - tptacek 17y ago
    I had dialin access in '93, and my first browser was Mosaic on Win3.1 under Trumpet Winsock, and I ran the tech side of an ISP from 95-97, and under no circumstances would I ever trade the web of '97 for the one I have today, where I can watch TV, browse Cooks Illustrated, learn Calculus, and read entire books. I wouldn't even trade Hacker News for Usenet. The signal to noise ratio in '97 was high because there was very little signal, and not as many people cared.
    - jacquesm 17y ago
      > The signal to noise ratio in '97 was high because there was very little signal I don't agree with that at all, there was plenty of signal, it just wasn't in 'rich media' format. Pages were static and simple instead of having a multi-media circus to put across a simple point. RiderOfGiraffes has a neat little page up elsewhere right now that could have existed in exactly the same form in '96. The web changed dramatically when 'big money' moved in and started turning the whole thing into a shopping mall / advertising space and I really think that that is degrading the medium. The internet has certainly improved in many ways since then as you rightfully illustrate but there was lots of good in those early days (of the web) as well, and plenty of it got destroyed. Usenet is a good example, there are those who argue that usenet had had it's run and that the web killed it, but it is my opinion that the spam is what killed it, not the competition from the web. Probably I prefer to have less signal but of a higher quality rather than an absolute overload where you have to sift for the bits that are worth your time.

nalbyuites 17y ago

Wow. A slashdot link in many months on HN. Telling.

RiderOfGiraffes 17y ago

Out of interest I downloaded the page with curl, then stripped out the JS and other stuff, leaving mostly just formatting and text. Before: 178845 bytes After : 33604 bytes That's just the page, and doesn't include images or ads, but it does include the text of the comments. Just an observation.

seshagiric 17y ago

Compressing http content also means extra processing on both the client and the server side. While this might not be as noticeable on a PC, for mobile phones it sure can be a concern. It will be interesting to see some data on it.