RE: detecting connection speed

Checking in here


There are use cases for both:


Content-Size: Figuring out use cases where intermediate e.g. proxies mess up the content and - for example - return empty content.


Connection Speed: Deciding whether you have problems serving to certain users on your end or whether slow response times are due to a user's connection speed. Today this is used by most RUM solutions. They way the data is collected is by downloading progressively large images.  There are other ways like network sniffers at edge routers to get this information. This, however, does not work when serving your content from CDNs.


// Alois


Alois Reitbauer | Technical Product Manager | Compuware APM



________________________________
From: Yoav Weiss <yoav@yoav.ws>
Sent: Thursday, December 5, 2013 12:18 PM
To: James Graham
Cc: public-web-perf
Subject: Re: detecting connection speed




On Thu, Dec 5, 2013 at 12:04 PM, James Graham <james@hoppipolla.co.uk<mailto:james@hoppipolla.co.uk>> wrote:
On 05/12/13 10:51, Yoav Weiss wrote:
On Thu, Dec 5, 2013 at 11:17 AM, James Graham <james@hoppipolla.co.uk<mailto:james@hoppipolla.co.uk>
<mailto:james@hoppipolla.co.uk<mailto:james@hoppipolla.co.uk>>> wrote:

    On 04/12/13 23:04, Ilya Grigorik wrote:

        Somewhat of a tangent...

        There have been multiple requests in the past to expose the "bytes
        transferred" as part of Nav/Resource Timing API. While this is not a
        panacea, I do think it would be valuable and could address a lot
        of use
        cases we're discussing here...


    What use cases? I haven't actually seen a list of use cases people
    want solved anywhere in this thread yet. Without that it is
    impossible to tell if any particular API would be valuable or not.


I've previously raised it on the list [1]. The main use-case I see for
that is enabling RUM solutions to detect compression issues along the
path, with the side-effect of enabling authors to experiment with
client-side effective-bandwidth detection strategies.

Apart from the first one, those aren't very concrete use cases. A concrete use case would be something like:

"Youtube.com wants to serve video over the internet. In order to stream with minimal interruptions in the face of variable network conditions, it would like to dynamically adapt the bitrate of the streamed video to match the currently available bandwidth"

Of course this is an already-solved use case, but it is good in the sense that it refers to a real problem that an actual site is having, not a problem that we think a hypothetical site might  be having, and sets out some clear parameters for deciding whether the solution is good enough (e.g. "solution must work for video", "solution must allow adaption in realtime", etc.)


I've misread your previous mail, and thought you're asking about use-cases for adding "bytes transferred" to ResourceTiming. I don't have a concrete use-case for the "bandwidth" attribute, even though I can think of some non-concrete ones. I think exposing "bytesTransferred" in ResourceTiming can enable authors to do crude BW detection on the client-side and let concrete use-case examples evolve naturally.

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.