Responsive Web Design (RWD – Diseño de Web Responsivo) es la palabra de moda actual, pero, pese a que se hable de ello desde hace más de dos años, en muchos sentidos sigue estando en sus inicios. Los diseñadores se enfrentan a un abanico fragmentado y cambiante de dispositivos, marcos de códigos y capacidades de navegadores – además y por supuesto, a la necesidad de trabajar de otra manera con los clientes para manejar el proceso de creación de sitios web responsivos.
En concreto, las páginas diseñadas de forma responsiva son inherentemente más complejas que la página media del sitio web móvil. Debido a esta complejidad, RWD requiere que se preste más atención al rendimiento si se quiere evitar que se degrade la velocidad y se incremente el uso de datos por parte de los usuarios. Como para cualquiera de nosotros que somos usuarios móviles frecuentes, no puede haber nada más frustrante que unas páginas que se cargan lentamente y esto puede hacer o romper el éxito del canal online de un negocio ya que los usuarios a los que se les hace esperar demasiado tiempo se irán rápidamente a otro sitio que funcione más rápido.
Prácticamente todas las empresas con las que hablo, en todo el mundo, adoptarán RWD, ya lo han adoptado, o por lo menos, lo están evaluando seriamente. Pero esto plantea una pregunta, ¿con todo este revuelo, cuántos sitios web son realmente responsivos?
Recientemente, he realizado una prueba en los primeros 10.000 sitios web (según Alexa), para comprobar si son responsivos. Esta prueba era una repetición de la prueba I realizada el año pasado y se basa principalmente en la presencia de una barra de desplazamiento horizontal cuando se carga la página en una pantalla pequeña. Si está la barra de desplazamiento, esto indica que el sitio web no ha ajustado su diseño a la pantalla, y por lo tanto, no es responsivo. Lo que he encontrado es que el porcentaje de sitios web responsivos entre los primeros 100, 1.000 y 10.000 sitios web es bastante substancial, alcanzando una tasa de adopción del 18,7% en todo el conjunto de datos.
Está claro que es una tendencia que las organizaciones están adoptando, por lo tanto merece la pena tomar en consideración algunos de los principales consejos a la hora de embarcarse en un diseño web responsivo lo que ayudará a superar mejor los riesgos y ayudar a asegurar el rendimiento, optimización y uso de datos para los sitios web de las organizaciones:
- Descargar imágenes con un tamaño adecuado para cada pantalla, una técnica conocida como “Imágenes Responsivas”.
Los sitios web responsivos visualizan normalmente la misma imagen en todos los tamaños de pantalla (suponiendo que la imagen no esté oculta), pero definen el tamaño de visualización de la imagen utilizando un percentil para que se adapte suavemente al tamaño de la pantalla. Esta técnica, conocida como “Imágenes Fluidas” está bien visualmente, pero crea desgaste en el volumen de datos descargados. Una solución mejor es crear varias versiones de cada imagen, cuyo tamaño se cambia en el servidor para conseguir el adecuado y descargar la que más se acerque a las capacidades de la pantalla utilizando un cargador de imágenes más inteligente. Esto se puede realizar utilizando srcset, un nuevo estándar que ya ha conseguido un buen soporte del navegador. Como alternativa, se puede hacer utilizando estándares que gozan de menos soporte, por ejemplo el elemento de imagen, ayudado por “pollyfills” (líneas de código) JavaScript. Redefinir el tamaño de las imágenes en el servidor significa que la carga enviada a la pequeña pantalla es más pequeña y que la página es más rápida. Para una mayor agilidad, solo almacene la “mejor” imagen en el servidor, y utilice servicios de transcodificación de imagen proxy, como “Image Converter” (Conversor de Imágenes) de Akamai, para cambiar el tamaño de la imagen justo antes de que se entregue al cliente.
- Evitar descargar imágenes ocultas utilizando cargadores de imágenes más inteligentes. Además de hacer que las imágenes sean fluidas, los sitios web responsivos utilizan reglas de estilo para ocultar imágenes configurando su estilo en «display:none». Sin embargo, ocultar una imagen de esta manera no impide que el navegador la descargue, lo que da como resultado una descarga de imágenes ineficiente. Como la mayoría de los sitios web responsivos muestran bastante menos imágenes en pantallas más pequeñas, este problema compite con el nº 1 por ser la primera razón debido al peso excesivo de página de los sitios web responsivos cargados en una sola página. Utilice cargadores de elemento de imagen basados en JS, como aquellos descritos en el consejo nº 1, para evitar descargar estas imágenes ocultas.
- Cargue con reservas JavaScript, y especialmente JavaScript de terceros.
Los sitios web responsivos incluyen a menudo componentes JavaScript que no se utilizan en una pantalla pequeña. Por ejemplo, los hilos de twitter, los mapas de ubicación, los chats de agentes en vivo y mucho más. Como los ejemplos de imagen mencionados antes, ocultar la salida de estas imágenes utilizando estilos no impide que el navegador descargue y ejecute los scripts. Aunque tienen una carga más pequeña, los scripts tienen un impacto byte por byte mucho mayor en el tiempo de carga de la página, y los scripts de terceros pueden también introducir puntos de fallos de fiabilidad en una página. Por lo tanto, es mejor envolver estos scripts con un pequeño script alineado que comprueba las propiedades del dispositivo y solo añade los scripts a la página si realmente se necesitan, evitando así la lentitud y los riesgos de fiabilidad. Es importante hacerlo cuidadosamente para evitar ralentizar la versión del sitio para pantallas mayores, por ejemplo añadiendo de forma dinámica elementos al Modelo de Objeto de Documento (Document Object Model – DOM) donde sea posible en vez de utilizar la función «document.write()». - Utilice RESS – REsponsive + Server Side – para optimizar su sitio web para clientes conocidos.
El diseño responsivo es una excelente herramienta para soportar muchos tipos de clientes sin incluso conocer su existencia, pero a menudo esto lleva a descargas innecesarias y excesivas. Se puede manejar parte de ello utilizando una carga inteligente, pero otros tipos – como HTML y CSS excesivos – son mucho más difíciles de tratar en el cliente. La única solución real es introducir un componente en el lado del servidor que identifique a los clientes conocidos y populares y adapte el HTML según estos clientes. Otros clientes tendrán el sitio web responsivo, que debería funcionar todavía, incluso si su rendimiento es menor. Un buen ejemplo de esto es recortar las porciones “solo para gran pantalla” más grandes de su HTML cuando se identifica que un cliente es un smartphone conocido, eliminando a menudo en las mismas referencias técnicas a ficheros JavaScript y CSS que no se necesitarán.
- Introduzca pruebas de rendimiento a su proceso de QA o de creación.
Al final, uno puede optimizar lo que puede medir. Si quiere ser rápido y mantener esa rapidez, es importante introducir una prueba de rendimiento en sus pruebas regulares y procesos de calidad, y hacerlo lo antes posible en el flujo de trabajo. Herramientas como WebPageTest y muchas otras facilitan añadir una prueba de rendimiento sencilla de páginas clave en su aplicación, y ejecutar estas pruebas desde navegadores con diferentes tamaños según los tamaños de las ventanas de vista y simulando diferentes propiedades de ratio de píxeles de dispositivo («Retina»). Échele un vistazo a la lista de comando de scripts de WebPageTest para ver estas manipulaciones, que se realizan normalmente en el navegador Chrome. Un punto de partida sencillo es medir el rendimiento de una página específica en su sitio web hoy 20 o 30 veces, establecer como base de referencia el tiempo de carga de página medio y anotar la desviación estándar. Luego, introduzca la misma medición de rendimiento en su proceso de creación, y si el nuevo tiempo de carga de página medio en más de una desviación estándar es mayor que la base de referencia, marque la creación como rota. Esto le ayudará a impedir que su rendimiento se degrade en el tiempo, y le dejará entonces centrarse en hacer que esta base de referencia sea más pequeña.
Guy Podjarny, CTO Web Experience, Akamai Technologies.
