Consejos para el rendimiento del diseño web adaptativo (RWD)

Guy Podjarny, director tecnológico de Web Experience de Akamai Technologies.

Diseño web adaptativo (Responsive Web Design, RWD) es la palabra de moda que está recorriendo Internet actualmente. Sin embargo, a pesar de que lleva en circulación algo más de dos años, en muchos aspectos aún se encuentra en sus comienzos. Los diseñadores se enfrentan a un panorama fragmentado y en constante proceso de cambio en lo que respecta a los dispositivos, marcos de código y capacidades de navegadores, así como, por supuesto, a la necesidad de trabajar con los clientes de una forma diferente para gestionar el proceso de creación de sitios web adaptativos.

Además, las páginas diseñadas de forma adaptativa son intrínsecamente más complejas que una página web media diseñada específicamente para móvil. Debido a esta complejidad, RWD requiere una especial atención al rendimiento si se quiere evitar a los usuarios problemas relacionados con la reducción de velocidad y un uso creciente de datos. Como cualquier usuario habitual de móviles sabe, no hay nada más frustrante que el hecho de que una página web se cargue despacio, y eso puede condicionar el éxito o fracaso del canal en línea de un negocio, ya que los usuarios que deben esperar demasiado, inmediatamente accederán a otro sitio web que funcione más rápido.

A continuación encontrará varios consejos que debe tener en cuenta a la hora de embarcarse en el diseño web adaptativo, y que le ayudarán a sortear mejor las dificultades y a garantizar el rendimiento, la optimización y el uso de datos de los sitios web de empresas:

1 – Evitar la descarga de imágenes ocultas usando una técnica de carga de imágenes basada en JavaScript o CSS. Los sitios web adaptativos usan principalmente reglas de estilo para ocultar imágenes, configurando su estilo como «display:none». Sin embargo, ocultar una imagen de este modo no evita que el navegador la descargue, lo que tiene como resultado la descarga inútil de una imagen. Puesto que la mayoría de los sitios web adaptativos muestran un número significativamente menor de imágenes o pantallas más pequeñas, este problema es la razón fundamental del peso excesivo de los sitios web adaptativos que se cargan en una sola página.

2 – Descarga de imágenes con un tamaño adecuado a la pantalla correspondiente, una técnica conocida como «imágenes adaptativas». Los sitios web adaptativos a menudo muestran la misma imagen en todos los tamaños disponibles (asumiendo que la imagen no está oculta), pero definen el tamaño de visualización de la imagen usando un percentil, de modo que esta se adapte suavemente al tamaño de la pantalla. Esta técnica, conocida como «imágenes fluidas», tiene un gran impacto visual, pero una vez más genera un exceso en la cantidad de datos descargados.

Una solución más propicia consiste en crear varias versiones de cada imagen, cuyo tamaño se adapta en el servidor según corresponda, y descargar la versión más cercana a las capacidades de visualización utilizando una herramienta de carga de imágenes como las mencionadas en el primer apartado. Adaptar su tamaño en el servidor implica que la carga útil que se envía a la pantalla pequeña es menor, por lo que la página funciona más rápido. Es importante tener en cuenta que un enfoque alternativo consistiría en almacenar solo la «mejor» imagen en el servidor y usar un servicio como el Conversor de Imágenes de Akamai para modificar su tamaño (siempre en el servidor) en tiempo real.

3 – Carga condicionada de JavaScript, y especialmente de componentes de JavaScript de terceros. Los sitios web adaptativos a menudo incluyen componentes de javascript que en realidad no se utilizan en pantallas pequeñas. Algunos ejemplos son secuencias de Twitter, mapas de localización, aplicaciones de chat de atención al cliente y muchos más. Al igual que los ejemplos de imágenes anteriores, ocultar la salida de estas imágenes mediante estilos no impide que el navegador las descargue y ejecute los scripts. A pesar de que son más pequeños en carga útil, los scripts tienen un impacto byte a byte mucho mayor sobre el tiempo de carga de la página, y los scripts de terceros pueden introducir incluso fallos de fiabilidad en una página.

Por lo tanto, es preferible incluir esos scripts en un script pequeño y en línea que verifique las propiedades del dispositivo y solo añada los scripts a la página si realmente pueden necesitarse, evitando así riesgos innecesarios de fiabilidad y ralentización. Es importante hacer esto con cuidado para evitar que se ralentice la versión para pantalla grande de la página, por ejemplo añadiendo elementos de forma dinámica al Document Object Model (DOM) siempre que sea posible, en lugar de usar la función «document.write()».

4 – Uso de RESS (REsponsive + Server Side) para optimizar su sitio para clientes conocidos. El diseño adaptativo es una herramienta excepcional para el soporte de muchos tipos de clientes sin ni siquiera estar al tanto de su existencia, pero (tal y como demostramos en los puntos anteriores) a menudo tiene como resultado descargas excesivas. Parte de este exceso puede gestionarse usando una herramienta de carga inteligente, pero otros elementos, como códigos HTML o CSS excesivos, son mucho más complejos de tratar en el cliente.

En estos casos, la única solución auténtica consiste en introducir un componente de servidor que identifique a los clientes conocidos y habituales, y que sintonice el HTML de acuerdo exclusivamente con esos clientes. Otros clientes obtendrán el sitio web adaptativo, que debería seguir funcionando aunque tenga un rendimiento menor. Un buen ejemplo de esto es recortar las porciones más grandes «solo para pantalla grande» del código HTML cuando se identifique que un cliente es un smartphone conocido, a menudo eliminando al mismo tiempo referencias a archivos JavaScript y CSS que no vayan a necesitarse.

5 – Introducir una prueba de rendimiento en el proceso de control de calidad o de construcción. Al fin y al cabo no podemos mejorar lo que no podemos evaluar. Si quiere conseguir rapidez y mantenerla, es importante que introduzca una prueba de rendimiento en su proceso habitual de control de calidad y evaluación, y que la sitúe lo antes posible dentro del flujo. Existen herramientas, como WebPageTest y otras muchas, que facilitan mucho la introducción de una prueba de rendimiento sencilla de páginas clave de su aplicación, así como la ejecución de dichas pruebas desde navegadores con tamaños adaptados a diferentes ventanas y la simulación de diferentes propiedades de proporciones de píxel de los dispositivos («Retina»).

Consulte la lista de comandos de programación de WebPageTest para ver diferentes opciones de este tipo, que a menudo se ejecutan en el navegador Chrome. Un punto de partida sencillo es medir el rendimiento de una página determinada de su sitio en el día de hoy 20 o 30 veces, marcar el tiempo medio de carga de la página como base y anotar la desviación estándar. A continuación, introduzca la misma medida de rendimiento en su propio proceso de construcción y si el nuevo tiempo de carga medio de la página es más alto que el tiempo base en más de una desviación estándar, marque la construcción como discontinua. Esto le ayudará a impedir que su rendimiento se vaya degradando con el tiempo y le permitirá centrarse en reducir esa marca de base.