Etiqueta: yahoo

Las aplicaciones web cada vez son más complejas. Cada vez se requiere más código Javascript que permita obtener la funcionalidad deseada. Debido a esta necesidad, y al igual que sucedió con las librerías en los sistemas operativos, han ido surgiendo varias librerías de código Javascript. Estas, además de descargar al programador de codificar tediosas rutinas para el acceso al DOM y similares, proporcionan una capa de abstracción que permite la portabilidad del código a distintos navegadores. Para los profanos, explico la situación. Hoy por hoy existen diversos navegadores web, siendo probablemente el Firefox, Internet Explorer, Safari y Opera los más importantes. Cada uno de estos navegadores implementa el motor de renderizado web de forma distinta. Algunos de ellos se ciñen a los estándares oficiales, mientras que otros deciden introducir sus propios elementos xhtml, html, etc al margen del resto. Esto genera graves problemas de interoperabilidad para las páginas web. Un diseño que emplea ciertos elementos CSS, es probable que no funcione como se deseaba al visualizar la misma página en otro navegador. Existe una problemática adicional, cada navegador luego tiene sus múltiples versiones que soportan subconjuntos diferentes de los estándares, agravando los problemas de interoperabilidad.

Las librerías Javascript proporcionan una capa de abstracción para el programador y le evita tener que programar distintas versiones del mismo código para los distintos navegadores. Dos de las más famosas probablemente sean la librería jQuery y Prototype. Sin embargo, a diferencia de las librerías de un sistema operativo, éstas otras han de ser descargadas (si no han sido cacheadas, lo que sucede el 50% de las veces) por cada usuario que visualice la web. Esto supone un problema de rendimiento, ya que el navegador no comenzará a hacer uso del código Javascript hasta que este haya sido descargado. Cuanto mayor es el tamaño de la librería, peor es el rendimiento.

Para evitar estos problemas de rendimiento, voy a introduciros una herramienta desarrollada por Yahoo para reducir considerablemente el tamaño de estas librerías y maximizar la velocidad de carga de la web. La herramienta, que se llama YUI Compressor es una aplicación Java (jar) a la que le damos el fichero Javascript de entrada y nos devuelve por la salida estándar una versión comprimida de la misma. A continuación os muestro las prueba que he realizado con la última versión de jQuery:

ergosum@braniac:/var/www/js$ ls -la jquery-copy-1.2.2.js
-rw-r–r– 1 ergosum ergosum 95285 feb 8 16:49 jquery-copy-1.2.2.js

ergosum@braniac:/var/www/js$ java -jar yuicompressor-2.3.4.jar jquery-copy-1.2.2.js > jquery-compress-1.2.2.js

ergosum@braniac:/var/www/js$ ls -la jquery-compress-1.2.2.js
-rw-r–r– 1 ergosum ergosum 52435 feb 8 16:51 jquery-compress-1.2.2.js

Como podemos apreciar, al comprimir la librería hemos obtenido una tasa de compresión del 45%, lo cual es increíble. El problema con el algoritmo de compresión es que convierte la librería en algo bastante ilegible. Si deseamos reducir el tamaño del código pero al mismo tiempo mantener algo de coherencia y no ofuscarlo, podemos lanzar la herramienta como sigue:

ergosum@braniac:/var/www/js$ java -jar yuicompressor-2.3.4.jar –nomunge –preserve-semi jquery-copy-1.2.2.js > jquery-compress-1.2.2.js

ergosum@braniac:/var/www/js$ ls -la jquery-compress-1.2.2.js
-rw-r–r– 1 ergosum ergosum 52970 feb 8 17:21 jquery-compress-1.2.2.js

Podemos comprobar la opción para añadirle los puntos y comas el tamaño ha incrementado ligeramente (44.41% de compresión). Sin embargo he de reconocer que no sale mucho más legible que antes. También podemos añadirle el parámetro –line-break n indicándole al parser que debe añadir un retorno de carro cuando llegue a la línea n. Esto lo hace algo más legible pero no mucho más.

Como nota adicional, leía ayer los resultados que han obtenido la gente de PBWiki (muy interesante por cierto) con distintas herramientas para el rendimiento de las librerías. Para jQuery obtuvieron los siguientes datos:

Minified	Time Avg	Samples
minified	519.7214	12611
packed	591.6636	12606
normal	645.4818	12589

Donde minified corresponde a la salida comprimida mediante la herramienta que hemos comentado, packed corresponde con librerías comprimidas con el empaquetados Packed y por último normal corresponde con la librería tal cual, sin procesar.

Se aprecia claramente como la minified es más óptima que la packed y la razón es porque, aunque con Packed el tamaño del fichero es menor, es necesario realizar un esfuerzo extra para desempaquetar el fichero una vez que llega al navegador, resultando en una suma total de tiempo mayor que en el caso del minified.

En conclusión, una herramienta muy útil que nos permite minimizar el tiempo de carga de nuestras librerías Javascript. Además de la compresión también podemos usar recursos como el mod_gzip para comprimir el archivo desde el servidor a nuestro navegador y seguir ganando en eficiencia.