- 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