Un Tamaño Que Queda A Pocos: Una Guía Para Soluciones de Imágenes Responsive En Diseño Web

Mientras que los dispositivos mobile y tablet se acercan a finalmente conseguir la dominación del mundo, la tecnología web está en carrera para acomodar los números que no paran de crecer en cuanto a tamaño de pantalla se refiere. Sin embargo, idear herramientas para poder estar a la par de este fenómeno nos trae una nueva cantidad de problemas, con una de las últimas palabras en emerger: “web responsive”. Este es el desafío de hacer que la web funcione en la gran mayoría, sino en todos, los dispositivos sin bajar la calidad de la experiencia de usuario. En vez de diseñar contenido que entre en una computadora de escritorio o laptop, la información tiene que estar disponible para teléfonos móviles, tablets o cualquier superficie conectada con la web. Sin embargo, esta evolución del diseño web responsive ha probado ser difícil y a veces, dolorosa.

Mientras que puede ser casi trivial acomodar información textual, la parte complicada aparece cuando ponemos en consideración contenido como imágenes responsivas, infografías, videos, y demás, lo cual una vez fue diseñado con las computadoras de escritorio en mente. Esto no sólo da lugar a la pregunta de poder mostrar el contenido correctamente, pero también cómo el contenido propiamente dicho es consumido utilizando diferentes dispositivos. Los usuarios en smartphones son diferentes de los usuarios que utilizan computadoras de escritorio. Cosas como planes de datos y velocidad de procesamiento son cosas para tener en cuenta. Google ha comenzado a resaltar sitios que sean amigables para los dispositivos mobile en los resultados de búsqueda, con algunos especulando si eso llevará al alza substancial en los rangos de estos sitios. Soluciones anteriores ponían foco en esto al lanzar subdominios que fueran sólo mobile (y redireccionados) pero esto incrementaba la complejidad y pasaba de moda rápidamente. (No todos los sitios tienen la habilidad de costear esta ruta).

En La Búsqueda De Imágenes Responsive Para La Web

En este punto, los desarrolladores y diseñadores pueden asegurarse que la carga de su sitio web esté optimizada para los usuarios que estén en sitios mobile. Más del 20% del tráfico web proviene ahora de usuarios mobile, y el número está creciendo. Con imágenes tomando entre las más grandes porciones de contenido de datos, se ha convertido una prioridad el ajustar su tamaño, incluyendo el lado del servidor y soluciones de front-end. Para discutir estas soluciones de solución de ajuste de tamaño, necesitamos primero entender los defectos actuales de vincular imágenes.

La etiqueta <img> sólo tiene el atributo fuente enlazado directamente a la imagen en sí. No tiene forma de determinar el tipo correcto de imagen necesaria sin ningún agregado.

¿No podemos poner todos los tamaños de imágenes incluídos en el HTML, y usar reglas de CSS para poner display:none para todo menos la imagen correcta? Esa es la solución más lógica en un perfecto mundo lógico. Pero de esta forma los navegadores pueden ignorar todas las imágenes no expuestas y, en teoría, no descargarlas. Sin embargo, los navegadores están optimizados más allá de la lógica común. Para hacer que la página se renderice lo más rápido posible, el navegador trae de antemano contenido enlazado, incluso antes de que hojas de estilo y archivos de JavaScript hayan cargado completamente. En vez de ignorar las imágenes grandes pensadas para desktop, terminamos descargando todas las imágenes, resultando en una página mucho más grande de cargar. La técnica de sólo CSS sólo funciona para imágenes que se han pensado como fondos porque estas se pueden fijar en las hojas de estilo (usando media queries).

Entonces, ¿qué debe hacer un sitio web?

Soluciones de Back-End Para La Escalabilidad de Imágenes

Salvo sitios mobile-only/sub-dominios, nos quedamos olfateando el user-agent (UA) y lo utilizamos para servir el tamaño correcto de las imágenes al usuario. Sin embargo, cualquier desarrollador puede testificar qué tan poco fiable esta solución puede ser. Nuevos hilos de UA aparecen todo el tiempo, haciéndolo extenuante el mantener y actualizar una lista comprehensiva. Y por supuesto, esto ni siquiera toma en cuenta lo poco fiable y qué tan fácil de burlar son los hilos de UA para empezar.

Imágenes Adaptables

Sin embargo, algunas soluciones secundarias de servidores son dignas de ser consideradas. Imágenes Adaptables es una gran solución para esos arreglos de imágenes responsive preferentes de back-end. No requiere algun markup especial pero por otro lado, utiliza un archivo pequeño de JavaScript y hace la mayor parte del trabajo pesado en su archivo de back-end. Utiliza PHP y un servidor configurado nginx. Tampoco no depende en ningún rastreo de UA, y en su lugar revisa lo ancho de la pantalla. Las Imágenes Adaptables funcionan bien para escalar imágenes, pero también son útiles cuando grandes imágenes necesitan dirección de arte, por ejemplo, reducción de imágen por técnicas como corte y rotación, no sólamente escalar.

Toque Sencha

Sencha Touch es otra solución de back-end para las imágenes de diseño responsive, aunque es mejor referirnos a ella como una solución tercerizada. Sencha Touch modificará el tamaño de la imagen acorde al rastrear el UA. Debajo, un ejemplo básico de cómo este servicio funciona:

<img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="Mi Gatito">

También está la opción de especificar tamaños, en caso de que no querramos que Sencha modifique su tamaño de forma automática. Al final del día, soluciones secundarias de servidor (y tercerizadas) requerirán recursos para procesar la solicitud antes de enviar la imágen correcta de vuelta. Esto requiere un preciado tiempo y de esta forma desacelera el viaje de solicitud-respuesta. Una mejor solución podría ser si el dispositivo en sí determinase a cuál recurso requerir directamente, y el servidor respondiera de forma correcta.

Soluciones De Front-End

En tiempos recientes, han habido grandes mejoras en el lado del navegador para responder a los problemas con las imágenes responsive.

El elemento <imagen> ha sido introducido y aprobado en las especificaciones de HTML5 por el W3C. Actualmente no está disponible en todos los navegadores pero no pasará mucho antes de que esto suceda. Hasta ese entonces, nos apoyamos en los polyfills de Javascript para el elemento. Los Polyfills también son una gran solución para navegadores heredados que carecen de este elemento.

También está el caso del atributosrcset attribute el cual está disponible para varios WebKit basados en navegadores para el elemento <img>. Esto puede ser utilizado sin nada de JavaScript y es una gran solución si navegadores que no tengan webKit son ignorados. Es un buen recurso temporal para el extraño caso donde otras soluciones no son suficientes, pero no debería ser considerada una solución comprehensiva.

Picturefill

Picturefill es una librería polyfill para el elemento <picture>. Es una de las librerías más populares en el montón de soluciones front-end para la escalabilidad de imágenes y problemas relacionados. Hay dos versiones; Picturefill v1 imita el elemento <picture> utilizando span mientras que Picturefill v2 utiliza el elemento <picture> entre los navegadores que ya lo poseen y provee polyfill para los heredados, (por ejemplo, para IE >=IE9). Tiene algunas limitaciones y interferencias, más notablemente para Android 2.3 - el cual incidentalmente es un ejemplo de cómo el atributo img srcset viene al rescate. A continuación, una muestra del markup por usar Picturefill v2:

<picture>
  <source srcset="/images/kitty_large.jpg" media="(min-width: 768px)">
  <source srcset="/images/kitty_medium.jpg" media="(max-width: 767px)">
  <img srcset="/images/kitty_small.jpg" alt="My Kitty Cat">
</picture>

Para mejorar el rendimiento en los usuarios con planes de datos limitados, Picturefill puede ser combinado con la carga perezosa. Sin embargo, la librería podría ofrecer un soporte más amplio para el navegador y encargarse de casos extraños en vez de apoyarse en parches.

Imager.js

Imager.js es una librería creada por el equipo de BBC News para logar que las imágenes responsive tuvieran un acercamiento diferente del que se usa en Picturefill. Mientras que intenta traer el elemento <picture> a navegadores sin soporte, Imager.js se concentra en descargar sólo las imágenes apropiadas mientras se fija en las velocidades de las redes. También incorpora la carga perezosa sin apoyarse en librerías tercerizadas. Funciona al poner elementos de placeholder y reemplazarlos con elementos <img>. El código muestra debajo exhibe este comportambiento:

<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 renderiazado 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 de los navegadores es mucho mejor que el de Picturefill con el costo de ser una solución más pragmática que una progresiva.

Source Shuffling

Source Shuffling se acerca a este problema desde un ángulo ligeramente diferente que del resto de las librerías front-end. Se parece a algo salido del pensamiento de la escuela “mobile first”, donde sirve a la resolución más pequeña posible por default. Al detectar qué dispositivo tiene la pantalla más grande, cambia la fuente de la imagen por una más grande. Se siente más como un hack y menos como una librería completamente crecida. Esta es una gran solución principalmente para sitios mobile pero significa que la descarga doble de recursos para desktops y/o tablets es inevitable.

Otras librerías notables de JavaScript son:

• HiSRC - Un plugin jQuery para imágenes responsive. Depender de jQuery puede ser un problema.

• Mobify.js - Una librería general para contenido responsive, incluyendo imágenes, hojas de estilo e incluso JavaScript. ‘Captura’ el dOM antes que el recurso cargue. Mobify es una poderosa y comprehensiva librería, pero puede ser un exceso si la meta es sólo tener imágenes responsive.

En Resumen

Al final del día, depende del desarrollador decidir qué aproximación usar en el diseño web responsive de imágenes para su base de usuarios. Esto significa que la colección de datos y testing darán una mejor idea de qué aproximación usar.

Para ir redondeando, puede ser de utilidad considerar la lista de preguntas que vienen a continuación antes de decidir la solución apropiada para imágenes responsive.

• ¿Los navegadores heredados son un problema? Si no lo son, considera utilizar una aproximación más moderno (por ejemplo, Picturefill, atributo srcset).

• ¿Es el tiempo de respuesta algo crítico? Si no lo es, ve por una solución de back-end o tercerizada.

• ¿Las soluciones deberían ser internas? Las opciones tercerizadas obviamente están descartadas.

• ¿Hay muchas imágenes en el sitio que intentan transicionar a imágenes responsive? ¿Hay preocupaciones sobre la validación o etiquetas semánticas (o etiquetas no-semánticas)? Esto requerirá una solución de back-end para guiar las solicitudes de imágenes a algo como Imágenes Adaptables.

• ¿La dirección de arte es un problema (específicamente para imágenes grandes con mucha información)? Una librería como Picturefill podría ser una mejor solución para un escenario así. Además, cualquiera de las soluciones de back-end podrían funcionar también.

• ¿Hay alguna preocupación por JavaScript? Cualquier solución de front-end estará fuera de discusión, lo cual deja opciones como back-end o tercerizados que se apoyen en rastreo de UA.

• ¿Hay alguna prioridad para tiempos de respuesta de mobile vs tiempos de respuesta de desktop? Una librería como Source Shuffling debería ser la más apropiada para ese caso.

• ¿Hay alguna necesidad de proveer una conducta responsiva a cada aspecto del sitio, no sólo las imágenes? Mobify podría funcionar mejor.

• ¿Se ha logrado alcanzar al mundo perfecto? ¡Entonces utiliza sólo aproximación de CSS display:none!