¿Cómo puedo reconocer los dispositivos lentos en mi sitio web?

Al adaptar una página web para dispositivos móviles, siempre confío en las consultas de medios css.

Recientemente ya no me preocupo solo por el tamaño de la pantalla, sino también por el motor javascript de muchos dispositivos móviles. Algunos efectos comunes de javascript que se basan en desplazamientos de ventanas o una secuencia rápida de transformaciones de DOM funcionan realmente mal en dispositivos lentos.

¿Hay alguna forma de adivinar el rendimiento del dispositivo para que pueda habilitar / deshabilitar elementos que se ven mal en dispositivos lentos?

Hasta ahora solo puedo pensar en malas soluciones:

tamaño de pantalla. pantalla estrecha "podría" significa dispositivo lentoinformación del agente de usuario. Podría mirar el dispositivo, el navegador o la CPU, pero eso no parece ser una solución estable a largo plazo debido a la cantidad de dispositivos a considerar.

ACTUALIZACIÓN: Se corrigió mi pregunta para centrarme en un problema. En los comentarios hay una buena solución para el problema de la interfaz táctil.

 SystematicFrank15 sept. 2012 15:11
@gabe actualicé la pregunta para hacerla más genérica. Mira la sección ACTUALIZACIÓN. Tu idea sobre un enfoque inverso es buena hoy, pero en el futuro habrá una combinación de dispositivos móviles lentos y terriblemente rápidos. Por lo tanto, no parece una buena solución estable a largo plazo.
 Gabe15 sept. 2012 14:54
¿Qué harías diferente si el navegador es demasiado lento?
 Basic15 sept. 2012 15:11
Podrías realizar algunas operaciones de DOM y cronometrarlas. No es perfecto, lo sé y deberías asegurarte de que no afecte demasiado a la página, pero podría darte una idea bastante precisa de la velocidad del cliente al manipular elementos.
 Matt Whipple15 sept. 2012 15:19
Esto cubre la pregunta flotante:stackoverflow.com/questions/4643443/…
 Gregor15 sept. 2012 14:56
¿Qué piensa acerca de un enfoque inverso: encontrar navegadores rápidos y habilitar efectos para ellos? Esto podría hacerse usando una consulta de agente de usuario en Webkit, Firefox y los recientes Internet Explorer.
 SystematicFrank15 sept. 2012 14:59
@gabe inhabilitaría algunos elementos. Por ejemplo, las barras de navegación dinámicas que aparecen cuando se desplaza más allá del encabezado se ven terribles. Además, las galerías de imágenes con transiciones animadas no son fluidas, deshabilitaría la transición de la imagen.
 Basic15 sept. 2012 15:09
Solo una observación, pero el navegador nativo de Android puede hacer eventos flotantes. Parece que tiene el concepto de un cursor de mouse invisible que se coloca en la última ubicación de toque, por lo que se puede simular el desplazamiento al tocar con un pequeño arrastre para evitar un clic. No es ideal y ciertamente no es universalmente compatible pero vale la pena saberlo

Respuestas a la pregunta(3)

Solución de preguntas

parece que no hay una solución particularmente buena para este problema (lo que tendría sentido ya que este tipo de cosas normalmente se supone que son las que están ocultas). Creo que, de cualquier manera, es mejor comenzar con la detección de UA para cuidar de las plataformas que se sabe que pertenecen a una categoría u otra. Entonces tendrías 2 opciones para adaptarte con flexibilidad a las plataformas desconocidas / inciertas:

Mejora progresiva: Comience con una prueba simplificada y cargue una pequeña prueba de rendimiento o pruebas para medir el rendimiento del dispositivo y luego cargue los archivos para las mejoras apropiadas. Prueba como la ya provista o en:Omita algún código si la computadora es lenta

Degradación elegante: Envuelva las funciones que son candidatas a causar UX desfavorables en dispositivos más lentos en una función de orden superior que las reemplaza si toman demasiado tiempo en la primera ejecución. En este caso probablemente lo agregaría aFunction.prototype y luego permitir que un argumento de retardo aceptable sea encadenado a la definición de la función. Después de la primera invocación, almacene el tiempo transcurrido, y luego, en la segunda invocación, si el tiempo transcurrido es mayor, el retardo intercambia la función con una alternativa. Si el tiempo transcurrido es aceptable, elimine el código de perfil cambiando la función estándar. Necesito sentarme y trabajar con un código de muestra (quizás este fin de semana). Esto también podría ajustarse mediante argumentos adicionales, como perfilar varias veces antes de intercambiar.

La primera opción probablemente sea la opción más amigable, pero la segunda puede ser menos intrusiva al código existente. Las cookies o la recopilación de datos adicionales de UA también ayudarían a continuar con el perfil después de recuperar la información.

 SystematicFrank18 sept. 2012 09:30
Me gusta la idea de una degradación elegante, ya que creo que un widget "pesado" puede ser una prueba de velocidad. Pregunté sobre la detección de dispositivos lentos cuando lo que realmente quería era detectar si algún widget se estaba ejecutando demasiado lento en el cliente. El problema con otras soluciones de prueba de velocidad es que después de obtener un resultado numérico, uno debe encontrar un umbral de lo que es aceptable o no.
 SystematicFrank18 sept. 2012 14:23
No se preocupe, tengo muy claro cómo implementar eso. Para mí es complicado el detalle de cada caso y cómo reaccionar lo suficientemente rápido, de lo contrario, el usuario debe experimentar al menos una vez una falla en la interfaz de usuario
 Matt Whipple18 sept. 2012 14:16
Si quisieras un ejemplo de código podría escribir algo hoy.
 Matt Whipple18 sept. 2012 14:34
Esa sería una de las desventajas, dependiendo de cuáles sean las mejoras de la interfaz de usuario (y cuál es la primera activación), puede que no haya manera de evitar un salto notable. Solo diría que simplemente agregue un mensaje que se deslice brevemente desde la parte superior o inferior diciendo algo como "optimización de la configuración de su dispositivo" para que el usuario sepa que esta es una característica y no uno o más errores.

os exigentes y cronometrar el resultado. Si es más lento que el dispositivo que considera que es el más lento, entonces pasa a una versión menos intensiva de su sitio.

También puede hacer un enlace de fácil acceso para cambiar al sitio más básico si el usuario tiene problemas de rendimiento.

Salir del tamaño de la pantalla no es una buena idea. Un montón de teléfonos modernos tienen pantallas pequeñas con procesadores rápidos.

 Pebbl15 sept. 2012 20:39
El tamaño de la pantalla de Imo es aceptable si todo lo que está haciendo es una degradación elegante de la "magia" superflua no esencial :) - pero sí, para cualquier otra cosa, dificultará la experiencia del usuario a medida que los teléfonos y las tabletas mejoran con el tiempo.

ueba de velocidad en JS en segundo plano antes o durante el uso de los efectos. Esto debería capturar los dispositivos que son lentos debido a la velocidad de su procesador o viceversa, capturar los dispositivos que son precisos en el tiempo. Sin embargo, si los dispositivos tienen optimizaciones, lo que significa que utilizan diferentes procesadores para calcular los efectos gráficos, esto no 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);
}

Por supuesto, al ejecutar esto, también afectará la velocidad del dispositivo, por lo que no es la mejor solución. Como regla, tiendo a desactivar las animaciones y otras cosas superfluas, simplemente cuando la pantalla es pequeña.

Otro inconveniente de este método, que he experimentado antes, es que un cierto navegador que implementa entornos de múltiples pestañas setIntervals se limita automáticamente a una cierta velocidad cuando la pestaña no se está viendo. Esto significaría que, para estos navegadores, el hecho de separar las pestañas degradaría automáticamente su experiencia, a menos que esta velocidad impuesta limitada pueda detectarse de alguna manera.

 Pebbl15 sept. 2012 20:35
Sí, no te preocupes, no usaría este enfoque yo mismo en producción, simplemente me gusta experimentar con JS. Por otro lado, siempre tiene una alternativa ... Podría pedirle al usuario, o al menos exponer algún tipo de control, que le permitiría deshabilitar las piezas de fantasía si no las desea. Conozco a muchos usuarios a quienes les gustaría deshabilitar los extras gráficos incluso en la vista de escritorio.
 SystematicFrank15 sept. 2012 15:51
Me gusta tu código, pero como dijiste, tiene algunas desventajas. Tampoco estoy muy convencido de usar las pruebas de velocidad como un buen enfoque de diseño. Por otro lado, parece que no existe una buena solución :(

Su respuesta a la pregunta