¿Cuál es la mejor manera de determinar en tiempo de ejecución si un navegador es demasiado lento para manejar de manera elegante JavaScript/CSS complejo?

Question

Estoy jugando con la idea de habilitar/deshabilitar progresivamente los efectos de JavaScript (y CSS) en una página, dependiendo de qué tan rápido/lento parezca el navegador.

Estoy pensando específicamente en los dispositivos móviles de baja potencia y ordenadores de sobremesa de edad - no sólo IE6 :-)

¿Hay ejemplos de este tipo de cosas se está haciendo?

¿Cuál sería la mejor manera de medir esto? ¿Tener en cuenta las cosas, como la ralentización temporal de las CPU ocupadas?

Notas:

• no estoy interesado en la detección del navegador/OS.
• Por el momento, no me interesan las medidas de ancho de banda, solo el rendimiento del navegador/CPU.
• cosas que pueden ser interesantes para medir:
  • Base JavaScript
  • manipulación del DOM
  • DOM/CSS representación
• Me gustaría hacer esto de una manera que afecta a la página de render-speed lo menos posible.

BTW: Para no confundir/irritar a los usuarios con un comportamiento incoherente, esto requeriría, por supuesto, notificaciones en pantalla para permitir a los usuarios participar o no de todo este proceso de ajuste del rendimiento.

[Actualización: hay una pregunta relacionada que me perdí: Disable JavaScript function based on user's computer's performance. Gracias Andrioid!]

Answer 1

Algunas ideas:

• Poner un límite de tiempo en las pruebas parece una opción obvia.
• Almacenar los resultados de las pruebas en una cookie también parece obvio.
• pobre rendimiento de la prueba en una prueba podría hacer una pausa más guiones
  • y pantalla gatillo de una interfaz de usuario rápida sin bloqueo (como la contraseña guardar solicita común en los navegadores web modernos)
  • que pregunta al usuario si desea opte por más efectos de scripting y almacene la respuesta en una cookie.
  • mientras el usuario no ha respondido al aviso, luego repita periódicamente las pruebas y acepte automáticamente la solicitud de scripting si las pruebas consecutivas finalizan más rápido que la primera.
    .
• En una nota - las velocidades de red lentas podrían también, probablemente, ser probados
  • midiendo el tiempo de la descarga de los recursos externos (como las páginas propios archivos CSS o JavaScript)
  • y comparando este resultado con el punto de referencia de JavaScript resultados.
  • esto puede ser útil en sitios que dependen de cargas de efectos XHR y/o uso intensivo de <img/> s.
    .
• Parece que los puntos de referencia de representación/manipulación DOM son difíciles de realizar antes de que la página haya empezado a procesarse, y es probable que causen retrasos bastante notables para todos los usuarios.

Answer 2

Puede intentar sincronizar algunas operaciones básicas: eche un vistazo a los episodios de Steve Souder y al bumerán de Yahoo para encontrar buenas formas de sincronizar las cosas con la vista. Sin embargo, será bastante complicado determinar cómo se relacionan las métricas con un nivel aceptable de rendimiento/una experiencia de usuario gratificante.

Si va a proporcionar una interfaz de usuario para que los usuarios puedan optar por no participar, ¿por qué no dejar que el usuario elija el nivel de caramelo en la aplicación frente a la velocidad de reproducción?

Answer 3

Para no ser un aguafiestas aquí, pero esto no es una hazaña actualmente posible de ninguna manera significativa en mi opinión.

Hay varias razones para esto, las principales son:

1. Cualquiera que sea la medida que hagas, si ha de tener algún significado, tendrá que probar el máximo potencial del navegador/CPU, lo cual no puede hacer y mantener ningún tipo de experiencia de usuario razonable

2. Incluso si pudiera, sería una instantánea sin sentido ya que no tiene idea de qué tipo de carga está la CPU de otras aplicaciones distintas del navegador mientras se realiza su prueba corriendo, y el clima o no esa situación continuará mientras el usuario visita su sitio web.

3. Incluso si pudiera hacer eso, cada navegador tiene sus propias fortalezas y debilidades, lo que significa que tendría que probar cada función de manipulación para saber qué tan rápido el navegador la completaría, no hay "general" o "promedio" que tiene sentido aquí en mi experiencia, e incluso si lo hubo, la velocidad con la que se ejecutan los comandos de dom manipulación se basa en el contexto de lo que está actualmente en el dominio, que cambia cuando lo manipulas.

Lo mejor que puede hacer es o bien

1. los usuarios puedan elegir lo que quieren, y les permitirá cambiar fácilmente esa decisión si lo lamentan

   o mejor aún

2. Elija darles algo de lo que pueda estar razonablemente seguro de que la mayor parte de su público objetivo podrá disfrutar.

poco fuera de tema, pero siguiendo esta línea de pensamiento: si los usuarios no son techleaders en sus círculos sociales (como la mayoría de los usuarios de aquí están, pero la mayoría de personas en el mundo no lo son) no darles demasiada elección, es decir. cualquier elección que no sea absolutamente necesaria: no la quieren y no comprenden las consecuencias técnicas de su decisión antes de que sea demasiado tarde.

Answer 4

Tome un vistazo a algunos de los de Google puntos de referencia para V8 (con derechos de autor!):

• http://v8.googlecode.com/svn/data/benchmarks/v4/regexp.js

• http://v8.googlecode.com/svn/data/benchmarks/v4/splay.js

elegí un par de los más simples para dar una idea de puntos de referencia similares que podría crear usted mismo para probar conjuntos de características. Siempre que mantenga el tiempo de ejecución de sus pruebas entre el tiempo registrado desde el principio hasta el tiempo registrado al finalizar en menos de 100   ms en los sistemas más lentos (que estas pruebas de Google son mucho mayores que) debe obtener la información que necesita sin siendo perjudicial para la experiencia del usuario. Si bien los puntos de referencia de Google se preocupan por la granularidad entre los sistemas más rápidos, no es así. Todo lo que necesita saber es qué sistemas tardan más de XX   ms en completarse.

cosas que podría poner a prueba son las operaciones regulares de expresión (similares a los anteriores), la concatenación de cadenas, la página de desplazamiento, cualquier cosa que cause un repintado navegador o reflujo, etc.

Answer 5

Un enfoque diferente, que no necesita referencia explícita , sería para habilitar funciones progresivamente.

Puede aplicar las funciones en orden de prioridad, y después de cada una, descarte el resto si ha transcurrido un cierto período de tiempo.

Asegurándose de que las funciones más costosas sean las últimas, presentaría al usuario una selección de características adecuada según la velocidad del navegador.

Answer 6

Puede ejecutar todos los puntos de referencia que desee utilizando Web Workers, luego, según los resultados, almacenar su detección sobre el rendimiento de la máquina en una cookie. Esto es solo para HTML5 Navegadores compatibles, por supuesto