Vamos a seguir en la línea de anteriores artículos hablando acerca del Responsive y de su optimización.

De hecho enlaza a la perfección con la introducción a RESS de hace dos semanas, porque como veréis algunos de los problemas abajo descritos tienen en RESS parte de las soluciones, o al menos, empequeñecen el problema 😉

Hablemos entonces de WPO (Web Performance Optimization) en el RWD (Responsive Web Design) con algunas de las problemáticas actuales:

1. El marketing detrás del RWD.

Obviamente se mueve un gran marketing detrás de este acrónimo, basta darse una vuelta por la red o visitar las páginas de estudios de diseño web y hay pocas palabras más utilizadas.

Y nos incluímos en ello. Desde que nos dimos cuenta de su potencial hemos enfocado muchos esfuerzos en ello, el problema es cuando se vende mal. Porque ello lleva a equívocos muy grandes, que no diré que sean a propósito… pero suceden.

Cuando se utiliza el término muchas veces se hace mal: Responsive no es “que quede bien en móvil”.

2. Ocultar contenido (Hiding content).

Esto es lo más usual, el manido “display: none;” está a la orden del día. “¿La pantalla empequeñece? Esto sobra”, display none, y tan pancho.

3. Diseñar para desktop. Apañar para mobile.

Esto es algo que, se tiene que abandonar ya. Y ya, es el año pasado.

“Unas media queries por aquí, otras por allá, todo que fluya hacia abajo, y… ¡Tenemos sitio móvil!”

¿Cómo podemos diseñar para desktop y luego simplemente ir apañando? ¿Entendemos la versión móvil como un apaño? ¿De verdad?

4. Imágenes.

Hace un tiempo ya escribimos sobre las imágenes en el RWD.

Mirando por encima HTTP Archive veréis que más de un 60% de la media de peso de una web es de imágenes, solo con este dato ya vemos que es un factor a tener muy en cuenta para la optimización de un sitio web, y ya ni hablemos si además es para un móvil…

5. Scripts, Librerías, Botones sociales, Plugins…

Aquí llegamos a otra de las pegas actuales: La sobrecarga de elementos inútiles, librerías que no se utilizan (o se utiliza una parte muy pequeña de ellas), botoneras sociales que cargan X scripts y que hacen X peticiones, etcétera…

Identificados (por encima) los problemas, ¿qué podemos hacer al respecto para mejorar el WPO afrontando un Desarrollo Responsive?

Lo primero que recomiendo es adoptar el modelo RESS de inmediato, toda la información que puedas sacar de la parte del servidor: bienvenida sea.

Lo segundo sería enfocar el desarrollo de menos a más, es decir, mobile first. Cargar asumiendo siempre la pantalla más pequeña (a no ser que utilizando RESS obtengas otro breakpoint, que en ese caso se partiría de ese). Y evidentemente este paso también incluye el diseño. Diseñad para móvil primero, os daréis cuenta más fácilmente de lo que es necesario.

Para saber cuándo hacer los breakpoints leí hace un tiempo una frase perfecta: Start with the small screen first, then expand until it looks like shit. Time for a breakpoint. (@stephenhay).

¿Se puede tener más razón? Es algo tan obvio que cuesta entender cómo peleamos tanto por los breakpoints y cómo buscamos la perfección en ello, cuando realmente no hay otra lectura que esta.

Respecto al marketing habría que preguntarse realmente si lo que queremos es “que se vea bien en móvil” o una experiencia de usuario buena en móvil (y en el resto de tamaños). Si se trata de lo primero, poco más hay que añadir. Con unos apaños en las CSS se verá bien en móvil. Lo que quizá habría que preguntarse es si deben pesar lo mismo para un móvil que para un desktop… ¿no?

“Ocultar contenido” realmente va en la línea del punto 1 y del punto 3, porque tienen relación directa con el diseño los 3 puntos. No podemos ir a por una web adaptable a dispositivos si lo único que hacemos es esconder lo que no interesa en versiones pequeñas y hacer que todo el diseño fluya para abajo “y ya está”, hay que ir algunos pasos más allá.

Sobre las imágenes, en el post que menciono arriba pusimos algunas de las soluciones en ese momento. La que más solemos utilizar es tener varios tamaños de imagen, y utilizar el data-* de HTML5 (o en muchos casos simplemente concatenar pequeños strings por formato) y cargar unas u otras en función de la pantalla u otras mediciones. Y obviamente, utilizar algún tipo de “Lazy Load“.

Y sobre el último punto, hace un tiempo leí una de las mejores citas respecto al WPO: Best request is no request. Worst request is one that blocks the parser (@igrigorik), y me parece más que acertada.

Sobre librerías javascript creo que nos hemos mal acostumbrado a cargar y cargar… y realmente lo que utilizamos de ellas nunca es tanto como pensábamos.

Por nuestra parte últimamente estamos intentando utilizar menos plugins y librerías javascript (especialmente jquery), programarlos nosotros enfocados a lo que queremos hacer para no cargar peso no utilizado. Además de ello, intentar cargar ondemand (asíncronamente ante un evento de usuario, o de página) todo lo que podemos, y así evitar la primera carga.

Sobre Botoneras sociales hay soluciones muy sencillas. No paro de ver webs que cargan scripts y scripts de las redes sociales, sus imágenes, peticiones… Y al final todo suma y todo resta. Si no vigilamos estos temas en unos meses tenemos una web sobrecargada y llena de peticiones sin sentido, que no se utilizan o que sirven de más bien poco.

Enlaces interesantes relacionados

 

Imagen de morgueFile

Comparte… ¡o no!
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *