In Summary
When bundling and minifying JavaScript, is it good practice to have a single site-wide JS bundle or multiple specific bundles?
If the latter, then how can these bundles be added to each View (not layout) and still get the server to return the individual non-minified JS files when in debug mode?
In Detail
I read a very interesting article detailing how to use the bundling and minification that is available in the MVC4 framework in the an ASP.NET MVC3 web application: click for article
In this article, it describes how to add a link to a particular bundle from the layout page:
Scripts.Render("~/bundles/MyBundle")
And I can see how this approach is great for creating a site-wide bundle.
However, I'm not sure what the best-practice is regarding whether to have a single site-wide bundle, or multiple specialized bundles and I'd appreciate advice here. As I see it, the pros and cons of a single site-wide bundle are:
Cons:
slows down initial load of home page (even with minimization)
may be harder to ensure no JS conflicts.
Pros:
all subsequent pages have nothing new to download
just one bundle to administer
Okay - assuming that best practice turns out to be multiple bundles.... That being the case, I see how easy it is to add a bundle to a layout page, but how about specific views? Each View should register the JS that it requires (in a script section) and then this is added to the bottom of the page's body so that it loads last (unlike CSS which you add to the Header so that it loads first). I managed this using the following code, but the problem with this route is that the JS always comes out as the single minified file which isn't that helpful in debug mode.
#<script src="#Scripts.Url("~/bundles/myBundle")"></script>
Many thanks in advance
Griff
You can do both. In order to render the specialized bundles, you can do this:
Create a scripts section in your _Layout.cshtml. I usually put mine at the bottom of the page just before the closing body tag, but you could also put it in the head:
#RenderSection("scripts", required: false)
Then, in your view, you define the section like so:
#section scripts {
#Scripts.Render("~/bundles/myspecialuniquebundlejustforthisview")
}
When you do it this way, the bundle will only be compressed and minified when you either compile with debug="false" or explicitly set BundleTable.EnableOptimizations = true during debug time.
Related
I'm trying to update a legacy frontend web application to use webpack for the dependencies. Right now it's structured like so:
- login.html
- dashboard.html
... src/login.js
... src/dashboard.js
Each page has its own javascript file, plus it loads in a bunch of external dependencies via script tags on the page. My problem is that most of the pages use some variation of the same bunch of very large libraries and jquery plugins. If I bundle each page's js into a seperate js file, i'm going to end up with a huge bundle for every page that has to be downloaded every time the user changes page. I'd prefer to just have one bundle that every page loads and uses the neccessary part. Is webpack fir for purpose here, and if so how should I be going about it?
I "solved" this by keeping my library imports as they are, ie jquery, bootstrap etc downloaded from CDNs. I made one bundle for each of my bigger local libraries and included that on each page so that it gets cached by the browser, then I used webpack with multiple entry point for our bespoke js code.
We have an MVC 4 web application with a number of areas.
There is a main layout view that is used by all the pages on the site and it contains all of the CSS includes, the render body tag, then all the JavaScript libraries.
<head>
<link rel="stylesheet" media="screen" href="~/Content/jquery-ui-1.10.3.custom.min.css" />
..
</head
<body>
<div id="main-content">#RenderBody()</div>
<script type="text/javascript" src="~/Scripts/jquery-1.10.2.min.js"></script>
..
</body>
The JavaScript consists of common libraries such as jquery, jqueryui and plug-ins.
There is also a single JavaScript file that contains the custom code for the whole site
Since there is only 1 large JavaScript file with thousands of lines, code routines are initialized by checking for the existence of a particular DOM element to decide if it proceeds.
runExample = function() {
if ($(".Example").length > 0){
// execute code
}
}
..
runExample();
This is of course problematic since there is a great deal of script included for all files, while there is code that applies to all pages, most of the code only applies to certain areas or pages.
Is there a better way to split the JavaScript up for the site? Keep in mind it is the custom code that is conditional, not necessarily the plug ins
Even if there way a way to create a JavaScript file for each area, how
would that be referenced within the main layout?
Is it best to load the JavaScript include files at the end of the include file?
What is the effect of minification on performance and would it benefit the custom code file?
Any advice would be appreciated.
First, use bundling. Give BundleConfig.cs under the App_Start folder in your project a gander. By simply minifying and bundling all your JS together, it's sometimes inconsequential that certain code is not actually being used on the current page (the savings you gain from having one cached JS file that every page uses is sometimes better than loading a new different bit of JS on each page.)
If you need more fine grained control, you can use something like Require.js. You essentially write your JS in modules that depend on other modules to run (all of your plugins, jQuery, etc. become "modules" in this scenario). You'll need to manually minify and combine your JS as much as logically possible, but this will allow you to integrate various scripts together without having to worry about load order and missing dependencies.
As a side note, I would respectfully disagree with Kevin B. If maintainability dictates that your JS has to be in the head, I would say that's a symptom of a larger problem with your code design. The only good reason to add JS in the head is when it's essential that the JS be run before the page is rendered. A good example is Modernizr, which for one adds classes to the html element to allow you to specify different styles and such depending on whether certain features are available in the user's browser or in the case of IE, what version the user is running. Without loading in the head, your style would changed after page load leading to flashes of unstyled content and such. Other than situations like these, all JS should go before the closing body tag, as JS is blocking: the browser will completely stop what it's doing and all rendering of the page, and run the script completely before continuing. Too much of this in the head, and your users stare at a blank page for far too long.
Also all script (and CSS for that matter) should be minified. There's no good reason not to, and the difference in bytes the user has to download is often quite dramatic. Especially in this day and age of mobile-everything and far-too-limited data plans, every byte truly does count.
It seems counter to good practice to place all JavaScript files in the `~/Scripts' folder. I see massive view specific scripts incorporated into the view, but now with the advent of TypeScript, with its compiled JS files, a developer should decide where these should go.
You could divide your scripts folder in the same way as your views folder... But I recommend thinking more in terms of either...
For smaller sets of scripts - bundle, minify, serve a single script. Reduction in requests and caching of the script will almost certainly trump trying to serve lots of small scripts. You are welcome to measure and adjust if you think you have something different from the norm.
For larger sets of scripts think of the scripts as a program and organise them that way rather than by tying them to your views. So look to create modules that do specific jobs, rather than serve specific pages.
I am using RequireJS and I am creating a own script file for each page. However I also have some components that are included into some of the pages (server side). Should these pages also get their own script file, or should the necessary javascript be in the containing page? Some of the functionality for the included pages are common to many pages.
I think you'd be better off thinking about your javascript as reusable modules rather than page-specific functionality. So, say your page has a search box which initiates an AJAX request, a few date pickers, and a whole bunch of tabs. Each of these should be a module (or if the functionality they provide is complex enough, a few modules). By breaking down your app into small pieces that have very focused aims, you make it easier to test each bit in isolation (automated unit tests) and reuse the functionality elsewhere.
Now as to how to load your javascript modules, there's a point where it makes sense to strategically load stuff based on user needs (ex: core.js is loaded by default but search.js isn't loaded until the user accesses the "search" tab) but you can get pretty far just packaging everything into a single file (require's r.js tool does this for you) and using the same script file (main.js) on every page.
When using a single script file, keep in mind that your js will need to work when the target of it's functionality is not present. jQuery makes this super simple and you almost don't have to think about it - ex:
$('#js-foo').on(...) // <-- this doesn't blow up if '#js-foo' isn't on the page.
I've also seen people set a data-attr on the body tag for the page - e.g. data-page="foo" and key js off of that:
var page = $('body').data('page');
if (page === 'foo'){
component1.setup();
component2.setup();
}
In your case, I would try building everything into a single file using RequireJS / AMD-style modules. Each component would get its own module file (mycomponent.js), your main.js would require() all your modules and init things appropriately, and finally you'd configure your r.js build to package everything into a single file when deploying to / running in production.
If you are interested in exploring this topic more, check out these posts:
Single Entry Point FTW
Single Entry Point Redux
I know that best practice for including javascript is having all code in a separate .js file and allowing browsers to cache that file.
But when we begin to use many jquery plugins which have their own .js, and our functions depend on them, wouldn't it be better to load dynamically only the js function and the required .js for the current page?
Wouldn't that be faster, in a page, if I only need one function to load dynamically embedding it in html with the script tag instead of loading the whole js with the js plugins?
In other words, aren't there any cases in which there are better practices than keeping our whole javascript code in a separate .js?
It would seem at first glance that this would be a good idea, but in fact it would actually make matters worse. For example, if one page needs plugins 1, 2 and 3, then a file would be build server side with those plugins in it. Now, the browser goes to another page that needs plugins 2 and 4. This would cause another file to be built, this new file would be different from the first one, but it would also contain the code for plugin 2 so the same code ends up getting downloaded twice, bypassing the version that the browser already has.
You are best off leaving the caching to the browser, rather than trying to second-guess it. However, there are options to improve things.
Top of the list is using a CDN. If the plugins you are using are fairly popular ones, then the chances are that they are being hosted with a CDN. If you link to the CDN-hosted plugins, then any visitors who are hitting your site for the first time and who have also happened to have hit another site that's also using the same plugins from the same CDN, the plugins will already be cached.
There are, of course, other things you can to to speed your javascript up. Best practice includes placing all your script include tags as close to the bottom of the document as possible, so as to not hold up page rendering. You should also look into lazy initialization. This involves, for any stuff that needs significant setup to work, attaching a minimalist event handler that when triggered removes itself and sets up the real event handler.
One problem with having separate js files is that will cause more HTTP requests.
Yahoo have a good best practices guide on speeding up your site: http://developer.yahoo.com/performance/rules.html
I believe Google's closure library has something for combining javascript files and dependencies, but I havn't looked to much into it yet. So don't quote me on it: http://code.google.com/closure/library/docs/calcdeps.html
Also there is a tool called jingo http://code.google.com/p/jingo/ but again, I havn't used it yet.
I keep separate files for each plug-in and page during development, but during production I merge-and-minify all my JavaScript files into a single JS file loaded uniformly throughout the site. My main layout file in my web framework (Sinatra) uses the deployment mode to automatically either generate script tags for all JS files (in order, based on a manifest file) or perform the minification and include a single querystring-timestamped script inclusion.
Every page is given a body tag with a unique id, e.g. <body id="contact">.
For those scripts that need to be specific to a particular page, I either modify the selectors to be prefixed by the body:
$('body#contact form#contact').submit(...);
or (more typically) I have the onload handlers for that page bail early:
jQuery(function($){
if (!$('body#contact').length) return;
// Do things specific to the contact page here.
});
Yes, including code (or even a plug-in) that may only be needed by one page of the site is inefficient if the user never visits that page. On the other hand, after the initial load the entire site's JS is ready to roll from the cache.
The network latency is the main problem.You can get a very responsive page if you reduce the http calls to one.
It means all the JS, CSS are bundled into the HTML page.And if your can forget IE6/7 you can put the images as data:image/png;base64
When we release a new version of our web app, a shell script minify and bundle everything into a single html page.
Then there is a second call for the data, and we render all the HTML client-side using a JS template library: PURE
Ensure the page is cached and gzipped. There is probably a limit in size to consider.We try to stay under 400kb unzipped, and load secondary resources later when needed.
You can also try a service like http://www.blaze.io. It automatically peforms most front end optimization tactics and also couples in a CDN.
There currently in private beta but its worth submitting your website to.
I would recommend you join common bits of functionality into individual javascript module files and load them only in the pages they are being used using RequireJS / head.js or a similar dependency management tool.
An example where you are using lighbox popups, contact forms, tracking, and image sliders in different parts of the website would be to separate these into 4 modules and load them only where needed. That way you optimize caching and make sure your site has no unnecessary flab.
As a general rule its always best to have less files than more, its also important to work on the timing of each JS file, as some are needed BEFORE the page completes loading and some AFTER (ie, when user clicks something)
See a lot more tips in the article: 25 Techniques for Javascript Performance Optimization.
Including a section on managing Javascript file dependencies.
Cheers, hope this is useful.