¿Es una buena práctica tener un paquete por vista en Asp Net MVC?

Dado que la agrupación y la minificación tienen que ver con la optimización y hacer que las páginas se carguen más rápido, me parece lógico crear un paquete para scripts y un paquete para estilos por vista, de modo que para cargar todos los scripts y estilos un navegador necesitará para hacer 2 solicitudes como máximo. Digamos que tengo un _Layout.cshtmlarchivo donde necesito 3 js bootstrap.js, jquery.jsy algunos custom1.jspuedo crear un paquete, algo como esto:

bundles.Add(new ScriptBundle("~/bundles/layout").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom1.js"));

Entonces digamos que tengo otra vista User.cshtmldonde necesito bootstrap.js, jquery.jsy custom2.js, de nuevo puedo crear un solo paquete:

bundles.Add(new ScriptBundle("~/bundles/user").Include(
          "~/Scripts/bootstrap.js",
          "~/Scripts/jquery.js",
          "~/Scripts/custom2.js"));

Se puede usar el mismo enfoque para los paquetes de estilos. Pero por lo que veo, no es una práctica común hacerlo de esta manera, por lo general, los paquetes se crean en función del tipo, por ejemplo, uno para bootstrap, uno para jquery, uno para archivos js / css personalizados, etc. Pero eso no aumentaría el tiempo de carga de la página, porque tener más paquetes significa más solicitudes al servidor. Además, ¿cuál es el problema de hacer las cosas como describí al principio?

Creo que incluso podría ser contraproducente usar un solo paquete por página.

Hay una sobrecarga para la creación del paquete ... aunque, esa sobrecarga se incurre una vez por instancia de aplicación (la aplicación lo almacena en caché después de la primera llamada), pero si tiene un nuevo paquete para cada página, eso significa para cada página distinta cuando visita, se debe crear un nuevo paquete antes de que se pueda servir. Eso supondría un incumplimiento considerable del propósito de los paquetes, creo.

Por el contrario, generalmente tengo dos paquetes: un paquete central que se espera que requiera cada página y que casi nunca cambiará una vez que se configure el proyecto inicial. Esto incluye estilos básicos, jQuery / knockout, otras bibliotecas de proveedores básicos.

El segundo paquete suele ser el contexto por aplicación (por ejemplo, el paquete de usuarios puede tener elementos modulares relacionados con los usuarios en general, pero no necesariamente con una página específica).

Cualquier cosa específica de la página generalmente ni siquiera entra en un paquete.

El efecto práctico de rendimiento de la agrupación (al menos para las aplicaciones comerciales que tiendo a escribir) no es realmente tan bueno, teniendo en cuenta que una vez que el cliente lo ha llamado por primera vez, está allí hasta que cambie de todos modos.

Si tiene un sitio público donde espera un mayor número de visitantes por primera vez, puede adoptar un enfoque ligeramente diferente.

No.

Debido al almacenamiento en caché del navegador, obtiene los mejores resultados generales al usar el mismo paquete o paquetes en todas las páginas. Esto significa que el usuario descargará todos los css y js cuando lleguen a la primera página y reutilizará ese archivo en las páginas siguientes.

Dado que la mayor parte del paquete serán frameworks javascript empaquetados como jquery y bootstrap. Sus pocos bytes adicionales de código personalizado tienen un efecto insignificante en la velocidad general de carga de la página.

La desventaja de un paquete por página es que el paquete en caché de una página no se puede usar en otra página, lo que normalmente desea es que la mayor parte de sus scripts (por ejemplo, jQuery bootstrap, etc.) se descarguen una vez y se almacenen en caché para todas las páginas en el sitio.

La solución "óptima" desde una perspectiva de almacenamiento en caché sería tener un paquete único que contenga todos los archivos .js para todas las páginas en todo el sitio, la desventaja de ese enfoque es que el paquete termina siendo bastante grande, lo que significa que la carga inicial de la página es más lenta , lo que podría no ser deseable para los sitios web de cara al cliente donde las impresiones iniciales lo son todo.

La "mejor" solución probablemente será una combinación de técnicas, por ej.

• Un paquete "básico" (cosas como jQuery y Bootstrap que se usa en casi todas las páginas), más un paquete por página
• Un paquete único para todo el sitio, tal vez excluyendo una página pesada de JavaScript que agrega mucho al tamaño del paquete