Measuring connection speed, ctd.

Measuring connection speed, ctd.:
Well, there were some interesting comments on my last post about connection speed in browsers. This post continues the conversation by giving my replies to a few notes, thoughts, and concerns.

First of all, three interesting resources were noted:

• Network Information API. This has come a long way since I looked last time (which may be over a year ago; I can’t remember). The spec does not treat HTTP headers or media queries; just JavaScript.


• A proposal by Ilya Grigorik that addresses several points that come close to what I envision.


• HTTP and timing API research. Especially interesting is the conclusion that the timing API is generally reliable. The only thing that’s missing is information about the browsers it was tested in.

Then the critique points:

It’s more complicated than just connection speed. That is true, but it’s not an argument against measuring connection speed. It’s is definitely part of the problem and should be measured.

Let users decide which assets to load. Some may prefer high-res ones. This is a good idea in principle, but we don’t really want to indicate a preference on every single site we visit, do we? So it’s either a browser preference (possible), or a site preference in case assets such as videos or images are vital content (video or photography sites, for instance).

Measure the connection speed during the loading of the site. Also a good idea, and in my proposal that’s going to happen anyway because everything is measured, but I’m not sure if the gathered data should be used for the same site. It may contradict earlier readings.

Units. The spec uses Mbps, so I guess we should standardise on that. It doesn’t really matter, as long as it’s a number, and not a keyword. (What does “slow” mean? Is one browser’s “slow” comparable to another browser’s?) And the connection type is unimportant, since it doesn’t necessarily say anything about the connection speed.

No-JavaScript-enabled and No-Images-enabled media queries. Also a good idea. The first one actually exists in the spec, the second one doesn’t but could be added.

The most complicated question is still wide open: exactly how are we going to measure the connection speed? Plenty of proposals were made; summarised as “a mixture of available TCP connection time, bandwidth,
latency and packet loss.” This partly depends on what the browser can measure, and in the end we’re mostly interested in the end result: which effective connection speed does the browser have?

The period over which we should take an average is especially important. And whether every single request should be measured equally, or whether there should be a kind of weighting.

Anyway, please continue. This is most instructive.

DIGITAL JUICE