Talla única para algunos: una guía para soluciones de imagen de diseño web receptivo

A medida que los dispositivos móviles y las tabletas se acercan a lograr la dominación mundial final, el diseño web y la tecnología están en una carrera para adaptarse al número cada vez mayor de tamaños de pantalla. Sin embargo, el diseño de herramientas para enfrentar los desafíos de este fenómeno trae consigo un conjunto completamente nuevo de problemas, y una de las últimas palabras de moda que ha surgido es "web receptiva". Este es el desafío de hacer que la web funcione en la mayoría de los dispositivos, si no en todos, sin degradar la experiencia del usuario. En lugar de diseñar contenido para computadoras de escritorio o portátiles, la información debe estar disponible para teléfonos móviles, tabletas o cualquier superficie conectada a la web. Sin embargo, esta evolución del diseño web receptivo ha demostrado ser difícil y, a veces, dolorosa.

Si bien puede ser casi trivial acomodar información textual, la parte complicada surge cuando consideramos contenido como imágenes receptivas, infografías, videos, etc., que alguna vez fueron diseñados pensando solo en escritorios. Esto no solo plantea la cuestión de mostrar el contenido correctamente, sino también cómo se consume el contenido en sí mismo utilizando diferentes dispositivos. Los usuarios de teléfonos inteligentes son diferentes a los usuarios de computadoras de escritorio. También se deben considerar cosas como los planes de datos y la velocidad de procesamiento. Google ha comenzado a destacar los sitios optimizados para dispositivos móviles en sus resultados de búsqueda, y algunos especulan que conducirá a un aumento sustancial en el ranking de páginas de dichos sitios. Las soluciones anteriores abordaron este problema mediante la implementación de subdominios (y redireccionamientos) solo para dispositivos móviles, pero esto aumentó la complejidad y pasó de moda rápidamente. (No todos los sitios tienen la capacidad de pagar esta ruta).

En la búsqueda de imágenes web receptivas

En este punto, los desarrolladores y diseñadores deben asegurarse de que la carga de su sitio web esté optimizada para satisfacer a los usuarios que se encuentran en sitios móviles. Más del 20% del tráfico web ahora son usuarios móviles, y el número sigue aumentando. Dado que las imágenes ocupan la mayor parte de los datos de contenido de la página, se convierte en una prioridad reducir esta carga. Se han realizado varios intentos para simplificar el cambio de tamaño de la imagen del diseño receptivo, incluidas las soluciones tanto del lado del servidor como del front-end. Para analizar estas soluciones de imágenes receptivas, primero debemos comprender las deficiencias actuales de vinculación de imágenes.

La etiqueta <img> solo tiene el atributo de origen que se vincula directamente a la imagen en sí. No tiene forma de determinar el tipo correcto de imagen necesaria sin complementos.

¿No podemos simplemente tener todos los tamaños de imagen incluidos en el HTML y usar reglas CSS para display:none para todos excepto la imagen correcta? Esa es la solución más lógica en un mundo lógico perfecto. De esta forma, el navegador puede ignorar todas las imágenes que no se muestran y, en teoría, no descargarlas. Sin embargo, los navegadores están optimizados más allá de la lógica común. Para que la página se muestre lo suficientemente rápido, el navegador obtiene previamente el contenido vinculado incluso antes de que las hojas de estilo y los archivos JavaScript necesarios estén completamente cargados. En lugar de ignorar las imágenes grandes destinadas a los escritorios, terminamos descargando todas las imágenes y resultando en una carga de página aún mayor. La técnica de solo CSS solo funciona para imágenes destinadas a ser imágenes de fondo porque se pueden configurar dentro de la hoja de estilo (mediante consultas de medios).

Entonces, ¿qué debe hacer un sitio web?

Soluciones de escalado de imágenes receptivas de back-end

A excepción de los sitios/subdominios solo para dispositivos móviles, nos quedamos con el rastreo del agente de usuario (UA) y su uso para devolver las imágenes del tamaño correcto al usuario. Sin embargo, cualquier desarrollador puede dar fe de lo poco fiable que puede ser esta solución. Las nuevas cadenas de UA siguen apareciendo todo el tiempo, lo que hace que sea agotador mantener y actualizar una lista completa. Y, por supuesto, esto ni siquiera tiene en cuenta la falta de fiabilidad de las cadenas de UA fáciles de falsificar en primer lugar.

Imágenes adaptables

Sin embargo, algunas soluciones del lado del servidor son dignas de consideración. Adaptive Images es una excelente solución para aquellos que prefieren una solución de imagen receptiva de back-end. No requiere ningún marcado especial, sino que utiliza un pequeño archivo JavaScript y realiza la mayor parte del trabajo pesado en su archivo de fondo. Utiliza un servidor configurado con PHP y nginx. Tampoco se basa en ningún rastreo de UA, sino que comprueba el ancho de la pantalla. Adaptive Images funciona muy bien para reducir la escala de las imágenes, pero también es útil cuando las imágenes grandes necesitan dirección artística, es decir, la reducción de la imagen mediante técnicas como el recorte y la rotación, no solo la escala.

Toque Sencha

Sencha Touch es otra solución de imagen de diseño receptivo de back-end, aunque es mejor referirse a ella como una solución de terceros. Sencha Touch cambiará el tamaño de la imagen en consecuencia olfateando la UA. A continuación se muestra un ejemplo básico de cómo funciona el servicio:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

También hay una opción para especificar los tamaños de imagen, en caso de que no queramos que Sencha cambie el tamaño de la imagen automáticamente.

Al final del día, las soluciones del lado del servidor (y de terceros) requieren recursos para procesar la solicitud antes de devolver la imagen correcta. Esto lleva un tiempo precioso y, a su vez, ralentiza el viaje de solicitud-respuesta. Una mejor solución podría ser que el propio dispositivo determinara qué recursos solicitar directamente y que el servidor respondiera en consecuencia.

Soluciones Front-End

En los últimos tiempos, ha habido grandes mejoras en el lado del navegador para abordar las imágenes receptivas.

El elemento <picture> ha sido introducido y aprobado en la especificación HTML5 por el W3C. Actualmente no está ampliamente disponible en todos los navegadores, pero no pasará mucho tiempo antes de que esté disponible de forma nativa. Hasta entonces, dependemos de los polyfills de JavaScript para el elemento. Polyfills también es una gran solución para los navegadores heredados que carecen del elemento.

También está el caso del atributo srcset que está disponible para varios navegadores basados ​​en webKit para el elemento <img> . Esto se puede usar sin JavaScript y es una excelente solución si se ignoran los navegadores que no son webKit. Es un recurso provisional útil para el caso extraño en el que otras soluciones se quedan cortas, pero no debe considerarse una solución integral.

Relleno de imagen

Picturefill es una biblioteca de polyfill para el elemento <picture> . Es una de las bibliotecas más populares entre las soluciones front-end para problemas de tamaño y escalado de imágenes sensibles. Hay dos versiones; Picturefill v1 imita el elemento <picture> usando span mientras que Picturefill v2 usa el elemento <picture> entre los navegadores que ya lo ofrecen y proporciona un polyfill para los heredados (por ejemplo, para IE >= IE9). Tiene algunas limitaciones y soluciones, sobre todo para Android 2.3, que por cierto es un ejemplo de dónde viene el atributo img srcset al rescate. A continuación se muestra un marcado de muestra para usar Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

Para mejorar el rendimiento de los usuarios con planes de datos limitados, Picturefill se puede combinar con la carga diferida. Sin embargo, la biblioteca podría ofrecer un soporte de navegador más amplio y abordar los casos extraños en lugar de depender de los parches.

Imager.js

Imager.js es una biblioteca creada por el equipo de BBC News para lograr imágenes receptivas con un enfoque diferente al utilizado por Picturefill. Mientras que Picturefill intenta llevar el elemento <picture> a los navegadores no compatibles, Imager.js se enfoca en descargar solo las imágenes apropiadas mientras también está atento a las velocidades de la red. También incorpora carga diferida sin depender de bibliotecas de terceros. Funciona usando elementos de marcador de posición y reemplazándolos con elementos <img> . El siguiente código de ejemplo muestra este comportamiento:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

El HTML renderizado se verá así:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

El soporte del navegador es mucho mejor que el de Picturefill a expensas de ser una solución más pragmática que una con visión de futuro.

Mezcla de fuentes

Source Shuffling aborda el problema de la imagen receptiva desde un ángulo ligeramente diferente al del resto de las bibliotecas front-end. Se asemeja a algo fuera de la escuela de pensamiento de "móvil primero", por lo que ofrece la resolución más pequeña posible de forma predeterminada. Al detectar que un dispositivo tiene una pantalla más grande, cambia la fuente de la imagen por una imagen más grande. Se siente más como un truco y menos como una biblioteca completa. Esta es una gran solución principalmente para sitios móviles, pero significa que la descarga doble de recursos para computadoras de escritorio y/o tabletas es inevitable.

Algunas otras bibliotecas de JavaScript notables son:

• HiSRC: un complemento de jQuery para imágenes receptivas. La dependencia de jQuery podría ser un problema.
• Mobify.js: una biblioteca más general para contenido receptivo, que incluye imágenes, hojas de estilo e incluso JavaScript. 'Captura' el DOM antes de la carga de recursos. Mobify es una biblioteca poderosa y completa, pero puede ser excesivo si el objetivo son solo imágenes receptivas.

Resumen

Al final del día, depende del desarrollador decidir qué enfoque de imagen de diseño web receptivo se adapta a la base de usuarios. Esto significa que la recopilación de datos y las pruebas darán una mejor idea del enfoque a seguir.

Para concluir, la lista de preguntas a continuación puede ser útil para considerar antes de decidir la solución de imagen receptiva adecuada.

• ¿Son los navegadores heredados un problema? Si no, considere usar un enfoque más moderno (por ejemplo: Picturefill, atributo srcset )
• ¿El tiempo de respuesta es crítico? De lo contrario, busque una solución de terceros o de back-end.
• ¿Se supone que las soluciones son internas? Obviamente, se descartarán las soluciones de terceros.
• ¿Ya hay muchas imágenes en un sitio que está tratando de hacer la transición a imágenes receptivas? ¿Hay preocupaciones sobre la validación o las etiquetas semánticas (o más bien las etiquetas no semánticas)? Esto requerirá una solución de back-end para enrutar las solicitudes de imágenes a algo como Adaptive Images.
• ¿La dirección de arte es un problema (específicamente para imágenes grandes con mucha información)? Una biblioteca como Picturefill será una mejor solución para tal escenario. Además, cualquiera de las soluciones de back-end también funcionará.
• ¿Hay alguna preocupación por la falta de JavaScript? Cualquiera de las soluciones de front-end estará fuera de discusión, lo que deja las opciones de back-end o de terceros que dependen de la detección de UA.
• ¿Existe una prioridad para los tiempos de respuesta móviles sobre los tiempos de respuesta de escritorio? Una biblioteca como Source Shuffling puede ser más apropiada.
• ¿Existe la necesidad de proporcionar un comportamiento receptivo a todos los aspectos del sitio, no solo a las imágenes? Mobify.js podría funcionar mejor.
• ¿Se ha logrado el mundo perfecto? ¡Utilice el enfoque display:none de solo CSS!