SI bien uno de los problemas que nos encontramos al solicitar que nos sirvan publicidad adaptada a dispositivos, por regla general nos encontraremos con que la agencia en cuestión no dispone de ese servicio. Y es que básicamente sus clientes o red de clientes sigue aportándoles materiales flash, en vez de contenidos separados, o tal vez que el equipo técnico de la agencia no esté por la labor de dar el paso hacia HTML5 aún manteniendo flash por el soporte y la compatibilidad.

Está claro que la carga de trabajo sería mayor, pero también que aumentarías tu cartera de clientes considerablemente y te posicionarías en un mercado creciente.

Si todavía existe un gran paso para que HTML5 se afiance del todo, sin ninguna duda ese paso es la publicidad. No le quitemos importancia, pues a fin de cuentas es el gran motor y medio de vida para muchos de nosotros.

Todos nosotros conocemos más que de sobra muchas de las utilidades y beneficios de usar HTML5, ya sean sus formatos abiertos y libres para reproducir contenidos multimedia, como vídeo o sonido, como también que a diferencia de un fichero flash (flv) html tiene valor semántico y mejoramos nuestro SEO.

Bien, pues eso no es todo, existe un sin fin de beneficios aunque también desventajas de hacer uso de esta “tecnología”. Si bien con flash nos atamos a un sistema privativo aunque funcional, con html5 las puertas se abren a cualquier dispositivo, cosa a tener muy en cuenta en nuestras campañas móviles, sobre iOS, Android, …

Si en algo le doy la razón a flash, es que era un único fichero, el cual funcionaba en cualquier lugar siempre y cuando se soportase flash y además tuviésemos instalado el plugin extra para visualizar correctamente los contenidos.

En cambio HTML5, depende del tipo de anuncio que mostremos dispondrá de varios archivos, unas reglas de estilo (css), contenido multimedia (img, video, audio, ..), un controlador (js) para disparar eventos y obtener estadísticas, y finalmente el documento (html) que englobe todas estas partes. Claro que las posibilidades son mayores que en flash.

También rompo una lanza a favor de HTML5 por el tema del SEO. Hemos podido comprobar a lo largo de los años como se ha ido pasando de páginas completamente creadas en flash se han migrado a HTML4 y posteriormente a HTML5. 

Como vimos en el anterior post, se puede mejorar la carga de los componentes sociales adicionales. Pero cuando hablamos de dispositivos móviles la cosa como de costumbre se complica más de lo esperado.

En primera instancia hacer uso de iframes nunca está bien visto, y más cuando queremos que nuestra web app alcance unos ciertos controles de calidad, validadores o test mínimos, como puede ser mobileOK.

Cuando vayamos a pasar un control de este tipo podremos comprobar que nos penalizan por hacer uso de iframes, los cuales sobrecargan la página.

La mejor solución es hacer uso de los recursos que ciertas redes sociales nos ofrecen, y es crear por nuestra cuenta el botón, o widgets y redirigir la funcionalidad a la web de la propia red social. Está claro que perderemos el foco de nuestra app, y que además el abrir nuevas pantallas o lanzar popups, también es algo penalizado en versiones móviles. Aunque desde el punto de vista del WPO sea la mejor solución.

Llevo varios días peleándome con la optimización de una web que usa abundantes widgets de redes sociales. Y después de mucho mirar, he intentar muchas cosas, no he obtenido una solución elegante.

Hay que comentar que cada red social incorpora un script maestro, el cual se encarga de construir los widgets, sean los que sean, pero teniendo en cuenta que cada red dispone de uno diferente, y que por lo tanto al cambiar de servidor, hay que volver a perder tiempos en conexiones, DNS, … y finalmente descargas. Sin hablar de los tiempos de javascript a la hora de construir y volver a solicitar más scripts y contenido adicional de los widgets.

En muchas ocasiones nos encontramos con redirecciones 302, y reconexiones y más resoluciones de DNS.

Esto como se puede comprobar se convierte en una bola enorme de peticiones imposible de evitar. Da igual que la carga sea asíncrona, pues como existe una cadena de peticiones rápidamente se convierte en un cuello de botella.

Hace no mucho que facebook, y resto de redes sociales, realizan una carga inicial asíncrona, a diferencia de twitter (https://dev.twitter.com/discussions/3369). Tengo que decir que pinterest ha sido el más difícil de tratar, sin contar con la lentitud del servicio.

Las ocurrentes caídas de sus librerías alojadas en sus servidores, etc …

Me he encontrado con likes de Facebook de 84k con 1,34 segundos, y con botones de google plus con mejoras del 20% en la carga.

Vamos al lio, como optimizamos todo esto ? Es una buena pregunta, y aunque el problema no se puede atajar por completo, que sería deshacerse de estos dichosos botones, hay alternativas.

Lo primero es entender el funcionamiento de estos widgets. El servicio quiere hacernos la vida fácil, pero olvidando la optimización, y es por eso que nos ofrece un elemento (a, div, … tag) a modo de referencia y configuración, y un script constructor.

Este script generador, busca el tag referencia, obtiene las configuraciones y finalmente es sustituido por un iframe. Si hay leido bien por un maldito iframe. Hasta Google amante de la velocidad, opta por esta solución, en parte es comprensible, pues se ocultan ciertos componentes para garantizar una seguridad.

Bien ahora que ya sabemos como funcionan estos widgets, podemos ahorrarnos las solicitudes de estos scripts eliminándolos por completo y obteniendo el iframe directamente, para que dos peticiones, en vez de una ? Bien la primera es asíncrona.

El siguiente paso, será cargar estos iframes de forma dinámica. Con esto habremos ganado mucho. Tiempos de creación y solicitud del iframe, conexiones, DNS, …

Como antes he comentado es un acercamiento, pero no una solución definitiva.

Hay detractores que van en contra de esta solución, argumentando que estos scripts se descargan con tanta frecuencia que todos nosotros tenemos una copia cacheada en nuestro navegador. Al igual que con otros famosos scripts, jquery, object, ga, …

Cuando hablamos de mejorar la carga de una página, casi siempre nos referimos al total de la carga. Pero hay dos aspectos muy importantes que componen esa carga total.

Uno de ellos es el speedIndex, término usado por webPagetest, que hace referencia al tiempo de carga mínimo para pintar algo por pantalla.

Este concepto es muy importante y entra en relación en el ámbito móvil cuando hablamos del first view. Cuando una persona accede a una web, quiere ver algo al instante, sea lo que sea, pero algo, no una pantalla en blanco. Evidentemente mejorar el firstview de nuestra web, quiere decir dos cosas, que cargue muy rápido, y que además que se muestre el mayor contenido posible.

Normalmente este contenido no suele ser multimedia, ni imágenes, ni vídeos, ni música. Preferiblemente texto plano, y muchos estilos, para llamar más atención.

Empezaremos mostrando aquellos componentes de nuestra web, que afectan a la funcionalidad. Es decir si tenemos un servicio para escuchar música, lo más importante para nosotros serán aquellos componentes mínimos necesarios para escuchar música, y no la caratula del álbum.

Con esto quiero decir que tendremos que realizar un breve análisis, para determinar cuales son los contenidos básicos para nuestra web, y cargarlos los primeros de todo.

Imaginad, que para mí web lo más importante es un vídeo. En ese caso tenemos que idea soluciones auxiliares, hasta que el vídeo se cargue. Como por ejemplo que el usuario vea un póster del vídeo, o una serie de imágenes.

Siempre es preferible un speedIndex muy rápido y una carga total más larga, que una carga total rápida y un speedIndex lento.

Con la llegada de HTML5 muchas cosas han cambiado y mejorado, pero todavía no es voxpopuli , falta dedicarle más tiempo y conocer bien sus posibilidades.

Una de las muchas opciones que nos brindan las nuevas API´s de HTML5, es el localStorage, una magia para nuestro WPO. El localStorage nos va a permitir almacenar datos y hacer uso de ellos hasta que el usuario decida borrarlos, es mucho mejor y más segura que la caché, además de que posee una capacidad mayor de almacenamiento (5Mb).

Con esta fantástica técnica podremos ahorrarnos peticiones vacías o de control. De este modo agruparemos varias peticiones en una.

Ahorro ? Si, y bastante grande.

Otro de los usos más frecuentes aunque no sean tan WPO, es que disponemos de un acceso a datos, sin necesidad de conexión a internet.

Esto supone no quedarnos colgados y dejar de leer noticias, o el contenido que sea, si por ejemplo viajamos en el metro y de repente nos quedamos sin internet, o incluso si ya la señal es muy debil, y finalmente la conexión agota el tiempo permitido, ocasionando un timeout.

Un dispositivo móvil es realmente pequeño, quieras o no quieras; aquellos diseñadores y frontend´s sabrán bien de que les hablo. Queremos añadir muchos componentes, mucho contenido, en tamaños realmente pequeños, y mantener las mismas facilidades e incluso aumentarlas.

Mismamente en un iphone, nos encontramos que casi un 30% del alto de pantalla se lo come las barras de control y navegación. Luego añade publicidad, … etc.

Con esto os vengo a comentar el tipo de diseño para reducir contenido duplicado, peticiones, tiempos de carga, … etc

Si contamos con mucho contenido, lo más habitual suele ser separarlo en muchas pantallas bien definidas. En este caso podemos ir duplicando ficheros y modificando el contenido interno, que vendría a ser una app MVC de toda la vida, con su pantalla por cada fichero, hojas de estilo, cabecera, pies …

Al usar este patrón tendríamos que cambiar de página cada vez, volviendo a solicitar (aun teniendo en cache) los ficheros, imagenes, hojas de estilo, y demás componentes.

Bien, una solución es diseñar una webapp “all in one”, siempre dependiendo de lo que necesitemos y queramos conseguir; es decir en vez de tener varios ficheros, disponer de un único fichero, algo más grande, pero que construya todo el layout para solicitar el resto de pantallas e integrarlas dentro de esta. Ahorrándonos peticiones extra, únicamente solicitaremos el contenido. Además nos permitirá cachear y almacenar esos contenidos en la memoria local del dispositivo.

Leyendo varios artículos sobre usabilidad, me he dado cuenta, que en todos ellos se repite un patrón, sobre todo cuando se habla sobre dispositivos móviles.

Dejan claro que el usuario quiere una interfaz muy bonita, muy ágil y fácil de seguir y usar. intuitiva, con varios puntos de acceso para mismas acciones.

Todo esto está muy bien, pero implica un coste considerable y lacra para la carga de la web. Si pensamos en todas esas mejoras que tendremos que hacerle a nuestra aplicación web, con esas ayudas y fallbacks.

Bien, una posible solución es cargar el contenido mínimo, a la vez que engañamos al usuario, con falsas pantallas muy visuales pero de bajo peso.

¿ Y esto como se consigue ? Bueno como de costumbre no estamos descubriendo nada que no conozcamos ya. Quién sino los videojuegos han tenido siempre problemas con los tiempos de carga. Bueno, pues observemos como lo solventan ellos y copiemos sus soluciones a la vez que las mejoramos.

Las típicas pantallas de carga con “ayudas” o “consejos”. Esto me he cansado de verlo en videojuegos, mientras se cargaba el contenido te iba anticipando lo que ibas a poder ver.

Aquí tenemos una primera solución. Digamos que sería la pantalla de splash, a la cual le añadiremos esos tooltips o notas de ayuda, indicándonos el camino a seguir.

De esta forma conseguiremos una carga super rápida, pues unos simples testos planos en un fondo, con algún patrón repetido, no pesa prácticamente nada, y sin javascripts. Que más podemos pedir.

Mientras mostramos esto, podemos ir cargando por debajo y de forma asíncrona, el resto del contenido.

Lo importante de esta técnica, además de utilizarla, es saber apartar la atención del usuario de la carga, de esa espera, y contarle algo que le pueda interesar. La última oferta de de nuestro ecomerce, un tweet, … lo que sea mientras consigamos que el usuario deje de pensar en el tiempo de carga.

Dejado claro el tema de mediaqueries, y la postura oficial de Google, en la no duplicación de contenido, os vengo a contar la posible solución, y el el responsive design, pero desde el servidor.

Es decir nos adaptamos en la parte del servidor y no en la del cliente, o en ambas partes, pero siempre sirviendo un contenido diferencial.

Como es evidente no todas las web son iguales, ni sus clientes son los mismos, así que tendremos que revisar nuestras estadísticas evaluando en que fragmentos tenemos que dedicar más esfuerzo y distinguir mejor nuestro contenido.

Si no nos queremos liar mucho, podremos directamente ofrecer dos contenidos, uno de escritorio y otro móvil. Luego lo correcto sería ir ampliando y adaptándonos al máximo.

A esta técnica se la denomina con RESS, server side components.

Como su nombre indica, trabajaremos con componentes al igual que lo hace Yahoo, con su framework mojito

Las diferencias entre un dispositivo móvil y uno fijo son todavía muy grandes y es por eso que tenemos que diferenciar muy bien ambas plataformas.

Todos hemos visto la reacción de Google ante el hecho de separar las webs según el dispositivo. Como es evidente, a Google no le satisface esa idea y opta por usar mediaqueries para adaptar el contenido según el dispositivo.

Pero no nos liemos, únicamente conseguiremos que se visualice bien, pero … a la misma velocidad. Es decir que si en mi ordenador de casa la web tarda en cargar y renderizar en el navegador 2s por poner un ejemplo, en el móvil con conectividad de 3G, posiblemente tarde más del doble. ¿Y por qué? Pues por que le estamos ofreciendo el mismo contenido, simplemente que lo adornamos para que se muestre bien en resoluciones y densidades menores, pero nada más.

Incluso en alguna ocasión he llegado a ver, que el contenido o el número de peticiones incrementa. ¿Y esto como es posible ? Bueno además de cargar el contenido de escritorio, se añaden ciertas librerías, o componentes extras para que todo marche bien.

También haciendo uso de mediaqueries, en muchas ocasiones se consigue duplicar peticiones en imágenes, primero solicitando la imagen grande, para resoluciones grandes y luego otra petición para formatos menores.

¿Quieres leer la primera parte ? Ir a WPO en móviles I