PS This system measured my connection speed as 20Mbps. Which is about 5x too large.
GET /inet/ent_logon/Logon?redirectjsp=true HTTP/1.1
HTTP/1.x 200 OK
Content-Encoding: gzip
no. since it is gzipped, there is no progressive download of the page and it is all downloaded at once and then executed. so startTime and endTime are measuring processor execution rather than download speed.
it is a flawed method. a better method would be to make an xmlhttprequest to an object of known size and compare the time to known times for known connection speeds. this method also has the advantage that you don't interrupt the page being loaded and don't interrupt the user experience since it is run in parallel.
Interesting, but this trick makes a ton of assumptions about the browser's behavior. I doubt it's very accurate.
As mmj pointed out, the page is gzip encoded. Will (can?) the browser actually decode and render/execute part of the gzipped stream before it's completed? Even without gzipping, will it? I suspect not.
And also notice the 10 second delay between the two paragraphs appearing in your browser. (At least it does for me, in FF3. In IE6, it only happens on the second-and-on load (F5).) It's perfectly possible, for a compliant browser, to download, and render, the page incrementally, even with gzip compression applied.
7 comments
[ 2.7 ms ] story [ 27.1 ms ] threadThe page is gziped.
it is a flawed method. a better method would be to make an xmlhttprequest to an object of known size and compare the time to known times for known connection speeds. this method also has the advantage that you don't interrupt the page being loaded and don't interrupt the user experience since it is run in parallel.
Gzipped data can be incrementally decompressed. Are you sure browsers download the entire page before starting decompression?
(Not that this would make the test much better; I agree it has numerous flaws. Just curious about what browsers actually do.)
As mmj pointed out, the page is gzip encoded. Will (can?) the browser actually decode and render/execute part of the gzipped stream before it's completed? Even without gzipping, will it? I suspect not.
If not, this is relevant: http://thedailywtf.com/Articles/Bulletproof-JavaScript-Detec...
Also, is 10KB (plus whatever came before) enough for the TCP connection to ramp up to full speed?
And, of course, JavaScript Dates are known to be pretty inaccurate in some browsers.
http://arantius.info/gzip-chunk.php
Notice headers: Content-Encoding gzip Transfer-Encoding chunked
And also notice the 10 second delay between the two paragraphs appearing in your browser. (At least it does for me, in FF3. In IE6, it only happens on the second-and-on load (F5).) It's perfectly possible, for a compliant browser, to download, and render, the page incrementally, even with gzip compression applied.