¿El diseño distribuido es mejor que el diseño adaptativo?

Hoy en día, todoslos desarrolladores webdeben tener en cuenta cada una de las pantallas que nos rodean:ordenadores de sobremesa, móviles, tabletas, televisores, relojes inteligentes, etc., cadauno consus propias características específicas. Los motores de búsqueda como Google penalizan a los sitios web que noofrecen una experiencia adaptada a los usuarios de dispositivos móviles. Por lo tanto,es imprescindible tener en cuenta todas las pantallas conectadas. 

Aunqueel diseño adaptativo esuna soluciónsencillay rápida para adaptar un sitio web a diferentes formatos de visualización, ¿es realmente la mejor opción? El«diseño distribuido»podría ser unaalternativa seria. Más que una especificación de lenguaje, el diseño distribuido es unaarquitecturaque define la herencia y los recursos utilizados para el dispositivo solicitante. A diferencia de su homólogo, esta solución nose basaen consultas de medios para adaptar la visualización en función de la resolución de la pantalla. En su lugar, se basa enla detección del dispositivo para cargar recursos específicos en él. La idea es sencilla:mismo servicio, misma URL, renderización optimizada. Las ventajas son múltiples: una gestión más precisa del peso de las páginas (los recursos), un mejor rendimiento de visualización, contenido adaptado, menor mantenimiento…

Algunas cifras

El número de dispositivos conectados no deja de crecer, lo que implica una enorme diversidad de entornos que hay que tener en cuenta. En 2015, uno de cada dos usuarios de Internet tenía una tableta, uno de cada tres tenía un televisor inteligente y uno de cada diez tenía un reloj inteligente. Resolución, tamaño, uso: si quieres que tumarcaseavisible, tienes queadaptarte aloshábitos de los usuarios. Es fundamental que una empresa sepa cómo estarpresenteencada medioque represente unmercado potencial.

Veamos un ejemplo de la vida real

El problema

Quieres crear una página web con gran visibilidad, capaz de satisfacer a la mayoría de tus visitantes, independientemente del dispositivo que utilicen, gracias a una visualización adaptada. Puede que ya tengas muchos visitantes o puede que no.

Primer enfoque

Una respuesta obvia sería utilizar consultas de medios CSS para adaptar el estilo de los elementos, ocultar o mostrar bloques, etc. Debo admitir que esa solución funcionará y ofrecerá un resultado relativamente satisfactorio. Sin embargo, si empiezas a pensar en optimizar tus páginas, te encontrarás con problemas como cómo adaptar la resolución de las imágenes al tamaño de la ventana de visualización, cómo eliminar los nodos DOM duplicados, cómo cargar solo los scripts necesarios o cómo limitar el número de solicitudes a tu API.

Por supuesto, hay soluciones para cada uno de estos problemas. Probablemente me dirás que podemos usar «srcset» con un polyfill para adaptar la resolución de las imágenes, utilizar la carga asíncrona de scripts para que se adapten al dispositivo actual, etc. Pero si analizamos cada problema por separado, puede tener repercusiones en otros aspectos, como el rendimiento de ejecución si hay demasiado JavaScript que ejecutar o la lentitud en la carga de las páginas debido a un peso excesivo.

Solución

Aquí llega lo mejordel diseño distribuido. ¿Y si tu servicio pudiera cargar automáticamente una lista de dependencias definidas en función del dispositivo?¿Y si pudierascargar automáticamente solo el código que necesita tu dispositivo? ¿Y si pudierascompartir plantillasentre dispositivos e incluir elementos específicos solo cuando fuera necesario?

Los dispositivos comparten componentes, diseños y fuentes comunes, y también pueden tener características propias

Arquitectura

La arquitectura se basa en tres componentes principales. Cada uno de ellos puede implementarse de forma diferente en función del entorno y los lenguajes de programación utilizados, pero el objetivo siempre será el mismo.

1. Detección de dispositivos

En primer lugar, definequé tipo de dispositivoestá interactuando con tu servicio. El método más habitual consiste en utilizar un filtro basado en el agente de usuario del navegador. Estefiltradopuede realizarse enel servidor de cachéHTTP,en el servidor HTTP o en tu aplicación. Por razones obvias de rendimiento, cuanto antes se realice este filtrado en el flujo de la solicitud, mejor.

Si aún así prefieres hacerlo directamente en tu aplicación, quizá debido a las limitaciones de tu entorno, existen numerosos paquetes de código abierto que te permiten evitar la tediosa tarea de escribir reglas que abarquen todos los dispositivos imaginables (MobileDetectBundle, Spring Device Detection, etc.).

Sin embargo, si eres de los que les gusta la aventura y aún así quieres o necesitas crear tus propias reglas de filtrado, hay muchas fuentes gratuitas que recogen la enorme cantidad de agentes de usuario de navegadores existentes. Una buena fuente:https://udger.com/resources/ua-list/devices.

Ten en cuenta que el filtrado de dispositivos debe realizarse una sola vez por solicitud y que el resultado debe estar disponible en toda la aplicación.

2. Herencia de plantillas

Ahora que ya sabes cómo detectar el dispositivo que realiza la solicitud, debesproporcionarle la imagen adecuada.Debes disponer de una estructura de directorios que organice las plantillas por dispositivo y de una carpeta común para las plantillas compartidas.

La idea es implementar un servicio quecargue automáticamenteuna plantilla adaptadaal contexto en función de su nombre. El servicio debe cumplir las siguientes reglas:

• si la ruta de la plantilla requerida es relativa, comprueba si la plantilla existe en la carpeta del dispositivo detectado y cárgala; de lo contrario, comprueba si existe en la carpeta común y cárgala
• si la ruta de la plantilla requerida es absoluta, cárgala directamente (se utiliza para forzar la carga de una versión específica)

Con estas reglas podrás combinar piezas comunes con piezas específicas de cada dispositivo.

Otra ventaja es que puedes anular en cualquier momento una parte de tu diseño simplemente creando una plantilla en la carpeta del dispositivo en cuestión. Por ejemplo, si tienes un bloque de barra lateral común para ordenador y tableta y decides utilizar una vista diferente para la tableta, solo tienes que crear una nueva copia de tu plantilla en la carpeta de la tableta y se cargará automáticamente.

Si organizas tus plantillas de esta manera, te resultará más fácil crear, modificar y mantener tus diseños. Además, la incorporación de un nuevo dispositivo compatible será mucho más rápida.

3. Agrupación y entrega de recursos

Un último punto crucial esorganizar los recursospara cada dispositivo de tal manera que solo se sirvan aquellos que necesite el dispositivo solicitante. Ya existen muchas herramientas dedicadas a la concatenación y la minificación. Con la llegada de Node.js y su ecosistema de paquetes, como Grunt o Gulp, el proceso de minificación se está convirtiendo en una tarea habitual. Pero para el diseño distribuido, tendrás que llevar la lógica un poco más allá y dividir recursos como JS y CSS en carpetas distintas.

Como ya se ha mencionado en el caso de las plantillas,los recursos deben dividirse en carpetas con el nombre de cada dispositivo y en una carpeta común. De esta forma, podemos crear listas de recursos para cada dispositivo y generar un paquete de recursos final para su entrega.

Siguiendo este proceso, podemos generar, por ejemplo, estos paquetes:

Las ventajasde este proceso son unamejor gestión del peso de las páginas yun mejor rendimiento de carga. Además,garantiza una reducción del riesgo de conflictos entre estilos o bibliotecas.

En definitiva, el diseño distribuidonosustituye al diseño adaptativo. Se tratamás bien de unaarquitectura quelleva el diseño adaptativo un paso más allá. Podría facilitar el mantenimiento, mejorar la visualización y la entrega general de las páginas, y ofrecer una forma más flexible de gestionar el contenido específico para cada dispositivo. Gracias a que se pueden reutilizar las plantillas, estilos, scripts y herramientas creados anteriormente, la migración a este tipo de arquitectura podría serrealmente rápida. Se trata de una solución que toda empresa debería tener en cuenta cuando le preocupanel rendimientoyel contenido adaptativo.