

Measuring download speed by embedding a GIF inside a JavaScript comment  - jgrahamc
http://www.jgc.org/blog/2009/03/measuring-download-speed-by-embedding.html

======
mmj

      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.

~~~
mooism2
Perhaps a gif was used on the assumption that gzip wouldn't be able to further
compress it.

~~~
nikblack
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.

~~~
gojomo
_since it is gzipped, there is no progressive download of the page_

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.)

------
tlrobinson
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.

If not, this is relevant: [http://thedailywtf.com/Articles/Bulletproof-
JavaScript-Detec...](http://thedailywtf.com/Articles/Bulletproof-JavaScript-
Detection.aspx)

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.

------
arantius
gzip + chunked encoding = works

<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.

