0

I am fighting about a web application script optimization. I have an ASP.NET web app that reference jQuery in the master page, and in every child page can reference other library or JavaScript extension.

I would like to optimize the application with YUI for .NET.

The question is, I should put all the libraries reference in the master page or to compress all the JavaScript code in a single file, or I should create a file for every page that contains only the code useful to the page?

Is there any guidance to follow?

4 Answers 4

2

The practice that I generally see followed is to put all js code in a single file, using a minimizer like Microsoft AJAX minifier or YUI compressor, and reference the file on the master page. That way you have a small file for the production version, while you can keep the code in separate files to ease development and debugging. You reference ASP.NET - Chirpy is a good VS plugin to help you manage js/css mashing and minimizing.

As for having separate files with page-specific functionality and referencing them on a per-page basis, you have to weigh the benefits of having a lighter 'main' script and the users having to download additional scripts when required versus the additional work it will take to maintain this more elaborate setup.

If you have a really 'heavy' js script required only for some seldom used functionality that only a fraction of your users will access (something like a rich text editor comes to my mind), you might see benefits in only including it where it's absolutely needed. Use your best judgement here to decide how granular you want to make your scripts.

I remember reading somewhere how it's a good practice to keep the script for your main page as light as possible, as this is the one that the users' impressions hinge on, and use a 'regular' script on other pages. I would have to look up the reference for that though.

2

For common libraries, link to a CDN

The point of combining JS imports is to cut down on the number of HTTP requests required to load the page.

With that in mind, common libraries like jQuery may already be on in the user's browser cache. By using a common CDN link, your users get the speed advantage of a pre-warmed cache and you get the added benefit of not having to maintain a local copy on your server.

Any common JS library of appreciable size will usually have the ability to fetch the code from an internal or third-party (ex google) CDN. They will usually provide links to multiple versions so users can lock into a specific while the dev team maintains the freedom to continue development.

To give you an idea, here's the test runner for one of my projects. If you 'View Source' you'll see that jQuery is being served by the Google APIs CDN and qUnit is being served by the jQuery CDN.

For local stuff, it might be a good idea to compile everything into one file

It depends on the size of your codebase but there is a measurable benefit to be gained by reducing the number of web requests required to load the page. The same rule holds true for using image sprites for the UI/CSS.

2

I prefer the leverage of RequireJS. Takes a little bit of getting used to, but I believe your use case lands in the RequireJS wheelhouse.

I prefer this approach because it sort of combines your two decisions into one... RequireJS will load only the javascript you require (a file for every page, if you like), and it will load them in one HTTP request.

In short, it condenses all of your modular javascript code into one file for low overhead.

2
  • 1
    Hi Honus, Why do you prefer this approach? Dec 18, 2012 at 15:25
  • It sort of combines your two decisions into one... RequireJS will load only the javascript you require (a file for every page, if you like), and it will load them in one HTTP request. In short, it condenses all of your modular javascript code into one file for low overhead. Dec 18, 2012 at 16:49
0

If you put all your JavaScript into one file and use it everywhere, the browser can cache the file ond only needs to download it once.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.