Scriptia. Javascript y buenas prácticas en español



Scriptia / artículos / De cómo comprimir ficheros javascript

De cómo comprimir ficheros javascript

Saltar a Anotaciones relacionadas

Ahora que javascript comienza a perder la fama de lenguaje maldito y las aplicaciones web, repito, aplicaciones web son el pan nuestro de cada día (porque las usamos y porque _comemos_ de ellas), la velocidad de descarga de los ficheros .js _debe_ preocuparnos.

En [Serving JavaScript Fast][0], Carl Herlson, de Flickr, habla largo y tendido sobre diferentes métodos para acelerar la carga de scripts y hojas de estilo (combinación, compresión, cacheado).

Aquí y hoy, nos vamos a centrar en la compresión de ficheros `.js`.

## Servicios en línea

Puedes comprimir/ofuscar tus scripts en línea con una de estas herramientas:

* [packer][1], de Dean Edwards. Pegas o subes tu código, pinchas un botoncito y, _voilà_, código comprimido. Utiliza expresiones regulares para obtener un código realmente ininteligible obteniendo una compresión de 0.4 a 0.6.

* [ShrinkSafe][2], del proyecto Dojo. Subes tu fichero o ficheros, y gritas con fuerza _shrink em!_ (o pulsas el botón, como prefieras). Aunque el nivel de compresión no es tan bueno como el obtenido con packer, el resultado es más seguro, puesto que ShrinkSafe no utiliza expresiones regulares sino un intérprete de javascript (Rhino).

## Háganlo en sus propias casas

Hagámoslo más fácil. Comprimamos desde la línea de comandos.

En el [sitio web de Dean Edwards][3] tenemos disponibles para descarga tres versiones, tres, que permiten utilizar [packer en la máquina de cada cual][5]. Dos de ellas (perl y WSH) resultan de lo más útiles para nuestra línea de comandos.

Servidor, que usa Windows, ha tomado la versión WSH y se ha currado un proceso por lotes (`build.bat`) tal que:

cscript /nologo pack.wsf validatorrr.js 62 1 1 > validatorrr-p.js

De esta manera, solo tengo que teclear `build` para obtener una versión comprimida de `validatorrr.js`. Antes: 11.997 bytes, después 4.796 bytes.

Mejor que las cremas adelgazantes, oiga. Y barato, muy barato.

Para maceros y linuxeros, supongo que la versión en perl (que no he probado) ofrecerá ventajas similares. Así que si no comprimes es porque no quieres. No hay excusa.

**Ojo:** Nueve de cada diez dentistas recomiendan utilizar un sistema de control de versiones para no perder jamás de los jamases la versión no ofuscada de script alguno.

[0]: http://www.thinkvitamin.com/features/webapps/serving-javascript-fast
[1]: http://dean.edwards.name/packer/
[2]: http://alex.dojotoolkit.org/shrinksafe/
[3]: http://dean.edwards.name/
[5]: http://dean.edwards.name/download/#packer



10 comentarios RSS

1 Pongamos a dieta nuestro Script.aculo.us (18KB) - aNieto2K (2006-09-24 @ 2:35 pm):

[...] Compactamos el fichero resultante con jscompact (para linux), y para windows podemos hacerlo de otras formas [...]

2 choan (2006-10-07 @ 7:09 pm):

Para que venga alguien y pregunte.

Si te molestaras en leer el artículo que enlazo al principio del post (o tuvieras experiencia en servir ficheros gzipeados) sabrías que servir ficheros con gzip puede ser problemático (carga extra tanto en servidor como en cliente).

Para más INRI, IE tiene sus propios problemas con el contenido gzipeado.

3 choan (2006-10-10 @ 9:38 pm):

Jarfil, si a ti el gzip no te da ningún problema, enhorabuena. Yo he sufrido por su causa momentos de pánico que no recomiendo a nadie.

En cuanto a tus argumentos:

  • carga excesiva en cliente: no considero que descomprimir con packer sea más costoso que con gzip (no puedo probarlo, no me lo pidas). Por otra parte, obvias que el servir con gzip también genera carga en el servidor.
  • fallos generales del compresor: ShrinkSafe utiliza un intérprete de javascript para realizar las sustituciones de nombres de variables y demás. packer es lo suficientemente seguro si se escribe el código como dios manda.
  • ralentización del ciclo de pruebas: solo si tu quieres. Puedes realizar unit tests tanto sobre el código comprimido como sobre el código sin comprimir.
  • bugs sorpresa == fallos generales del compresor ? está respondido : no sé a qué te refieres

En cuanto a la solución, el problema no es del servidor. De lo que se trata es de que el código llegue cuanto antes al cliente. Y hay clientes lentos, doy fe. ¿Ninguno de tus conocidos usa una conexión por módem telefónico?

Pues bien, puede que ahorrarle un segundo a un usuario no suponga nada. Ahora cuenta tus usuarios en miles, millones al día. Merece la pena ahorrar tráfico. Si prefieres –y puedes, puesto que no todos los servidore te lo permiten– hacerlo con gzip, a mí plim.

MilVidas: un archivo .js puede llegar a pesar lo suficiente como para retrasar considerablemente la carga de la página.

En cuanto a tus dudas y miedos, lo mismo que le decía a Jarfil, considero que los dos scripts de los que hablo están lo suficientemente testeados (y siempre queda la posibilidad de utilizar tests automatizados).

Hale, salud.

4 Kr0n (2007-05-24 @ 12:10 pm):

Aunque sea un post antiguo, una pregunta que me ha surgido:

A que te refieres con que es más seguro porque no usa regexp?

5 choan (2007-05-24 @ 12:22 pm):

Quizá «seguro» no sea el término más apropiado. Quizá sería mejor decir «confiable».

El hecho es que ShrinkSafe utiliza Rhino (el intérprete de javascript de Mozilla) para interpretar el código. Y un intérprete de javascript entiende mejor el código que cualquier expresión regular, por muy currada que ésta esté.

¿Se entiende ahora?

6 Kr0n (2007-05-24 @ 6:31 pm):

Si, mucho mejor. De hecho estaba entendiendo que utilizaba Rhino no para interpretar el código y reescribirlo comprimiéndolo, sino que lo comprimía en base a Rhino y por tanto este era necesario para luego interpretarlo. Paja mental.

Y si, te doy la razón, para un interprete el código tiene un significado semántico mientras que para una regexp no.

Gracias por la aclaración.

7 YUI Compressor comprime tus scripts y tus hojas de estilos - Scriptia (2007-09-09 @ 5:54 pm):

[...] hemos hablado por aquí de cómo comprimir ficheros javascript. Pero aún no está todo dicho. Hoy y aquí, YUI [...]

8 Zenhaust (2007-09-11 @ 11:35 pm):

Conozco el gran trabajo de Dean Edwards. El problema que encuentro es que el código no es para nada ilegible. Basta con escribir el resultado de la funcion de desempaquetado en el body de una nueva ventana y voila.
No obstante creo que resulta enormemente interesante combinarlo con CopyRightParser (made in spain). En este sitio se modifica el código de forma que solo funcione para el dominio especificado, evitando la portabilidad del mismo. Además puede añadirse una linea de copy right visible y muy difícil de eliminar. Con esto no solo se empaqueta el código, sino que además se protege la autoría del desarrollo, de forma que su distribución corresponda única y exclusivamente al autor, y no a terceras personas ajenas al desarrollo del mismo y sin permiso expreso del propietario.

9 choan (2007-09-13 @ 2:15 pm):

@Zenhaust: tu comentario es irrelevante al tema, aquí se habla de compresión, no de ofuscación ni de protección de derechos.

La próxima vez que quieras publicitar un producto, envíame la referencia y, si me da la santa gana, escribiré un post. Comentarios publicitarios como este no deberían tener cabida en Scriptia. Pero como hoy estoy medio dormido, lo dejo pasar.

10 Comprimir archivos javascript - Blog Comunitario (2008-01-19 @ 12:49 am):

[...] En el siguiente link hay un artículo interesante que nos puede guiar en el tema de la compresión de archivos js /articulos/2006/07/de-como-comprimir-ficheros-javascript.html  [...]


Acerca de Scriptia

Saltar a la caja de búsqueda

Scriptia forma parte del PDM de Choan C. Gálvez, desarrollador web residente en Barcelona. Scriptia pretende mejorar la calidad de la documentación acerca de javascript disponible en español.