W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2013

Re: detecting connection speed

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 11 Dec 2013 16:39:45 -0800
Message-ID: <CADXXVKoGtXyC3+LOREhuGBRsbyzJfZ3xaQ7-YuLHV7M24p76Lg@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: Jake Archibald <jakearchibald@chromium.org>, Marcos Caceres <w3c@marcosc.com>, Puneet Mohan Sangal <pmsangal@yahoo-inc.com>, public-web-perf <public-web-perf@w3.org>
On Wed, Dec 11, 2013 at 4:39 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> TL;DR: We shouldn't focus on stopping people doing dumb things that aren't
> harmful, we should focus on enabling people to do smart things that are
> useful.


Big +1 to that. You can shoot yourself in the foot with just about
anything, including Service Worker, Web Components, and just about every
other feature. Reporting connection type / bandwidth estimation is no
different -- the more pertinent question is which of the different methods
to expose this data makes more sense.

On Wed, Dec 11, 2013 at 5:46 AM, Yoav Weiss <yoav@yoav.ws> wrote:

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

+1 for exposing bytesize, as it will allow us to begin experimenting with
this stuff. That said, it's worth noting that this type of measurement can
only be done *after* some resource has been fetched, and is also subject to
state of the connection itself (i.e. need to guard for slow-start, etc).
Exposing connection type or some global BW estimation scheme would measure
and enable different use cases -- whether they are high priority /
reasonable to implement is a separate conversation.

In short: bytesize on NavTiming + ResourceTiming is a great place to start.

ig
Received on Thursday, 12 December 2013 00:40:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC