Como posso reconhecer dispositivos lentos no meu site?

Ao adaptar uma página da web para dispositivos móveis, sempre confio em consultas de mídia css.

Recentemente eu não me preocupo apenas com o tamanho da tela, mas também com o mecanismo de javascript de muitos dispositivos móveis. Alguns efeitos comuns de javascript que dependem de rolagens de janelas ou de uma rápida seqüência de transformações DOM funcionam muito mal em dispositivos lentos.

Existe alguma maneira de adivinhar o desempenho do dispositivo para que eu possa ativar / desativar elementos com aparência ruim em dispositivos lentos?

Até agora só consigo pensar em soluções ruins:

tamanho da tela. tela estreita "pode" significar dispositivo lentoinformações do agente do usuário. Eu poderia olhar para o dispositivo, navegador ou cpu, mas isso não parece uma solução estável a longo prazo por causa da quantidade de dispositivos a considerar

ATUALIZAÇÃO: Corrigimos minha pergunta para me concentrar em um problema. Nos comentários, há uma boa solução para o problema da interface de toque.

 Basic15 de set de 2012 15:09
Apenas uma observação, mas o navegador android nativo pode fazer passar os acontecimentos. Parece ter um conceito de um cursor de mouse invisível que é colocado no último local de toque - assim, hover pode ser simulado tocando com um pequeno arrasto para evitar um clique. Não é ideal e certamente não é universalmente suportado, mas vale a pena conhecer
 Matt Whipple15 de set de 2012 15:19
Isso cobre a questão do foco:stackoverflow.com/questions/4643443/…
 Gabe15 de set de 2012 14:54
O que você fará de diferente se o navegador for muito lento?
 Gregor15 de set de 2012 14:56
O que você acha de uma abordagem inversa: encontrar navegadores rápidos e ativar efeitos para eles - isso pode ser feito usando uma consulta de agente de usuário no Webkit, no Firefox e nos Internet Explorer recentes.
 SystematicFrank15 de set de 2012 14:59
@gabe gostaria de desativar alguns elementos. Por exemplo, as barras de navegação dinâmicas que aparecem quando você rola pelo cabeçalho são terríveis. Também galerias de imagens com transições animadas não são fluidas, eu desabilitaria a transição da imagem.
 SystematicFrank15 de set de 2012 15:11
@gabe Eu atualizei a questão para torná-la mais genérica. Veja a seção UPDATE. Sua idéia sobre uma abordagem inversa é boa hoje, mas no futuro haverá uma combinação de dispositivos móveis lentos e terrivelmente rápidos. Portanto, não parece uma solução estável a longo prazo.
 Basic15 de set de 2012 15:11
Você poderia executar algumas operações DOM e programá-las. Não perfeito eu sei e você precisa ter certeza de que não impacta a página indevidamente, mas pode lhe dar uma idéia bastante precisa da velocidade do cliente ao manipular elementos

questionAnswers(3)

QuestionSolution

Certamente parece que não há uma solução particularmente boa para esse problema (o que faria sentido, já que esse tipo de coisa normalmente é o tipo de coisa que está escondida). Eu acho que de qualquer maneira o seu melhor começando com a detecção de UA para cuidar dessas plataformas que são conhecidas por cair em uma categoria ou outra. Então você tem duas opções para se adaptar de forma flexível a plataformas desconhecidas / incertas:

Aprimoramento Progressivo: Comece com um teste simplificado e carregue um pequeno teste de desempenho ou testes para avaliar o desempenho do dispositivo e, em seguida, carregue os arquivos para os aprimoramentos apropriados. Teste como já fornecido ou em:Pule algum código se o computador estiver lento

Degradação Graciosa: Enrole os recursos que são candidatos para causar UX desfavorável em dispositivos mais lentos em uma função de ordem superior que os substitua se demorar muito na primeira execução. Neste caso, eu provavelmente adicionariaFunction.prototype e, em seguida, permitir que um argumento de atraso aceitável seja encadeado na definição da função. Após o primeiro armazenamento de chamada, o tempo expirou e, em seguida, na segunda chamada, se o tempo decorrido for superior ao atraso, troque a função por um fallback. Se o tempo decorrido for aceitável, remova o código de criação de perfil trocando a função padrão. Eu precisaria sentar e trabalhar com código de amostra (talvez neste fim de semana). Isso também pode ser ajustado por argumentos adicionais, como para o perfil várias vezes antes da troca.

A primeira opção provavelmente seria a opção mais amigável, mas a segunda pode ser menos invasiva para o código existente. Os cookies ou a coleta de dados do UA também ajudariam a continuar o perfil depois que as informações forem recuperadas.

 Matt Whipple18 de set de 2012 14:34
Essa seria uma das desvantagens, dependendo de quais são os aprimoramentos da interface do usuário (e qual é o primeiro acionado), pode não haver nenhuma maneira de ter um salto perceptível. Acabei de dizer apenas adicionar uma mensagem que desliza rapidamente da parte superior ou inferior dizendo algo como "otimizar as configurações do seu dispositivo" para que o usuário saiba que isso é um recurso e não um ou mais bugs.
 Matt Whipple18 de set de 2012 14:16
Se você quisesse um exemplo de código, eu poderia escrever algo hoje.
 SystematicFrank18 de set de 2012 14:23
Não se preocupe, eu tenho muito claro como implementar isso. Para mim é complicado o detalhe de cada caso e como reagir rápido o suficiente, caso contrário, o usuário deve experimentar pelo menos uma vez uma falha da interface do usuário
 SystematicFrank18 de set de 2012 09:30
Eu gosto da idéia de degradação graciosa, pois acredito que um widget "pesado" pode ser um teste de velocidade. Eu perguntei sobre a detecção de dispositivos lentos quando o que eu realmente queria era detectar se algum widget estava rodando muito devagar no cliente. O problema com outras soluções de teste de velocidade é que depois de obter um resultado numérico, é preciso encontrar um limite do que é aceitável ou não.

Você poderia fazer seu próprio mini benchmark de tipos. Faça alguns cálculos exigentes e cronometre o resultado. Se for mais lento que o dispositivo que você considera mais lento, você acessa uma versão menos intensiva do seu site.

Você também pode criar um link facilmente acessível para alternar para o site mais básico se o usuário estiver com problemas de desempenho.

Sair do tamanho da tela não é uma boa ideia. Muitos telefones modernos têm telas pequenas com processadores rápidos.

 Pebbl15 de set de 2012 20:39
Imo indo no tamanho da tela é aceitável se tudo o que você está fazendo é degradação graciosa de "magia" supérflua não essencial :) - mas sim, para qualquer outra coisa você vai dificultar a experiência do usuário como telefones e tablets melhorar ao longo do tempo.

A única maneira que eu poderia pensar seria executar algum tipo de teste de velocidade em JS no fundo antes ou durante o uso dos efeitos. Isso deve capturar os dispositivos que estão lentos devido à velocidade do processador ou vice-versa. Capture dispositivos com tempo preciso / rápido. No entanto, se os dispositivos tiverem otimizações, o que significa que eles usam processadores diferentes para calcular os efeitos gráficos, isso não funcionará.

var speedtest = function(){
  /// record when we start
  var target = new Date().getTime(), count = 0, slow = 0;
  /// trigger a set interval to keep a constant eye on things
  var iid = setInterval(function(){
    /// get where we actually are in time
    var actual = new Date().getTime();
    /// calculate where we expect time to be
    target += 100;
    /// 100 value here would need to be tested to find the best sensitivity
    if ( (actual - target) > 100 ) {
      /// make sure we aren't firing on a one off slow down, wait until this
      /// has happened a few times in a row. 5 could be too much / too little.
      if ( (++slow) > 5 ) {
        /// finally if we are slow, stop the interval
        clearInterval(iid);
        /// and disable our fancy resource-hogging things
        turnOffFancyAnimations();
      }
    }
    else if ( slow > 0 ){
      /// decrease slow each time we pass a speedtest
      slow--;
    }
    /// update target to take into account browsers not being exactly accurate
    target = actual;
    /// use interval of 100, any lower than this might be unreliable
  },100);
}

É claro que, ao executar isso, você também afetará a velocidade do dispositivo, por isso não é a melhor solução. Como regra geral, tenho a tendência de desabilitar animações e outras coisas supérfluas simplesmente quando a tela é pequena.

Uma outra desvantagem desse método - que já experimentei antes - é que certos navegadores que implementam ambientes com várias abas setIntervals são automaticamente limitados a uma determinada velocidade quando a aba não está sendo visualizada. Isso significaria que a navegação pelos navegadores diminuiria automaticamente sua experiência - a menos que essa velocidade imposta limitada pudesse ser detectada de alguma forma.

 SystematicFrank15 de set de 2012 15:51
Eu gosto do seu código, mas como você disse, tem algumas desvantagens. Também não estou muito convencido sobre o uso de testes de velocidade como uma boa abordagem de design. Por outro lado, parece que não existe uma boa solução :(
 Pebbl15 de set de 2012 20:35
Sim, não se preocupe, eu não usaria essa abordagem na produção, eu apenas gosto de experimentar com JS. Por outro lado, você sempre tem uma alternativa ... Você poderia perguntar ao usuário, ou pelo menos expor algum tipo de controle, que lhes permitiria desabilitar as partes de fantasia, se não quiserem. Eu conheço muitos usuários que gostariam de desabilitar os extras gráficos, mesmo na visualização do desktop.

yourAnswerToTheQuestion