3 ms·

And how much is it compressed? Let's see... ~ $ curl -s 'http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/' | gzip | wc -c 1741 ~ $ curl

And how much is it compressed? Let's see... ~ $ curl -s 'http://studentweb.infotech.monash.edu/~wlay/FIT1012/muse-demo/' | gzip | wc -c 1741 ~ $ curl -s 'http://muse.adobe.com/index.html' | gzip | wc -c 11521 Hmm, so 11.5kB vs 1.7kB with gzip, which I believe browsers can usually handle. That's a factor of 6.6, incidentally. I don't know much about this, but might it still be ok? I thought to check this because of ridiculousfish's old article (note the FAQ at the bottom, "Isn't that a humungous flood of markup?"): http://ridiculousfish.com/blog/archives/2009/06/01/roundy/#fish_made_a_mess http://ridiculousfish.com/blog/archives/2009/06/01/roundy/#f...

libria 15y ago
That factor is exacerbated on a smartphone. Plus, some of them pay for bandwidth.
Rantenki 15y ago
Keep in mind that those connections are all going to be stuck in TCP slow start (gradually improving) for the duration of their communications, meaning that the smaller version gets loaded in 2*RTT, as it will probably fit, in it's entirety, in 2 packets. The larger one is going to take 8 or so packets, meaning a lot more RTTs (probably at least 4, assuming aggressive TCP tuning, and possibly 6. Since RTT can easily be 120ms, these can be substantially larger load times, and that can make a huge impact to user impression: Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006). edit: It has been pointed out below that rfc2581 is going to mitigate this somewhat, and they are absolutely right, although I don't know what the implementation levels on this are in the real world, so my observations above may be obsolete for newer OSs.
- jsnell 15y ago
  Basic RFC 2581 should hardly count as an aggressively tuned stack, and even it'd do the larger file in 4 roundtrips (syn/synack, req/2 packets, -/4 packets more, -/8 packets more). These days even an initial cwnd of 10 might not count as aggressive any more, given it's the default initial cwnd on recent Linux kernels...

libria 15y ago

That factor is exacerbated on a smartphone. Plus, some of them pay for bandwidth.

Rantenki 15y ago

Keep in mind that those connections are all going to be stuck in TCP slow start (gradually improving) for the duration of their communications, meaning that the smaller version gets loaded in 2*RTT, as it will probably fit, in it's entirety, in 2 packets. The larger one is going to take 8 or so packets, meaning a lot more RTTs (probably at least 4, assuming aggressive TCP tuning, and possibly 6. Since RTT can easily be 120ms, these can be substantially larger load times, and that can make a huge impact to user impression: Even small changes in response times can have significant effects. Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006). edit: It has been pointed out below that rfc2581 is going to mitigate this somewhat, and they are absolutely right, although I don't know what the implementation levels on this are in the real world, so my observations above may be obsolete for newer OSs.

jsnell 15y ago
Basic RFC 2581 should hardly count as an aggressively tuned stack, and even it'd do the larger file in 4 roundtrips (syn/synack, req/2 packets, -/4 packets more, -/8 packets more). These days even an initial cwnd of 10 might not count as aggressive any more, given it's the default initial cwnd on recent Linux kernels...