Measuring download speed by embedding a GIF inside a JavaScript comment
jgc.org
jgc.org
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
The 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.