CODEWITHSUNDEEP
javascriptjqueryasp.net-mvcperformance
user1838662
user1838662

Reputation: 523

javascript segregation/performance in an ASP.NET MVC Application

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.

Any advice would be appreciated.

Upvotes: 0

Views: 220

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239250

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.

Upvotes: 1

Related Questions