Put javascript in one .js file or break it out into multiple .js files?

Question

My web application uses jQuery and some jQuery plugins (e.g. validation, autocomplete). I was wondering if I should stick them into one .js file so that it could be cached more easily, or break them out into separate files and only include the ones I need for a given page.

I should also mention that my concern is not only the time it takes to download the .js files but also how much the page slows down based on the contents of the .js file loaded. For example, adding the autocomplete plugin tends to slow down the response time by 100ms or so from my basic testing even when cached. My guess is that it has to scan through the elements in the DOM which causes this delay.

Answer 1

If people are going to visit more than one page in your site, it's probably best to put them all in one file so they can be cached. They'll take one hit up front, but that'll be it for the whole time they spend on your site.

Answer 2

At the end of the day it's up to you.

However, the less information that each web page contains, the quicker it will be downloaded by the end-viewer.

If you only include the js files required for each page, it seems more likely that your web site will be more efficient and streamlined

Answer 3

Common but relevant answer:

It depends on the project.

If you have a fairly limited website where most of the functionality is re-used across multiple sections of the site, it makes sense to put all your script into one file.

In several large web projects I've worked on, however, it has made more sense to put the common site-wide functionality into a single file and put the more section-specific functionality into their own files. (We're talking large script files here, for the behavior of several distinct web apps, all served under the same domain.)

The benefit to splitting up the script into separate files, is that you don't have to serve users unnecessary content and bandwidth that they aren't using. (For example, if they never visit "App A" on the website, they will never need the 100K of script for the "App A" section. But they would need the common site-wide functionality.)

The benefit to keeping the script under one file is simplicity. Fewer hits on the server. Fewer downloads for the user.

As usual, though, YMMV. There's no hard-and-fast rule. Do what makes most sense for your users based on their usage, and based on your project's structure.

Answer 4

Duplicate of Multiple javascript/css files: best practices?

Answer 5

If the files are needed in every page, put them in a single file. This will reduce the number of HTTP request and will improve the response time (for lots of visits).

See Yahoo best practice for other tips

Answer 6

If you like the code in separate files for development you can always write a quick script to concatenate them into a single file before minification.

One big file is better for reducing HTTP requests as other posters have indicated.

Answer 7

I also think you should go the one-file route, as the others have suggested. However, to your point on plugins eating up cycles by merely being included in your large js file:

Before you execute an expensive operation, use some checks to make sure you're even on a page that needs the operations. Perhaps you can detect the presence (or absence) of a dom node before you run the autocomplete plugin, and only initialize the plugin when necessary. There's no need to waste the overhead of dom traversal on pages or sections that will never need certain functionality.

A simple conditional before an expensive code chunk will give you the benefits of both the approaches you are deciding on.

Answer 8

I would pretty much concur with what bigmattyh said, it does depend.

As a general rule, I try to aggregate the script files as much as possible, but if you have some scripts that are only used on a few areas of the site, especially ones that perform large DOM traversals on load, it would make sense to leave those in separate file(s).
e.g. if you only use validation on your contact page, why load it on your home page?

As an aside, you can sometimes sneak these files into interstitial pages, where not much else is going on, so when a user lands on an otherwise quite heavy page that needs it, it should already be cached - use with caution - but can be a handy trick when you have someone benchmarking you.

So, as few script files as possible, within reason.

If you are sending a 100K monolith, but only using 20K of it for 80% of the pages, consider splitting it up.

Answer 9

It depends pretty heavily on the way that users interact with your site.

Some questions for you to consider:

• How important is it that your first page load be very fast?
• Do users typically spend most of their time in distinct sections of the site with subsets of functionality?
• Do you need all of the scripts ready the moment that the page is ready, or can you load some in after the page is loaded by inserting <script> elements into the page?

Having a good idea of how users use your site, and what you want to optimize for is a good idea if you're really looking to push for performance.

However, my default method is to just concatenate and minify all of my javascript into one file. jQuery and jQuery.ui are small and have very low overhead. If the plugins you're using are having a 100ms effect on page load time, then something might be wrong.

A few things to check:

• Is gzipping enabled on your HTTP server?
• Are you generating static files with unique names as part of your deployment?
• Are you serving static files with never ending cache expirations?
• Are you including your CSS at the top of your page, and your scripts at the bottom?
• Is there a better (smaller, faster) jQuery plugin that does the same thing?

Answer 10

I think it depends how often they change. Let's take this example:

• JQuery: change once a year
• 3rd party plugins: change very 6 months
• your custom code: change every week

If your custom code represents only 10% of the total code, you don't want the users to upload the other 90% every week. You would split in at least 2 js: the JQuery + plugins, and your custom code. Now, if your custom code represents 90% of the full size, it makes more sense to put everything in one file.

When choosing how to combine JS files (and same for CSS), I balance:

• relative size of the file
• number of updates expected