Cómo acelerar nuestras aplicaciones web

Desde hace ya tiempo la mayoría de las aplicaciones que desarrollamos son aplicaciones web. Incluso el límite entre aplicaciones web y de escritorio es cada vez más difuso, entre nuevas tecnologías basadas en plugins como Flash, Silverlight o Unity, y el incremento de poder del lado de HTML y Javascript, incluyendo también soporte offline y otras características.

Sin embargo, la web, por las maravillas de la diversidad que la hacen fabulosa, también es un océano de calamidades desde el punto de vista del diseño e implementación de las aplicaciones que encontramos en ella.

A esta altura la mayoría de nosotros debería conocer las recomendaciones y herramientas básicas para optimizar los tiempos de respuesta de nuestras aplicaciones, pero nunca está de más repasarlas.

La mayor parte de estas recomendaciones surgen del trabajo de Steve Souders, iniciado cuando era el Chief Performance en Yahoo!, antes de continuar esta labor desde Google, y compilado en dos libros que ya debería considerarse como obligatorios para cualquier desarrollador que tenga que tocar algo en la web:

High Performace Web Sites (de 1997) y Even Faster Web Sites (de 2009)

La mayoría de estas reglas pueden verse en detalle en el sitio para desarrolladores de Yahoo, especialmente en la sección de Mejores Prácticas para acelerar un Sitio Web o su equivalente en Google, Mejores prácticas de rendimiento Web.

Dejo un resumen rápido de algunas recomendaciones, para que se den una idea antes de zambullirse en la lectura de todo ese material.

Minimizar peticiones HTTP

• Combinar archivos es una manera de reducir peticiones, por ejemplo, unificando las hojas de estilo y scripts
• Utilizar Sprites CSS para combinar muchas imagenes en una sola y descomponerla en la página

Utilizar redes de distribución de contenido (CDNs)

Esto no aplica a cualquier sitio, porque implica un costo, pero cada vez aparecen más alternativas económicas o embebidas directamente sobre alguna plataforma más amplia.

Agregar expiración o control de cache en la cabecera

Tanto en contenido estático como dinámico, manejando apropiadamente estos mecanismos podemos lograr que el browser descargue una única vez los recursos que no varían. Esto es particularmente efectivo en cosas como imágenes, hojas de estilo, scripts, etc, pero también se puede lograr mantener la mayor parte del HMTL utilizando mecanismos de fragmentación para separar el contenido que realmente varía.

Comprimir componentes con Gzip

Esta es una de las recomendaciones que es casi gratuita. La mayoría de los navegadores modernos soportan este tipo de compresión que es estándar, lo mismo que casi todos los servidores web. Sólo implica indicar que debe ser utilizada al hacer las peticiones.

Ubicar las hojas de estilo arriba de la página

Ubicar los estilos en la cabecera del HTML hace que la carga de la página se perciba más rápida porque permite que suceda progresivamente.

Ubicar los scripts al final de la página

La descarga de los scripts genera muchas veces un freno a la descarga en paralelo de otros elementos, porque supo que parte del código puede estar escribiendo parte del contenido de la página. Hay varias técnicas para evitar el problema y mejorar el rendimiento general.

Evitar expresiones CSS

Estas expresiones permiten asignar valores dinámicos a propiedades de los estilos, pero esta es una operación peligrosa y lenta, por lo que se la convirtió en obsoleta.

Los scripts y hojas de estilo deberían ser externos

Independizar estos recursos mejorar usualmente el rendimiento porque además de poder paralelizarse la descarga, estos son recursos ideales para permanecer mucho tiempo en la cache del navegador.

Reducir la cantidad de búsquedas en los DNS

Esto es algo en lo que hay que mantener un balance. Las búsquedas en los servidores de nombres son mantenidos en cache por los navegadores por varios minutos, porque son una operación relativamente costosa. De todas maneras, cierta distribución de recursos en diferentes dominios también ayuda a paralelizar las descargas, ya que los navegadores tienen un límite de cantidad de descargas en paralelo por cada dominio.

Minificar JavaScript y hojas de estilo

Esta práctica implica compactar en ambos casos la cantidad de caracteres en uso para todos los recursos internos como estilos, variables y nombres de funciones, al igual que reducir la cantidad de espacios opcionales e indentación. Esto hace que el resultado parezca críptico, pero puede resolverse en una etapa posterior al desarrollo, como parte del despliegue (utilizando JSMin y YUI Compressor, por ejemplo), de modo que dentro del ciclo de vida de un proyecto nadie tenga que leer las versiones minificadas.

Evitar redirecciones

Aunque este es un recurso útil en ciertos casos, su abuso genera demoras y una experiencia poco prolija, que es difícil de optimizar.

Remover scripts duplicados

Aunque parezca obvio, la cantidad de sitios que incluyen mas de una vez el mismo script en una página es enorme. En parte, si se trabaja fuertemente en la unificación de los scripts, las posibilidades de que esto suceda disminuyen inmediatamente.

Configurar ETags

A pesar de que los ETags son un mecanismo para evitar transferir recursos ya existentes, implementaciones divergentes de este estándar en distintos servidores terminan generando que algunos recursos se descarguen siempre, sin importar si ya están actualizados en el navegador. Es importante revisar la manera en que funcionan y estar seguro que lo hacen correctamente.

Hacer que las llamadas AJAX utilicen la cache

Aunque esta técnica de pedir datos de manera asincrónica sin tener que reenviar toda la página está pensada para minimizar el tráfico, es importante aplicar muchas de las recomendaciones anteriores a estos casos también. Esto implica hacer que las respuestas generalmente dinámicas de estos servicios utilicen los mismos mecanismos para evitar el reenvío de respuestas que ya llegaron antes al navegador y cuyo contenido no cambió.

 

¿Cómo controlar y validar estas reglas?

Aunque la lista pueda amedrentarnos en principio, ya hay varias herramientas disponibles para ayudarnos en este camino, como la clásica YSlow (un plugin de FireBug, que a su vez es un plugin para FireFox). Va como muestra una captura del análisis de YSlow en este blog (para que vean que todos cometemos pecados).

Google, por su parte, tiene también una extensión similar pero con algunas características particulares, llamada PageSpeed, producto de la mudanza de Souders. Notablemente esta extensión también es para FireBug, por lo que corre en FireFox, no en Chrome.

Finalmente, Google ha publicado también el módulo mod_pagespeed para Apache, que aplica muchas de las reglas automáticamente, al preprocesar scripts y hojas de estilo, unificando y minificándolas, optimizando imagenes, etc.

Es interesante ver que GoDaddy, el principal registrador de domininos y una de las principales empresas de hosting en el mundo, ha empezado a activar este módulo en todos sus servidores Apache, produciendo mejoras significativas en muchísimos de sus cliente de manera casi mágica.

 

Agiles @ Buenos Aires: Coding Dojo

El grupo Agiles.org organiza actividades de varios tipos en muchos puntos de América Latina.

Esta comunidad surgió fuertemente tras la primera edición de la conferencia latinoamericana Agiles 2008, y a partir de ahí el grupo en Argentina quedó consolidado, realizando muchas actividades por todo el país (anunciadas en la página Agiles Argentina).

Específicamente en Buenos Aires, se efectúan reuniones todos los meses, que se anuncian en la página Agiles@BsAs.

La próxima reunión es el martes que viene, 8 de febrero, en las oficinas de Southworks (Perú 375, 1er piso).  [disclaimer: es donde yo trabajo]

Lo interesante de esta próxima reunión en particular es que va a ser un Coding Dojo (estilo Randori), facilitado por Adrián Eidelman.

En palabras del propio Adrián:

"Un coding dojo es una sesión de codificación centrada alrededor de un desafío de programación. El desafío es sumamente pequeño en alcance y -en la versión Randori de un coding dojo- la totalidad de la audiencia participa para completarlo. Básicamente la solución se construye utilizando una única computadora y un proyector, en donde los desarrolladores van rotando de a pares cada una cantidad fija y acotada de tiempo, dejando lugar a que otras personas de la audiencia continúen. El objetivo es aprender, enseñar y mejorar nuestras habilidades de programación compartiendo con otros desarrolladores de software en un ambiente relajado."

La actividad como siempre es totalmente abierta y gratuita pero requiere inscripción previa, y vale la pena decidirse rápido porque el espacio no es infinito.

Espero ver a muchos de ustedes la semana que viene, codeando, y espero poder capturar en video todo lo que se pueda de la actividad, para compartir con quienes no puedan asistir.

 

Programando en Windows Azure con el Maestro Angel "Java" López

En la última reunión VAN (Virtual Alt.Net) de Alt.Net Hispano, el Maestro presentó una profunda sesión sobre programación en la plataforma de cloud computing de Microsoft. Para quienes quieran saber más sobre este grupo, pueden leer este post previo.

En esta sesión, como siempre, registrada en video (disponible más abajo), el Maestro @ajlopez recorre los conceptos básicos de Windows Azure, el SDK correspondiente para poder programar aplicaciones para esa plataforma, las opciones de computación (roles web y roles de trabajo), y las alternativas de almacenamiento (tablas, blobs y colas).

Pero lo más jugoso es ver en acción la manera de programar, sobre todo a través de los ejemplos e ideas del Maestro, que sabe mantener el interés con buen nivel de detalles y muy buen humor.

Tras las sesión, hubo en la lista de Alt.Net hispano un mensaje de Eugenio Pace, Sr. Program Manager en Microsoft patterns & practices, que desde Redmond mandó felicitaciones por la sesión y aprovechó para puntualizar algunos detalles que Angel dejó planteados, para beneficio de los asistentes.

Antes de dejarles el video, aviso para todos los que estén interesados en profundizar en el tema y estén alrededor de Buenos Aires, que Angel va a dar un seminario gratuito de dos días sobre Azure, el 15 y 17 de febrero, en el Grupo de Usuarios Microsoft de Argentina.

Que lo disfruten:

Leisure Suit Larry en HTML5

La aparición de nuevas librerías para gráficos y animación en HTML5 / JavaScript han posibilitado una avalancha de regresos a juegos clásicos que se adaptan bien a ser ejecutados en el browser.

Y aunque ya se pueden encarar estilos más ambiciosos, los clásicos siguen volviendo. Esta vez encontré una versión sumamente fiel de un clásico de los 80: Leisure Suit Larry. Para quienes lo jugaron en aquella época o m's tarde, ya que su popularidad lo mantuvo vivo bastante tiempo, he aquí una oportunidad de revivir esos momentos sin tener que recurrir a la virtualización.

Algo interesante de este juego y otros clásicos disponibles en el mismo sitio, es que están autorizados por las compañías que mantienen los derechos de los juegos originales, Activision y CodeMasters.

Pero además están construidos sobre un par de componentes  para juegos licenciado bajo GPL o MIT, y disponibles en Google Code:

• El intérprete Sarien.Net, que es una implementación sobre el browser del motor original usado por Sierra On-Line para los juegos originales Space Quest, Police Quest y el de Larry.
  
  
• El motor multiplayer Q42 es una plataforma multi-usuario sumamente liviana para juegos basados en el browser, siempre por puerto 80. El API cliente son 5K de JavaScript, y el servidor es una clase en C# que puede embeberse o referenciarse como una DLL externa (imagino que probablemente pueda correr en Mono, pero habría que probarlo).
  
  El motor implementa básicamente un mecanismo de chat con salas separadas, escalamiento automático, liberación de salas vacías, propiedades por usuario como nombre y posición (x,y), mensajería y soporte para múltiples usuarios por sesión, lo que permite mantener usuarios distintos en tabas separados del mismo browser, por ejemplo.

Espero que alguno se divierta con esto, jugando o programando.

Meditación programática: Koans

Los Köan (pronunciación japonesa del chino 公案) o Koan, son ejercicios mentales de la meditación Zen, consistentes en diálogos o preguntas que plantean un problema que muchas veces no tiene respuesta directa. El objetivo de un Koan es el aprendizaje durante el proceso de elaboración de la respuesta, más que la respuesta en sí.

Un ejemplo clásico es la pregunta: "Cuando dos manos aplauden hay un sonido. ¿Cuál es el sonido de una sola mano?".

Tomando esta idea como base, de manera similar a la idea de los Code Katas que comentaba en un post reciente, diferentes personas empezaron a generar Code Koans para diferentes lenguajes. Como siempre, la adaptación es libre y no sigue exactamente los mismos principios, sino que e inspira en la idea motora.

Los Koans dentro del campo de la programación parten del objetivo de comenzar con conceptos sumamente básicos y realizar ejercicios generalmente abiertos, pero que frecuentemente llevan a la necesidad de experimentar o investigar un poco más allá del alcance mismo del planteo.

Hay colecciones de Koans para varios lenguajes, entre ellos Ruby Koans (Jim Weirich y Joe O'Brien), JavaScript Koans (Liam McLennan), .NET Koans (Cory Foy) y los Clojure Koans (Aaron Bedra).

La mayoría de estos proyectos están inspirados en el primero, los Ruby Koans, de los que incluyo algunos ejemplos para que se entienda el concepto general.

Los Koan suelen estar agrupados por temas, por ejemplo en los de Ruby, hay series para arrays, blocks, clases, excepciones, módulos, strings, y muchas más.

Los Koans se basan siempre en la práctica de Test-Driven Development (curso gratuito en español disponible), donde las "preguntas" están formuladas como tests, que el aprendiz debe implementar y pasar. La diferencia con TDD tradicional es que el test principal ya está escrito (lo que no significa que no podamos agregar más).

Lo primero a ejecutar en los Ruby Koans es (desde la línea de comandos):

$ ruby path_to_enlightenment.rb

y el resultado es algo como:

AboutAsserts#test_assert_truth has damaged your karma.

The Master says:
  You have not yet reached enlightenment.
  Do not lose hope.

The answers you seek...
  Failed assertion, no message given.

Please meditate on the following code:
  /Users/ . . . /koans/about_asserts.rb:10:in `test_assert_truth'

mountains are merely mountains
your path thus far [X_________________________________________________] 0/274

El mensaje juega con el estereotipo del Maestro Zen y el estilo de los consejos, pero más allá de eso, nos da un indicio: nos dice que meditemos en el método test_assert_truth dentro del archivo about_asserts.rb. Si abrimos este archivo y lo miramos, encontramos este test donde el motivo de la falla es más que obvio:

  # We shall contemplate truth by testing reality, via asserts.
  def test_assert_truth
    assert false                # This should be true
  end

Al cambiar a assert true y ejecutar de nuevo, obtenemos un mensaje similar sobre el siguiente test que falla, y otra frase Zen diferente para inspirarnos. Por supuesto, a medida que avanzamos la respuesta es menos evidente que cambiar un false a true. El primer ejercicio solamente sirve para que entendamos el procedimiento.

En varios casos, la manera de resolver el test no es evidente y tenemos que buscar más información en libros o en la web, pero esto es lo que buscan los Koans: forzarnos a aprender algo, pero siguiendo baby steps.