Now, when you see the default bundles organized by-library, your first thought is – “that’s default behavior, so it’s probably the one I should use ” and you jut go with the flow with it.
Sadly that leads to making a bundle for each library and calling @Scripts.Render method for each library that you’re using on the page. Which leads to this in production:
I think bundling should be able to combine all your files into one so we get the best possible optimization. A way of doing that is to make a bundle for each page you’re using with the necessary libraries in it.
If we do this however with the current structure of bundles in MVC 4, we wouldn’t be able to use a CDN for jQuery and the other of the common used libraries, because the CDN is declared on per-bundle basis.
A better approach would be to use different bundles for just the common libraries – jQuery, jQuery UI, Twitter Bootstrap etc. with CDN configurations. And for the custom libraries we could use a bundle for each screen with the custom libraries that each screen uses. So in your base _Layout file we could say:
And in each page we make the include:
Where bundles/index is a custom bundle definition for the Index.cshtml page, where you define all the custom libraries needed for the Index.cshtml page. The bundle definition could look like that:
That way we get both CDN support with the common libraries as well as the most effective and optimized bundle management for the custom libraries and files that change more frequently. Win-win situation. Or almost.
The downside of this approach is that if you want to put your libraries in your personal CDN, this method of organizing bundles wouldn’t be very effective, I guess, as you’d have to make a different file in the CDN for each bundle e.g. for each page.