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

RE: detecting connection speed

From: Reitbauer, Alois <Alois.Reitbauer@compuware.com>
Date: Wed, 11 Dec 2013 19:51:42 +0000
To: Marcos Caceres <w3c@marcosc.com>, Jake Archibald <jakearchibald@chromium.org>
CC: Puneet Mohan Sangal <pmsangal@yahoo-inc.com>, public-web-perf <public-web-perf@w3.org>
Message-ID: <5e6f693c5e4a4e1bb37c8c646fab9be1@DM2PR05MB558.namprd05.prod.outlook.com>

From: Marcos Caceres <w3c@marcosc.com>
Sent: Wednesday, December 11, 2013 10:40 AM
To: Jake Archibald
Cc: Puneet Mohan Sangal; public-web-perf
Subject: Re: detecting connection speed

On Wednesday, December 11, 2013 at 6:47 PM, Jake Archibald wrote:

> I'm not keen on use-cases that boil down to "if connection is < something, serve degraded experience".

Agree. That would totally suck.
> 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.


Exactly.

[Alois] And how do you know these users have a slow connection? Isn't this what we are talking about?

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


That would be nice. I donít think anyone does this (either OS level or Web browser) - but it could be handled at the <video> or <audio> level for sure.

[Alois] Agree

>
> Adapting during streaming of something - yeah, these are great, we need to enable this.

This is a video/audio streaming protocol problem, me thinks. Not in scope for this group.
> Basically, if websites start offering a poor experience because of navigator.connectionType, then devices will lie so they get the better experience. See media="handheld" and user agent strings.

Agree.

Note that I also donít want web apps to try to be clever using this API (which they will undoubtedly fíup, as history teaches us) - but to provide *options* for the user to have some control over what is going on when it comes to large content downloads (particularly wrt how large amounts of data are handled).

For example, the iOS Audible application giving me control, as a user, whether it can d/l 300mb audio books over cellular. That makes sense to me. Or the Facebook app, giving me the choice to ďAuto-play videos on WIFI onlyĒ - that also makes sense to me. This is exactly what kind of choices iOS apps seem to provide - of the ones I have, I donít see any making dumb decisions on my behalf (maybe they are, but I donít see them doing it!:) Ö but seriously, there may be low quality apps doing the wrong thing - and there may be low quality websites that could also do the wrong thing).

If we donít feel we can trust developers to do the right thing with this information (even if itís just navigator.connectionType = ďwifiĒ or ďcellular"), then I think itís ok to discontinue this work. Then we can just leave it to browsers and OSs to try to do the right thing (e.g., through the video/audio and other media related tags).

Iím hopeful that we can expose something - but maybe itís too early to standardize this stuff in the form of an API. Or maybe there is just too much potential for people to do the wrong thing.






The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebšude G.
Received on Wednesday, 11 December 2013 19:52:19 UTC

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