Re: detecting connection speed

We seem to have general agreement that adding byte size info to ResTiming
and navTiming is a good idea [1].
At least when it comes to (heuristic) bandwidth estimation, if there are
concrete use-cases, they will be implementable using JS and the Timing
APIs+byte-size.
So, once it's added, if we'd see that they're being used extensively for BW
estimation, we could then discuss standardizing a simpler, JS-free and
possibly more accurate API to give developers that info.
Currently, I don't think we know what people need. (and if they need it at
all)

On Wed, Dec 11, 2013 at 9:47 AM, Jake Archibald
<jakearchibald@chromium.org>wrote:

> I'm not keen on use-cases that boil down to "if connection is < something,
> serve degraded experience". My mobile provider uses a compression proxy and
> I hate it, I'd rather wait longer to avoid a sub-standard experience. If
> you've got users with slow connections, make your site faster for them by
> making your site faster for everyone. If that means loading in low res
> content then high res content to get to first render faster, this benefits
> everyone.
>
> Avoiding video autoplay on 3g, or warning about data use - this is valid
> but something the browser/os could do, especially as the user may have set
> data limits. This avoids every site having to implement the same messaging,
> and the user can "don't tell me again" these kind of messages at the
> browser/os level rather than per site.
>

I like that idea, but it calls for an entirely different type of API.
Basically, we'd need a "Can I start this large download now?" API, which
the browser will respond according to user prefs.

[1] http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0069.html