Vanguardia

Cómo gestionar de manera eficaz las imágenes en sitios web dinámicos

Dino Esposito

El llamado Diseño web dinámico adaptable (Responsive Web Design o RWD en sus siglas inglesas), o cómo crear una experiencia web única a través de un diseño web fluido y adaptable es, sin duda, uno de esos hitos que cambiarán el fluir de las cosas en el mundo real.

Como desarrollador web debe estar dispuesto a asumir que todo hecho, por inamovible que parezca, siempre contará con una excepción. Es decir, por un lado el RWD es un estándar ya establecido y que se está convirtiendo en algo indispensable para todos los sitios web pero, por otro lado, el RWD resulta ser una metodología incompleta, con sus procedimientos recomendados aún sin concretar de forma definitiva. En este artículo echaremos un rápido vistazo al estado del RWD, centrándonos sobre todo en sus aspectos más críticos: su rendimiento en general y, en particular, la manipulación de imágenes.

Rendimiento del RWD

El propósito principal del RWD es hacer que el contenido que se va a utilizar en los dispositivos sea sencillo y ameno, sin tener en cuenta su tamaño o forma. Por ahora, todo claro. Pero, ¿cómo conseguimos esto?

El RWD aborda de una forma bastante diferente el desarrollo de los proyectos y su aprobación. El punto de control visual convencional que se establece cuando sus clientes ven bocetos estáticos y le dan su aprobación, es un paso que no está demasiado definido. En vez de presentar bocetos estáticos, tal vez prefiera utilizar un wireframe. En general, un sitio dinámico es algo que resulta fácil de vender a sus clientes, pero es un verdadero reto explicarles por qué esta opción les resulta más cara que tener un sitio clásico y no dinámico.

Unos cuantos años de experiencia han sido de ayuda para consolidar unas pocas prácticas y frameworks como Twitter Bootstrap que han surgido para favorecer la implementación de los sitios dinámicos. Pero, ¿qué ocurre con el rendimiento?

El rendimiento resulta ser actualmente el punto débil del RWD. Un sitio dinámico funciona perfectamente en un explorador de escritorio que sea potente. En cambio, su rendimiento tiende a disminuir si se utiliza en dispositivos más pequeños como los smartphones. El RWD no tiene la misma efectividad en cualquier tipo de sitio web. Por ejemplo, es más fácil modificar el tamaño de un portal de noticias y vídeos para adaptar su contenido a pantallas más pequeñas, que modificar el tamaño de un sitio como una web de reservas de viajes, que tiene numerosos formularios y es interactiva. En este último caso, el tamaño de la pantalla es un factor de mayor importancia.

La pregunta clave que ha de hacérsele a un cliente potencial antes de comenzar a implementar un RWD, es hasta qué punto está interesado en promocionar su negocio a través de las capacidades de los diversos dispositivos. Si un negocio utiliza varios dispositivos para hacer búsquedas o comprar productos o servicios, entonces no puede limitarse a diferenciar el contenido basándose en el ancho y la orientación de una pantalla convencional. Es decir, un explorador de escritorio redimensionado y un smartphone pueden mostrar contenido utilizando el mismo diseño, pero ambos utilizan un hardware diferente y tienen amplias diferencias en cuanto a capacidades informáticas. Si al negocio en cuestión le interesa el tema de utilizar dispositivos diversos, habrá que tener en cuenta estas diferencias antes de tomar cualquier decisión.

La metáfora de un único sitio

La metáfora de "un único sitio" forma parte de los cimientos del RWD: solo hay un único conjunto de páginas, una única lógica de back-end, una URL y una sola marca. Hay dos maneras de abordar este tipo de desarrollo RWD para sitios web. Para cada vista y con independencia del dispositivo, deberá utilizar el mismo marcado HTML y crear un puñado de archivos CSS disponibles para el dispositivo. Cada archivo CSS está enlazado a una expresión de consulta de medios que el explorador evalúa en tiempo de ejecución cuando el tamaño de la ventana cambia. El CSS aplicado puede cambiar sobre la marcha, lo que modificará el aspecto del contenido. Este enfoque depende en gran parte de consultas de medios CSS3, un estándar establecido por el consorcio internacional World Wide Web Consortium (W3C) y se define en bit.ly/1oVBf89. A continuación se explica cómo debería definir dos archivos CSS para aplicarlos en dos tamaños de pantalla diferentes:

<link type="text/css"
  rel="stylesheet"
  href="view480.css"
  media="only screen and (max-width: 480px)">
<link type="text/css"
  rel="stylesheet"
  href="view800.css"
  media="only screen and (max-width: 800px)">

La otra opción para desarrollar sitios dinámicos es utilizar las consultas de medios CSS3 con código JavaScript para reajustar de forma adecuada el modelo Document Object Model (DOM). Este enfoque es más potente ya que le proporciona mayor control sobre el diseño. Incluye además la oportunidad de descargar contenido adicional específico para el tamaño de la pantalla. Para detectar cambios en el tamaño de la pantalla, puede usar el evento de cambio de tamaño de ventana o el evento matchMedia. El evento matchMedia es una implementación de JavaScript de consultas de medios. Cuando el explorador detecta un cambio en una consulta de medios especificada, realiza una llamada a su código:

if (window.matchMedia) {
  mq800px = window.matchMedia("(min-width: 800px)"),
  mqPortr = window.matchMedia("(orientation: portrait)");
  mq800px.addListener(mq800px_handler);
  mqPortr.addListener(mqPortr_handler);
}

Si el explorador detecta una orientación vertical o un ancho de 800 píxeles, el código invocará a sus controladores. Puede usar JavaScript y las consultas de medios CSS en el mismo sitio, ya que se aplican a vistas o páginas HTML individuales.

Así pues, el patrón clave de RWD es un conjunto de contenido con múltiples vistas, tanto si lo cambia de forma con CSS como si lo hace con JavaScript ad hoc. Si se decide por CSS, deberá atenerse a lo que este pueda hacer en una página web. Puede mover y cambiar de sitio elementos, puede redistribuir el contenido en contenedores de diferentes tamaños y crear bloques de contenido flotantes bien horizontales o bien verticales. También puede ocultar simplemente el contenido no deseado.

Si decide utilizar JavaScript, podrá hacer todo lo detallado anteriormente y algo más: puede realizar cambios más sofisticados al diseño de vista, crear subárboles DOM a partir de un borrador o descargar contenido desde extremos remotos. Con CSS, el DOM será lo más grande posible. Con JavaScript, solo podrá aumentarlo de tamaño hasta alcanzar el máximo designado.

El tamaño de las soluciones RWD no es un problema cuando estamos visitando sitios en exploradores de escritorio. De hecho, no debería ser un problema en la mayoría de tabletas ya que suelen ser lo suficientemente potentes como para ejecutar cualquier tipo de JavaScript requerido y normalmente se utilizan con una conexión Wi-Fi sólida. El problema aparece al tener sitios RWD para smartphones con conexión 3G. En esos casos, la cantidad de revisión y código JavaScript no tienen demasiado que ver; lo que importan son los eventos relacionados y el impacto de estos en subprocesos que acaban dificultando las cosas. El aspecto del RWD que más quebraderos de cabeza produce, son las imágenes.

Manipulación de imágenes

El antiguo elemento img hace referencia a las imágenes. Estas se descargan por completo y se muestran tal y como especifican los atributos de alto y ancho. Si necesita una imagen de fondo grande para el escritorio o numerosas imágenes para una secuencia, no basta con utilizar CSS para ajustar el ancho y el alto de la imagen. Hacer esto no afectará al tamaño de la descarga. Tampoco le servirá de nada ocultar imágenes con CSS, ya que se descargarán igualmente.

De todos modos, tiene a su disposición varios trucos que puede aplicar cuando esté esperando a que un nuevo elemento HTML esté disponible. Aun así, tenga en cuenta que generalizar un nuevo elemento HTML en exploradores compatibles siempre supone un largo camino a recorrer. Ahora mismo se están realizando algunos experimentos acerca de este tema, pero aun no están completos. Parece ser que, tal y como se muestra a continuación, la dirección nos lleva a un elemento cuya estructura tiene un punto de esa estructura HTML5 de los elementos de vídeo:

<picture>
  <source media="(min-width: 400px)" srcset="foo-sm.jpg, foo-sm-2x.jpg 2x">
  <source media="(min-width: 800px)" srcset="foo-md.jpg, foo-md-2x.jpg 2x">
  <img src="foo.jpg">
</picture>

Cuando utiliza la etiqueta picture en vez de img, proporciona un rango de opciones para la misma imagen lógica. Es decir, proporciona un conjunto de imágenes para cada escenario de consulta de medios y, en cada escenario, deberá proporcionar varias imágenes para aplicarlas a las diferentes densidades de píxeles. En el ejemplo que se muestra, cuando el ancho de la pantalla es de al menos 800 píxeles, el explorador puede elegir una imagen normal que tenga el tamaño adecuado o una copia mayor y hecha a medida para una densidad mayor, o incluso para satisfacer los requisitos del diseño y proporcionar una imagen diferente o una parte de la imagen original cuando una consulta de medios hace su aparición. El elemento img incrustado indica la reserva y su equivalente lógico que están en uso hoy en día. Puede experimentar con este enfoque utilizando un polyfill (un complemento o trozo de código) de JavaScript que encontrará en: bit.ly/1aVEoxb.

Otro enfoque es utilizar la lógica del lado servidor, como un controlador HTTP. El controlador recibirá la solicitud y decidirá qué imagen se descargará. Aunque, francamente, este enfoque puede resultarle un desafío. Esto se debe a que la lógica del lado servidor necesita algunas pistas para poder seleccionar la imagen más adecuada. Estas pistas solo pueden provenir del explorador y deben colocarse en la solicitud HTTP, ya sea con encabezados o una cadena de consultas. Para ello, deberá realizar algo de trabajo de scripting cuando se descarguen las imágenes al cargar la página. Esta opción es factible, pero algo delicada.

Mientras espera a que el elemento de imagen, el tamaño de imagen y otros aspectos de la especificación RWD se estandaricen y estén disponibles para todos los exploradores (ahora mismo, solo Chrome y Opera son compatibles), deténgase un segundo y reflexione exactamente acerca del problema que está tratando de solucionar.

Siempre que el usuario esté en un explorador de escritorio, el tamaño de la imagen no supone un problema. Lo único que tiene que hacer es marcar img en la más grande. Si la ventana del explorador cambia de tamaño, esa misma imagen grande cambia con ella. Llegados a este punto, la imagen ya no supondrá una dificultad para el rendimiento. Pero resulta que quiere cambiar una imagen en ventanas más pequeñas para que se centre en aspectos específicos. En ese caso, un truco que puede probar es hacer referencia a la imagen como fondo de un conjunto de funciones div a través de CSS, en vez de a través de un elemento img estándar. La ventaja que obtendrá de esto es que las consultas de medios seleccionarán únicamente la imagen que usted quiera. También podría tener varias imágenes en el escritorio, pero eso ya es un tema sin importancia. Asimismo, pueden surgir otros problemas con las imágenes de fondo si los usuarios intentan imprimir la página.

Utilizar imágenes de fondo puede ser de gran ayuda cuando el sitio RWD se visualiza en dispositivos móviles, ya que tiene la garantía de que las imágenes se mostrarán en un tamaño adecuado. De todas formas, deberá abordar el tema del uso de imágenes en RWD cuando tenga intención de ver el sitio en otros dispositivos que no sean equipos de escritorio.

¿Cómo puedo detectar qué tipo de dispositivo se está usando? Por supuesto, no tiene por qué rasgarse las vestiduras a la hora de detectar dispositivos. Es cierto que realizar una detección fiable es algo difícil y que puede convertirse en un caos si decide hacerlo usted mismo. Para ello, puede usar el popular complemento Modernizr para algunos tipos de detección de dispositivos del lado cliente (bit.ly/1tfJhtf). De esta manera, puede modificar el DOM mediante programación para que intente conseguir imágenes ad hoc. Este enfoque es razonable, pero no profundiza en el número de dispositivos y puede no ser fiable hasta cierto grado. La detección de dispositivos es algo serio y requiere experiencia.

La herramienta WURFL Image Tailor de un vistazo

Un planteamiento interesante en cuanto a la manipulación de imágenes es el componente Wireless Universal Resource File (archivo de recursos universales móviles o WURFL en sus siglas inglesas) Image Tailor (WIT). Respaldado por el motor WURFL al completo (el mismo motor que Facebook usa para la detección de dispositivos), la herramienta WIT realiza un rápido análisis desde el lado servidor del agente de usuario. Determina el factor de forma del dispositivo solicitante y proporciona una versión redimensionada de la imagen original. WIT es un servicio gratuito que solo necesita una corrección en la URL de la imagen:

<img src="//wit.wurfl.io/[full-url-to-your-image]">

Tiene que adjuntar la URL de imagen completa a la URL del sitio web WIT para poder descargar la imagen desde el sitio web original, redimensionarla y devolver los píxeles al sitio solicitante. Las imágenes se almacenan en caché en el extremo WIT y ello mantiene el número de solicitudes al mínimo. Un puñado de parámetros compatibles le permiten controlar aspectos del cambio de tamaño como el recorte, las dimensiones y el formato que se devuelve.

De todos modos, WIT tiene sus pros y sus contras. Por un lado le evita tener que lidiar con varias versiones de la misma imagen ya que solo necesita una versión ligeramente modificada de la URL en el antiguo y sencillo elemento img. Además, puede comenzar a utilizar WIT en cuestión de segundos.

Y por otro lado, WIT actúa como un proxy y no trata específicamente los escenarios en los que a usted no solo le interesa el tamaño, sino también la densidad de píxeles. En cualquier caso, no hay razón por la que no deba darle una oportunidad. Podrá encontrarlo en wurfl.io/#wit.

El panorama de la manipulación de imágenes dentro del RWD es algo fluido. Por ello está claro que, para asegurar que todo funciona de forma eficiente en todos lados, es necesario lograr cierto nivel de compromiso entre RWD y los dispositivos.

Dino Esposito es el coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) y “Programming ASP.NET MVC 5” (Microsoft Press, 2014). Esposito, evangelizador técnico para las plataformas Android y Microsoft .NET Framework en JetBrains y orador frecuente en eventos del sector en todo el mundo, comparte su visión de software en software2cents.wordpress.com y en Twitter en twitter.com/despos.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Jon Arne Saeteras