- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Thu, 05 Dec 2013 11:43:06 +0100
- To: public-web-perf@w3.org, "James Graham" <james@hoppipolla.co.uk>
On Thu, 05 Dec 2013 11:11:16 +0100, James Graham <james@hoppipolla.co.uk>
wrote:
> On 04/12/13 19:44, Aaron Heady (BING AVAILABILITY) wrote:
>
>> In my experience, determining it on a per request basis just has too
>> much variance. Maybe if the UA kept its own set of statistics on a
>> per origin IP + current default gateway basis and knew that it was
>> generally good or bad for a given connection pair then it could pass
>> that hint along, maybe include a confidence hint with it (fast last
>> 99 of 100 connections). If that mobile device thinks it is always
>> fast to an IP given its current proxy, then it most likely is.
>
> So, I don't know exactly how it worked but Opera trie[s|d] to do
> something like this to hint at when the "turbo" compression feature
> should be enabled. In my experience it wasn't exactly reliable; I don't
> think I was alone in getting the "slow connection" popup when I knew
> perfectly well that I wasn't on a slow connection at all.
We do something similar with Turbo, using our own code for deciding when
to apply it. This is a use case for a browser.
A more generalised version may be a site (e.g. single-page app, although
it also applies to multi-page) that stays open a "long time" and downloads
a number of resources during that time. Somewhat like the responsive
images use cases, there may be multiple resources that can be offered, and
the expected speed of a connection is a determining factor for the server
to choose the most appropriate version of given resources.
The obvious question is whether anyone can share a real and concrete
version of that use case - making up theoretical problems is easy, but…
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Thursday, 5 December 2013 10:43:38 UTC