ASP.NET MVC 4 – Minification and Bundling

Una de las nuevas features de ASP.NET MVC 4 es la de minification and bundling (también denominada web optimization), la cual nos permite compactar y agrupar archivos de Javascript y CSS en nuestra aplicación o sitio web. Esta característica es proporcionada por la librería System.Web.Optimization, que tenemos disponible por default en nuestros proyectos a partir de la versión RC de ASP.NET MVC 4.

Un punto importante, es que a partir de esta feature surge un nuevo concepto, los bundles:

Bundle es simplemente una agrupación lógica de archivos que se pueden referenciar mediante un único nombre, y que se cargan en una única petición HTTP.

La agrupación (bundling) generalmente incluye uno o más archivos de scripts JS o CSS relacionados entre sí. Estos archivos son compactados y optimizados permitiéndonos descargarlos por única vez del servidor ahorrándonos varios request.

La compactación (monification) se realiza en el server y ocurre una única vez, este proceso elimina todos los espacios y saltos de líneas de los archivos incluidos en el paquete (bundle), ademas de renombrar todas las variables por nombres muchos más simples y pequeños. El resultado final: archivos muchos más livianos que ofrecen una mejor performance en el cliente.

Ahora veamos de que se trata esto de Bundles. Si generamos una nueva Web Application ASP.NET MVC 4 podremos ver en ciertas vistas algo similar a lo siguiente:

Utilizando bundles

Utilizando bundles

En este punto, le estamos diciendo a la vista es que utilice bundles, previamente definidos, para los estilos @Style y para los scripts JS @Scripts (veremos más adelante donde definir los paquetes). De esta forma ya no es necesario registrar estos recursos utilizando los tags <scripts> o <styles>.

Si prestan atención al ejemplo, le estamos pasando como parámetros  al método Render() la ubicación y nombre del bundle. Dicha definición del paquete (nombre, path y archivos que lo componen), se realiza en la clase BundleConfig (App_Start\BundelConfig.cs):

BundleConfig

BundleConfig

Los bundles serán generados por única vez cuando se inicie la aplicación. En el método Application_Start() del global.asax encontrarán la inicialización de los mismos:

BundleConfig.RegisterBundles(BundleTable.Bundles);

La definición de un nuevo bundle es bastante simple: creamos un objeto ScriptBundle y le pasamos como parámetro el “path virtual” (ubicación y nombre del paquete), el cual nos permitirá identificarlo desde las vistas. Acto seguido, indicamos que archivos vamos a incluir en el paquete. Existen ciertos atajos para poder especificar los archivos que componen un paquete, podemos utilizar por ejemplo el * para indicar el conjunto de archivos que comienzan con el mismo nombre: jquery-1.*.

Algunos puntos importantes, del mecanismo de bundles. Uno es que tanto los versiones de scripts JS para documentación o previamente minificadas (*.min.js, *-vsdoc.js, *.debug.js) son “descartados” al momento de la compactación. Otro es que el orden en que registramos los archivos dentro de un bundle son respetados al momento de generar el paquete, lo que evita problemas de referencia entre scripts.

Sin embargo, cuando ejecutemos nuestra aplicación nos vamos a encontrar con que ninguna de las características mencionadas anteriormente se hicieron efectivas:

Request realizados al servidor

Request realizados al servidor

Pero a no preocuparse!. Para poder implementar esta feature, simplemente debemos des-habilitar el modo “debug”. Para eso simplemente modificamos la entrada compilation en el archivo web.config:

Modificando el modo de compilación

Modificando el modo de compilación

Esto es así, ya que en el ambiente de desarrollo generalmente necesitamos depurar nuestros archivos de scripts o css, y no tiene sentido el uso de bundles. Sin embargo, si quisiéramos forzar su uso sin afectar el modo de compilación, podemos hacerlo de la siguiente manera (en el método Application_Start() del global.asax):

BundleTable.EnableOptimizations = true;

Ya sea modificando el web.config o habilitando la propiedad BundleTable.EnabledOptimization, si ejecutamos nuevamente la aplicación nos encontraremos con lo siguiente:

Request realizados al servidor

Request realizados al servidor

Como podemos ver, ya no fueron necesarios 15 request para obtener todos los scripts y css. Con solo 4 request trajimos los paquetes compactados y optimizados.

Si revisamos en detalle los archivos que fueron descargados en cada request, podemos ver que tanto el nombre como la ubicación de los paquetes son los que definimos como “path virtual”:

Ubicación y nombres de los bundles

Ubicación y nombres de los bundles

Pero esto no es todo, si volvemos a solicitar la página, vamos a encontrarnos con que los paquetes se encuentran en cache – HTTP Status Code 304 – Not Modified -, por lo que ya no es necesario volver a solicitarlos! 🙂

Cache de Bundles

Cache de Bundles

Inspeccionando un poco más la petición del bundle, se puede observar que a la URL se añade un parámetro “v” con un valor hash. Este es utilizado para identificar cuando un paquete fue modificado, y por lo tanto es necesario volver a buscarlo nuevamente en el servidor.

Como podemos ver, el mecanismo de bundles, no solo se trata de agrupar o compactar archivos. También nos permite manejar de una manera transparente cuestiones como la cache o cambios de versión de los recursos, que a veces son pasadas por alto.

Por último les dejo un par de post excelentes sobre el tema de José M. Aguilar, Scott Hanselman y Rick Anderson.

Espero que les sea de utilidad!