En el pasado artículo explicamos muchos de los motivos por los que el diseño "Responsive" debe ser un diseño optimizado, preparado para la navegación desde escritorio, pero también desde el "contexto móvil" con sus características. Todo ello bajo el prisma de las "webs obesas", lo que desafortunadamente es una problemática habitual cuando los diseñadores implementan webs que adaptan a dispositivos.

En el pasado artículo repasamos con detalle los porqués, de modo que ahora nos vamos a dedicar a los cómos.

Entonces, ¿cómo hago una web responsive que no sea obesa y que realmente esté optimizada teniendo en cuenta las características del uso y conexiones que tenemos en los dispositivos a lo largo del mundo?

Me alegro de que lo preguntes...

Antes hablé de cómo el rendimiento no ha de ser visto como una cadena de tareas automatizadas en el servidor para levantar un sitio web ya medio perdido. Hay maneras más inteligentes de aplicar estos conceptos y convertirlos en una ventaja competitiva.

Qué evitar

Guy Podjarny cita tres síntomas principales sobre la cantidad de páginas obesas que vemos por ahí:

Descarga y Esconde
Los recursos se descargan pero se esconden del usuario.

Descarga y Ajusta el tamaño
Se sirven imágenes de alta resolución para escritorio y se ajustan a la pantalla de un pequeño smartphone.

Exceso en el DOM
No hay manera de evitar que los exploradores parseen y procesen todas las áreas del DOM, incluidas las que se ocultan.

Estrategia Preventiva

Hay una gran cantidad de información ahí fuera sobre por qué las páginas web no superan las expectativas de rendimiento. La mayoría viene a decir algo así como 'sé responsable desde el principio'. Las técnicas de las que voy a hablar no son nuevas. Para mi lo interesante es cómo se combinan, juntando fuerzas y cubriendo huecos.

Progressive Enhancement

El objetivo de esta técnica es reducir la experiencia a lo esencial como punto de partida y construir desde ahí.

Hace un par de años esta teoría se aplicaba desde el punto de vista del navegador. Con las nuevas tecnologías a disposición de todo el mundo: HTML5, CSS3, jQuery, etc., diseñadores y desarrolladores empezaban a correr un serio peligro de olvidarse de sus usuarios por apoyarse en estas tecnologías suculentas. Lo que llegaba a un buen porcentaje de ellos era una versión incompleta de la web.

Ahora que la mayoría del mercado de navegadores utiliza Webkit o Gecko (Firefox), el problema gira más hacia la enorme cantidad de dispositivos que no tienen las capacidades técnicas del nuevo iPhone o Samsung. El Progressive Enhancement es de nuevo la manera de trabajar que cuida de los excluídos, y deja las florituras para los que puedan soportarlas.

Desarrollo 'Mobile First'

En 2009, Luke Wroblewski propuso diseñar para móvil primero, por tres razones:

• El mercado móvil está en plena explosión
• Diseñar para móvil obliga a concentrar la información, permitiendo deshacerse de la maraña que resulta de diseñar para demasiado espacio en pantalla
• La tecnología móvil aumenta las posibilidades (GPS, geolocation, multi-touch, accelerómetros, cámara...)

Desde entonces el diseño web se ha transformado rápidamente para seguir estos principios. En el camino, no sólo diseñadores, sino una buena cantidad de desarrolladores ha señalado que programar para dispositivos móviles primero tiene ventaja sobre hacerlo para escritorio, algo muy relacionado con la segunda razón de Luke W. Progressive Enhancement y Móvil Primero se han fusionado de alguna manera. Los desarrolladores crean páginas para móvil como núcleo y las extienden progresivamente, tomando el tamaño de pantalla como un incremento.

Jordan Moore @jordanmoore hace un buen resumen de las razones. Argumenta que ya que 'no podemos apostar sin temor a equivocarnos por la velocidad de conexión. El 'diseñador responsable' trabajaría sobre el mínimo valor posible -un acercamiento 'Mobile First'-, asumiendo la conexión más lenta y construiría desde ahí mediante breakpoints para velocidades más altas'. Algún día podremos usar herramientas sólidas para detectar la banda ancha. Por ahora es buena idea tenerlo en cuenta y no dar pasos en falso.

Para resumir: Escribe tu código para la mínima resolución y capacidades que te interesen, primero. Usa técnicas de Progressive Enhancement desde el principio. Construye funcionalidad extra, gráficos e interacción avanzada cuando se pueda utilizar.

RESS: diseño REsponsive + componentes Server Side
Para mucha gente el diseño Responsive sufría una carencia esencial: fundamentarse en detectar el tamaño de pantalla.

Con más y más dispositivos entrando en el mercado cada día, híbridos como los portátiles de pantalla táctil y demás, la detección de características o features ha pasado a primer plano. Florecen librerías como Modernizr, cuyo manual encuentras en DesarrolloWeb.com, usadas en una cantidad tremenda de proyectos, que ayudan a los desarrolladores a evaluar si el navegador del cliente soporta cierta funcionalidad para inyectársela si es necesario. Pero hacer esto es delicado, porque muchas veces los navegadores 'mienten'. Dicen que soportan ciertas tecnologías, pero en realidad hacen lo que les da la gana. El soporte es parcial, normalmente.

RESS nació como una solución a este problema. El término fue acuñado por Luke Wroblewski, padre también del 'Mobile First', en 2011. Consiste en detectar la clase de dispositivo y proporcionar una experiencia adaptada. Para hacerlo hay librerías, más "heavies" (WURFL, Device Atlas) y más "lights" (Browser Gem), que detectan el agente de usuario del cliente.

Evaluar el dispositivo tiene más ventajas: permite a los desarrolladores servir diferentes 'plantillas'. Pon que estás creando un sitio web gigantesco y que tu intención es que la navegación móvil sea más simple, que ocupe ni la mitad de espacio que la de escritorio. Podrías jugar con el contenido, esconder y mostrar cosas, mover "divs" por ahí mediante Javascript, o podrías mantener una plantilla diferente para escritorio y para móvil, y dejar que el servidor decida cuál servir.

Este enfoque da al diseño Responsive una ventaja esencial sobre los sitios Mdot, o 'm.'. El único mérito que tenían estos últimos era servir una página optimizada para móvil.

La BBC (gente muy astuta con millones de lectores en todo el mundo y un sentido de la responsabilidad bastante fuerte) nos muestra cómo RESS y Progressive Enhancement pueden funcionar como una sóla técnica. Llaman a este acercamiento 'Cut the Mustard', algo así como 'dar la talla'. Consiste en crear una experiencia básica que funcione en todos los dispositivos imaginables. Después, evaluar el dispositivo en el servidor y si efectivamente 'da la talla', servir una experiencia aumentada (Progressively Enhanced experience). De esta forma, si no lo hiciera, los usuarios todavía podrían acceder al contenido básico.

Carga Condicional
Revisa las técnicas para cargar contenido de modo condicional.

Los usuarios de teléfono móvil quieren ver el menú, el horario y el número de teléfono. Los de escritorio obviamente quieren un PNG de 1Mb de alguien sonriendo a una ensalada Mat 'Wilto' Marquis

Un par de cosas a tener en cuenta:

Los usuarios de móvil buscan EL contenido, igual que los usuarios de escritorio.

Si tu contenido es accesible desde una URL, será accedido desde un dispositivo móvil Brad Frost.

El móvil obliga a concentrar la información. Los diseñadores han de aceptar ciertas limitaciones a la hora de servir contenido, como el ancho de banda o el tamaño de pantalla.

También llamada 'Agressive Enhancement', esta técnica de desarrollo permite a los diseñadores concentrarse en el contenido clave, y expandirlo junto al tamaño de pantalla. Se trata de proveer acceso básico a cierto contenido que puede ser inyectado dinámicamente en la página en cuanto haya más espacio.

Puede que sea más preciso pensar en la 'Carga Condicional' como un enfoque 'Content First'. No puedes permitirte el lujo de llenar de contenido sidebars o múltiples columnas. Está bien tenerlas pero no son esenciales. Jeremy Keith

Puedes usar herramientas estupendas como MatchMedia, que imitan el comportamiento del CSS, evaluando el tamaño de pantalla mediante Javascript.

Lazy Loading

Los sitios web con una fuerte carga de imágenes y usuarios que han de ser optimizados para móvil, tipo Facebook o Pinterest, se sirven de la técnica de Lazy Loading o "carga vaga" para mejorar la experiencia. Cuando entras en la página se cargan un cierto número de posts. Cuando llegas hasta el pie de página, el diseñador asume que quieres ver más contenido, así que lo inyecta en la página mediante AJAX. Esto alivia el peso de la página, evitando un exceso en el DOM.

Crear un presupuesto de rendimiento
Tim Kadlec @tkadlec argumenta que ponerse como meta un peso máximo es la manera definitiva de reducirlo. 'Ponte una meta y cúmplela'. Steve Souders propone tres alternativas, si te pasas del presupuesto: * Optimizar recursos existentes * Eliminar recursos existentes * No implementar recursos nuevos. Para mi todo esto suena ligeramente radical, pero el punto es seguir de cerca el rendimiento de la página a lo largo del tiempo, con cada pequeña mejora.

Pongámonos Técnicos

Hay ciertas maneras de alcanzar velocidad, más técnicas y menos conceptuales.

Técnicas de imagen
Las imagenes constituyen cerca del 60% de un sitio web. Si te dedicas a servir imágenes de escritorio a usuarios de móvil con banda ancha indefinida, básicamente estás condenando tu web al bajo rendimiento. El truco para saltarse el problema es servir diferentes tamaños de imagen, dependiendo de tamaño de pantalla o formato: Una pequeña a un móvil y una de alta resolución a un ordenador de escritorio. Una de doble tamaño a un dispositivo Hi-DPI.

Imágenes Responsive
Diseñadores y desarrolladores de todo el mundo han luchado para incluir imágenes responsive en la especificación HTML. Matt 'Wilto' Marquis @wilto es uno de los más afilados. La batalla no está ganada, pero ya hay soluciones Javascript para conseguir el objetivo. Scott Jehl @scottjehl, compañero de Wilto en el Filament Group, escribió un plugin que imita la sintaxis propuesta por la comunidad y que funciona como un tiro: PictureFill.

Imágenes 'Compresivas' Dan Jobsis @daanjobsis, un diseñador holandés, descubrió una anomalía muy extraña comprimiendo imágenes en Photoshop. Probó lo siguiente: Coge una imagen, dobla su tamaño (al 200%), comprímela a un 25% o menos de su calidad original y devuélvela a su tamaño original en el explorador (100%). La imagen no sólo será mucho más ligera, sino ya optimizada para dispositivos HiDPI, por doblar su densidad de píxel.

El único problema que se observa es que al explorador le cuesta repintar una imagen de doble tamaño a la mitad, si lo tiene que hacer cien veces, como en algunas páginas. Decidir si es la solución óptima requiere un poco de testeo.

Vectors VS Bitmaps
SVG es el rey. Una imagen vectorial es por definición expandible y contraíble, así que funcionará bien en cualquier tipo de pantalla. Se puede crear un 'fallback' rápidamente mediante Modernizr.

Icon Fonts
Funcionan como imágenes vectoriales, servidas en formato fuente. Según Chris Coyier @chriscoyier, son estupendas porque:

• Puedes jugar con su tamaño
• Puedes jugar con su color
• Puedes darle sombra fácilmente
• Funcionan en IE6, no como los PNG transparentes.
• Puedes hacer con ellas todo lo que podrías hacer con otras imágenes
• Puedes hacer con ellas lo que sea que harías con tipografía
• Imágenes HiDPI

Dave Bushell @dbushell escribió recientemente un artículo muy interesante sobre imágenes HiDPI. Argumenta que aunque hoy sea posible servir imágenes a iPhones, iPads, etc. que satisfagan la capacidad de sus pantallas, es muy pronto todavía para asumir que no nos va a salir el tiro por la culata.

¿Significa una conexión más rápida y una densidad de píxel más alta que los usuarios quieren más calidad? No lo creo, con estos contratos de datos móviles Dave Bushell

El punto es hacerlo con cabeza, considerando cada caso antes de saltar a por imágenes 4x.

Lo que viene

Google desarrolló recientemente un nuevo formato de compresión de imágenes, WebP. Resulta en imágenes 3 veces menores que el PNG.

Hay librerías sencillas de Javascript para convertir a WebP. Considerando el impacto que tienen las herramientas que va soltando Google, igual no es mala idea probarlo.

Carga de recursos
Hay que cargar recursos cuidadosamente y en orden. Controlar este aspecto es muy ventajoso, por permitir a la página renderizar el contenido básico y expandirlo después.

CSS, Imágenes
Controlar la carga mediante Media Queries, carga condicional o Lazy Loading, e imágenes Reponsive / Compressive

Javascript Usar funcionalidad HTML5 como async y defer. Hay librerías de carga como RequireJS, para organizar dependencias y orden de carga.

Anuncios, Widgets sociales o cualquier plugin de terceros

Simplemente inyectar después de cargar.

Técnicas de rendimiento Old-school
Nos siguen desde hace ya tiempo pero hoy son igual de relevantes.

Reducir el número de llamadas HTTP
Para conseguirlo hay que pensar recurso a recurso, aunque hay algunas reglas que vienen muy bien:

• Concatena todos los archivos CSS o usa un preprocesador (LESS, SASS o Stylus) para compilarlos en un sólo fichero.
• Unifica todos los plugins de Javascript en un fichero y cárgalo en el footer, a menos que tu intención sea que bloqueen el renderizado de la página (si cargas fuentes de Typekit en el footer, por ejemplo, sufrirás el infame FOUT, 'Flash Of Unstyled Text' o 'Flash de texto sin estilos').
• Si has de usar PNG, usa sprites. Unifican todas las imágenes y usan CSS para cortar las piezas. Hay una buena cantidad de recursos online para hacerlo. (WAKKOS ref)
• Carga las imágenes mediante data: URI siempre que puedas. Esto permite incluir imágenes como datos, reduciendo el número de llamadas HTTP.

Reduce el número de Bytes
Uglifica, minifica, o como te de la gana, cada fichero Javascript o CSS que llames desde la página. Configura tu servidor para que permita compresión GZIP y comprime todos los recursos que puedas.

En Resumen

La importancia del rendimiento de las páginas web se ha pasado por algo desde el nacimiento de las páginas Responsive.

Tanto diseñadores como desarrolladores estaban tan concentrados en resolver el puzzle del diseño Responsive que no se han percatado de cómo un nuevo escenario, una nueva web multi-ancho-de-banda, multi-dispositivo, multi-localización se abría paso entre la maraña.

Para estar preparado para los problemas por venir tenemos que incluir el rendimiento como una consideración esencial, mientras la web de escritorio se deshace frente a nuestros ojos. El usuario de móvil está más preparado y tiene más prisa, y no va a andar brincando por aros para llegar al contenido. Y ya que cada día hay más y más pagínas, ser rápido significará estar a la cabeza.