(Notar que todos los ingenieros de Google usan Macs…)

Estuve en las charlas que organizó Google en Buenos Aires en el marco del DevFest y afortunadamente en los dos días se tocaron diversos temas. Les dejo algunos conceptos e impresiones que me quedaron sobre los temas que más me interesaron:

• Charlas sobre HTML5: Contrariamente a lo que dice la W3C, Google quiere que utilicemos HTML5 YA, que no esperemos hasta el 2022. En las presentaciones, los ingenieros mostraron diversas demos para mostrar su potencial: Utilización de canvas 2D y 3D, aplicaciones offline, nuevos elementos en las interfaces, nuevos atributos para los elementos, utilización de audio, video. Todo esto sumado a las nuevas características de CSS3. Y dejaron en claro que Google Chrome Frame es la solución para que las versiones antiguas de Internet Explorer puedan utilizar el estándar.
  
  Presentaciones:
  - HTML5: Building for a Faster Web por Eric Bidelman
  - HTML5++, el futuro de la web, ahora! por Ernest Delgado (fueron 3 presentaciones separadas, una de ellas el slide de HTML5 Rocks)
  
  
• Charlas sobre Google Maps y Geolocalización: Dos presentaciones realizadas por Ossama Alami, en donde se habló sobre las características de la nueva API de Google Maps. Aunque no trabajo seguido con la aplicación, realmente me gustó mucho: Posibilidad de modificar el look de los mapas en colores y elementos, soporte para móviles, Street View utilizando canvas (y no Flash), posibilidad de crear nosotros mismos nuestro Street View con imágenes propias (se mostró una demo muy buena con un recorrido dentro del mismo salón de conferencias), mostrar datos de Fusion Tables en mapas. Esta versión también tiene como novedad que no se utilizan más las API keys y que Internet Explorer 6 quedó excluido del soporte.
  
  Presentaciones:
  - The Google Maps API V3
  - Google Geo: New Features and Tools (las dos presentaciones están realizadas en HTML5/CSS3 y solo se ven en Google Chrome)
  
  
• Charla sobre Chrome Web Store: De las cosas que ya leemos en todos lados (que las aplicaciones en el navegador son la evolución de las aplicaciones de escritorio, que Google Chrome OS es el sistema operativo del futuro, etc) Eric Bidelman dejó en claro que los desarrolladores somos libres de hacer las aplicaciones para la Web Store con las tecnologías que queramos (HTML5, Flash, Silverlight, JavaScript, LAMP…) y que podemos ofrecerlas como queramos (gratis, pagas, por suscripción, freeware, etc).
• Charla sobre Google Apps APIs: Tal vez la presentación que menos conceptos tenia, sin embargo me di cuenta que hay un gran nicho para aprovechar y que con un poco de ingenio se puede ganar algún dinero. Fue muy interesante la demostración de un sistema de timesheet, en donde desde el mismo mensaje de GMail se podía completar un formulario de Google Docs (el widget se mostraba de forma contextual, entendiendo el email en donde se le pedia al usuario completar las horas de trabajo). También una demo de un sistema de tickets, en donde desde el mismo excel de Google Docs se podía enviar emails de notificación. Realmente muy interesante para desarrollar aplicaciones para empresas.

En conclusión, el evento fue muy interesante y muy bien organizado, pero hay que recordar que Google no lo es todo (existe vida después de Google!). Me hubiera gustado aportar alguna opinión sobre el primer día del evento, en donde se habló full time sobre Android, pero como no soy experto (y mi único contacto con Android es tener un celular con el sistema) mucho no puedo aportar!

Más links e información que se mostraron en el evento

Presentaciones de Google Storage, BigQuery, Prediction APIs y Appengine.

Web del evento y Google Argentina en Twitter.

Asi que ya terminaste el sitio web… comprimiste todos los CSS y JS, escribiste el HTML de forma semántica, usaste sprites para las imágenes, agregaste las reglas en .htaccess, optimizaste las consultas a la DB, tienes un “A” sobresaliente en Yslow y Page Speed, todo es perfecto… justo cuando en ese momento viene el departamento de marketing y/o jefe directo y te dice:

Necesitamos agregar banners en la página (varios) También incorporar el tracking de visitas… y medir cómo estan funcionando nuestras campañas online

Nosotros, cumplimos ordenes, pero vaya sorpresa que al probar de nuevo el sitio, el “A” sobresaliente pasa a ser un “D” rotundo:

• La página aumentó en tamaño un 30% debido a los banners SWFs
• Observamos una subida en la cantidad de peticiones a servidores externos (llamados a distintos JS de tracking)
• A su vez estos scripts, resultan ser bloqueantes, por lo cual el tiempo de carga y renderizado también aumenta

Vemos (¿con un poco de impotencia?) como el trabajo que realizamos en optimización ya no se ve tan reflejado (y ni hablar cuando alguien dice – La página tarda mucho en cargar…–)

Ante esta situación no tenemos muchas alternativas, pero aquí van un par de consejos:

• No sugerir opiniones extremistas como - Debemos sacar toda la publicidad -, la web de algún lado tiene que mantenerse (monetariamente): Si no hay dinero, no hay página y si no hay página, no hay trabajo!
• De la misma forma, debemos hacer entender que una sobrecarga de publicidad perjudica la experiencia del usuario, lo mejor es buscar un balance, ya que puede ocurrir que el usuario ingrese menos seguido al sitio o comience a bloquear la publicidad, y si se reducen las visitas, hay menos clicks.
• Sugerir un peso máximo para los banners, pero por sobretodo que se respeten. Los banners por lo general son SWFs y alguién que haya trabajado con Flash conoce (o deberia conocer) técnicas para bajar el peso de los archivos (utilizar imágenes vectoriales, optimizar el código AS, disminuir el uso de imágenes de mapa de bits, etc). En la web de IAB existe una tabla con pesos sugeridos para los distintos tamaños.
• Si se está contratando un servicio de adserver, verificar que se está utilizando la última versión del JS que inserta los banners. De igual manera, si se usa un adserver interno, ya que entre versiones puede cambiar drasticamente la velocidad de inserción.
• Si finalmente se va a mostra publicidad de forma severa, podemos optar por alguna alternativa no convencional, por ejemplo, existe un plugin para jQuery que permite mostrar/cargar los banners solamente cuando se encuentran en el viewport del usuario: jQuery LazyLoad Ad. Si van a implementar esta solución, les tengo tres palabras: Testing, testing y testing. Esten seguros que todo funciona de forma correcta y no existen conflictos: una baja en las estadísticas de visualización y clicks se va a notar enseguida (y la furia caerá sobre nosotros).
• Con respecto al tracking de Google Analitycs, es de los más optimizados (sobre todo con la versión asíncrona). También hace un tiempo habia leido sobre cómo servir los JS de GA de forma local, no sé si existirá una mejora considerable pero se podria tener en cuenta.
• Tal vez una solución íntegra puede ser utilizar Gatling Analytics, (también) un plugin para jQuery que permite a través de su API, centralizar las llamadas a diferentes sistemas de tracking (GA, Chartbeat, Bing, Facebook) y hacerlas de forma asincrónica. No tuve oportunidad de probarlo, pero suena interesante y como decia antes, realizar testing.

¿Algún consejo más? ¿Alguna experiencia similar? ¿Otra solución que no dependa de jQuery? Puedes sugerirlo a travéz de Twitter!