El diseño receptivo no es suficiente, necesitamos un rendimiento receptivo

Recientemente me encontré con muchos sitios web receptivos con muchos problemas de rendimiento. En la mayoría de ellos, los problemas son tan evidentes que son casi inútiles en cualquier cosa que no sea la última generación de teléfonos inteligentes. Teniendo en cuenta el hecho de que la capacidad de respuesta como concepto pretende llegar a un público más amplio, esto parece bastante contraproducente.

El mayor contribuyente a este problema es el paradigma de diseño de escritorio primero que aún prevalece. Pensar desde la perspectiva de los dispositivos móviles primero parece abordar el problema, pero eso por sí solo no garantiza un rendimiento satisfactorio. Todos parecemos confiar demasiado en una degradación más o menos elegante. Confiamos en calces y polirellenos para habilitar la funcionalidad faltante. Confiamos en las bibliotecas para permitir un desarrollo rápido y para respaldarnos cuando la compatibilidad del navegador es un problema.

"¿Por que preocuparse?" podrías preguntar. “La mayoría de nuestros visitantes tienen teléfonos inteligentes de alto rendimiento que ejecutan sus últimas versiones del sistema operativo. Pueden manejar nuestros sitios. Los análisis nos lo dicen”.

Lamento el argumento del hombre de paja, pero creo que vale la pena decir en voz alta que las personas que pueden usar su sitio serán la mayoría de sus usuarios. Si no ve Android 2.3 en sus análisis, ¿significa que no hay usuarios con esos dispositivos? ¿O significa que su sitio no tiene nada que ofrecer a esos usuarios? Tenga en cuenta que muchos dispositivos de esa generación todavía están en los estantes y se compran nuevos incluso hoy. No debe descartarlo por completo como una tecnología de antaño.

Por lo tanto, me gustaría hablar sobre los casos ideales y los objetivos reales del desarrollo web. Y sobre prácticas y paradigmas que nos acerquen a esos objetivos.

Paradigma de diseño de ladrillo primero

Una parte significativa de las ventas anuales de teléfonos todavía se la llevan los teléfonos básicos. Una porción aún mayor de la población no compra teléfonos todos los años, pero sin embargo tiene algún dispositivo con capacidad web en su poder. Agregue a esos números los teléfonos inteligentes de última generación que todavía están en uso, agregue los Kindle y otros dispositivos con capacidad parcial para la web (dispositivos WAP, televisores, tostadoras, camisetas y ladrillos). Súmalos todos y podrías llegar a una suma asombrosa.

Considere los casos de uso para esta audiencia. No van a leer artículos extensos, navegar e investigar en sus dispositivos. Pero pueden pasar por los horrores de tratar de escribir una URL en el teclado numérico y navegar por la página usando las teclas direccionales para llegar a un número de teléfono o verificar una dirección sobre la marcha.

Entonces, ¿qué tan difícil es para nosotros implementar un diseño sub-móvil primero que proporcione solo esa información a los dispositivos por debajo de un cierto umbral de capacidades y rendimiento?

Mejora elegante

Con la degradación elegante como práctica recomendada mínima, hemos creado un principio general que (hasta cierto punto) obstruye el pensamiento más allá. Una vez que la degradación elegante esté en su lugar, seguramente podemos decir que nuestro trabajo está hecho y bien hecho. Cada vez más, ni siquiera tenemos que pensar en ello, ya que está cubierto por los diversos marcos y bibliotecas en uso. Y finalmente, los polyfills y shims eliminan por completo la necesidad de degradación de la funcionalidad en algunos casos.

A medida que esta funcionalidad se vuelve cada vez más disponible, la necesidad de pensar en ella (y mucho menos más allá) se vuelve cada vez más remota.

Desde el punto de vista de este artículo podría desglosarse así:

Degradación sin gracia: si una característica no está fácilmente disponible, la implementación falla de tal manera que se vuelve inutilizable o utilizable de una manera prohibitivamente poco práctica.

Degradación elegante: si una característica no está fácilmente disponible, falla de una manera que aún permite una usabilidad aceptable.

Mejora poco elegante: si la característica no está disponible fácilmente, se emula mediante un relleno de polietileno o una cuña.

Ahí, problema resuelto.

Bueno, a menos que considere el rendimiento de esos mismos dispositivos de gama baja.

Al carecer del poder de procesamiento y las capacidades de datos de sus hermanos menores, se les pide que lleven una carga mucho mayor. Tomar polyfills como una solución crea la ilusión de que todas las funcionalidades modernas ahora están disponibles en todos los dispositivos y se pueden usar sin preocupaciones.

Y entonces implementas modernizr y polyfill todo por si acaso. El dispositivo menos competente termina cargando la mayor cantidad de datos y realizando la mayor cantidad de procesamiento. Garantizando así la "mejor" experiencia del usuario final.

La idea de una mejora elegante revertiría el concepto comenzando con los requisitos de características más bajos y cargando actualizaciones hasta que el equilibrio entre rendimiento y usabilidad sea óptimo en función de las capacidades del dispositivo. Así, los requisitos de procesamiento y tráfico de datos se trasladarían a los dispositivos más adecuados para manejarlos.

Claro, en este momento el concepto es prohibitivamente complejo: no es compatible con la mayoría de los marcos y bibliotecas, en su mayoría no se discute, y las referencias a tales prácticas son pocas, muy alejadas y localizadas en micro-funcionalidades. Pero en algún momento fue así con todos los conceptos y funcionalidades.

Puede, pero ¿tiene que hacerlo?

Otra práctica recomendada con el desarrollo web es verificar si una función está disponible en un dispositivo antes de activarla.

Sin embargo, tenga en cuenta que puede instalar la última versión de Google Chrome en su teléfono Android de años, y afirmará que puede ejecutar animaciones CSS, WebGL, efectos de paralaje de fondo y muchas otras funcionalidades. Pero realmente, realmente , no puede. Tanto es así que el navegador se bloqueará y todo el dispositivo dejará de responder hasta el punto de que tendrá que reiniciarse para recuperar el control.

Este problema últimamente ha comenzado a afectar a las aplicaciones de Android en gran medida (desde el punto de vista del usuario). Una de las degradaciones más notables en este sentido ha afectado la actualización de la aplicación Google Talk/Hangouts que ha convertido su servicio de la aplicación de chat más liviana disponible en una aplicación casi inutilizable debido a problemas de rendimiento en dispositivos más antiguos. (Solo para enfatizar este punto una vez más: "más antiguo" aquí significa que aún puede comprarlo listo para usar, nuevo en casi cualquier tienda). El mismo problema afectó a la aplicación de YouTube y la aplicación de Twitter (según mi experiencia) y aparentemente a muchas otras.

Por lo tanto, tómese un momento en algún momento durante su fase de planificación para evaluar el valor de una característica principal de alto rendimiento sobre el maquillaje de vanguardia. O al menos deje la última generación de su aplicación/servicio/contenido disponible de alguna forma para los usuarios heredados. Hablando de que…

Deje que los usuarios opten por no participar en Bleeding Edge

¿Alguna vez te has encontrado tratando de usar Gmail desde un dispositivo antiguo o con una conexión deficiente? Ese enlace "cargar HTML básico" seguro que es útil.

¿Por qué su escaparate en línea innovador, receptivo, animado y táctil no tiene esa funcionalidad?

Piénselo: solicitó que sea receptivo para que pueda llegar a más clientes potenciales. Lo hizo de vanguardia para dejar la mejor primera impresión. Y como resultado, menos clientes potenciales pueden llegar incluso a la información básica sobre usted y sus servicios. Si la mejora elegante es un concepto demasiado costoso para usted, ¿por qué no ofrece al menos a sus visitantes la opción de acceder a una versión de solo texto de su contenido si la versión "WOW" es demasiado para sus dispositivos?

¿Realmente necesita toda la biblioteca?

Por último, la última mejor práctica que me gustaría ver empujada un poco más allá del estándar es "úsalo o piérdelo". Hacer un seguimiento de qué bibliotecas y módulos están realmente en uso e incluirlos solo a veces es tedioso, pero mantener todo su conjunto de herramientas en cada página es simplemente descuidado.

Recientemente, me he puesto a hacer un seguimiento de la cantidad de funciones que realmente uso una vez que incluyo una biblioteca. Y la herramienta que uso con más frecuencia es jQuery. A menudo encuentro que he usado solo una o dos funcionalidades (como $.extend o $.ready), o peor aún, que lo he usado solo para obtener elementos por clase o ID. A veces lo dejo así, otras veces reviso el código para eliminar o desacoplar la dependencia.

¿No sería genial si pudiera analizar automáticamente qué y cuánto de una biblioteca ha terminado usándose y perdiendo peso en función de los resultados?

Muchas bibliotecas y aplicaciones ofrecen la opción de personalizar la carga antes de comenzar a usarla. Pero sigo teniendo la sensación de que no debería estar demasiado lejos de nuestro alcance estandarizar una arquitectura de compilación automatizada de "úsalo o piérdelo" en nuestras bibliotecas.

Soy alérgico al enfoque de "incluir todo". Pero usarlo junto con dicha funcionalidad podría convertir el enfoque en algo similar a una placa de creación de prototipos: una herramienta de desarrollo demasiado flexible que se minimiza no solo en la sintaxis, sino también en la funcionalidad real.

Lo que se requeriría es una versión solo de desarrollo de la biblioteca que, a través de una prueba unitaria de la funcionalidad dependiente, permitiría rastrear las funciones utilizadas y generar la dependencia mínima o al menos la escala de utilización (como preguntar si incluí jQuery por 8% de su funcionalidad o el 80%). La salida de dependencia podría usarse para seleccionar, agregar y minimizar la salida para la producción.

Pero, ¿qué puedo hacer al respecto?

En primer lugar, abordar el problema . Piénselo, discútalo con sus compañeros e intente detectar el problema en escenarios del mundo real.

Pruébalo. Busca ese teléfono de última generación que has escondido en un cajón en alguna parte. Intente usarlo en sus propios sitios web y verifique si el contenido se puede usar incluso de forma remota. Visite a algunos parientes atrasados ​​en el campo e intente ser un evangelista tecnológico para ellos. Vea si su retraso en la adopción de tecnología realmente se ve facilitado por problemas de accesibilidad.

Si usted es un comprador que está poniendo en marcha un sitio web, asegúrese de solicitar (al menos) un soporte de bajo nivel sobre este tema. Recuerde: el objetivo no es crear un puerto completo de todas sus funciones para dispositivos de bajo nivel. Todo lo que se pide es que esos usuarios obtengan su información de contacto en lugar de que su dispositivo se bloquee.

Reserve recursos reales para esto: la solución más simple para el problema no debería tomar más de uno o dos días y un poco de visión de futuro. Tenga en cuenta las razones más básicas para hacer el sitio web en primer lugar (y mucho menos hacer un sitio receptivo).

Si es un desarrollador de paquetes que trabaja en una biblioteca, marco, paquete o cualquier otro software integrable: usted es quien puede marcar la diferencia aquí. Si puede facilitar o incorporar estos conceptos en su plataforma, estará afectando todo el panorama del desarrollo web. Si lo incorpora en el diseño de su paquete, hágamelo saber y evangelizaré por usted.

Y, por último, **si es desarrollador o diseñador**, no se limite a las mejores prácticas. Trate siempre de mirar un poco más allá de ese horizonte. El trabajo duro está en ti para impulsar estos conceptos que nadie ha pedido todavía, que no están respaldados ni documentados en beneficio de tus clientes y usuarios.

En última instancia, si quieres escuchar a alguien hablando de esto durante horas y te encuentras cerca de Zagreb, házmelo saber. Podríamos ir a tomar una taza de café.