11

Both YSlow and Google's Page Speed add-ons recommend combining script (and style) files into a single file each to reduce the number of HTTP requests, and I can certainly see the point of this when the script files are consistent across the entire site, but for a web application that has different requirements across the site.

The way I see it there are a few options:

  1. Combine all of the files that are used across the site, and every page gets the same combined file - the downside is unused content cluttering the script (and a heavier first load (also reload when any component script changes))

  2. Combine the files on a per page basis - the downside is each page with different requirements gets a different combined file (heavier first load for each page type)

  3. Ignore the strict 'one file only' interpretation of the recommendations and have the page load in multiple files as appropriate, with caching hopefully negating the number of HTTP requests in the general case - downside is the number of HTTP requests on each page

Thoughts?

Improve this question
2
  • You're doing it wrong. Either separate the parts out into individual files and take the warmup hit (caused by larger # of requests and cold cache) or programmatically combine the source files serverside and serve just 1 js, css, html page per hard link. Mixing files with different mime-types = bad.
    – Evan Plaice
    Feb 11, 2012 at 18:07
  • And... like @Larry Smithmier said in his answer, use a CDN (ex. Google) to deliver common libraries (ex. jquery) to completely avoid initial cache warming costs for those files.
    – Evan Plaice
    Feb 11, 2012 at 18:11

4 Answers 4

Reset to default
11

Option 2 is the worst; it means that every page with a different combination of needed JS scripts will result in an HTTP request. It will make performance much worse.

Option 1 is the best. Eventually most users will visit most of the page "types" of your website, so it's still advantageous to combine everything into a single file, with maybe the exception of large JS files that are needed in few, seldom visited pages.

The first page hit may be slower than with different files, but it's still worth doing as every other page hit will used the cached global JS.

One tip though; merge them automatically if you aren't already!

Improve this answer
3
  • 2
    Though you do need to be very aware of the initial impression given by your home page / landing pages. If the first page a visitor sees is slow to load they might not bother to look at a second page.
    – pelms
    Jul 9, 2010 at 10:15
  • Another option, especially if your site depends heavily on a landing page or strong first impression, would be to minimize the size of the files served on that first page, and then serve the combined files on every other page.
    – Travis Northcutt
    Jul 12, 2010 at 21:39
  • This response is perhaps out of date now that HTTP/2 has lessened the impact of additional HTTP requests.
    – Maximillian Laumeister ♦
    May 4, 2021 at 8:46
4

I generally combine "global Javascript" - jQuery and common plugins - into a single file, and then serve up extra plugins as separate files when required.

For example, one site I run many of the pages have data tables on them so I have a global.js with jQuery, DataTables and SuperFish (for my menu). There are two pages on the site that use a "lightbox" so I have a separate script for those two pages.

For CSS, I just serve a single file for the entire site and try to make the CSS as general as possible - most pages only have a few unique CSS elements.

Improve this answer
1

While it's definitely recommended to use as few files as possible, you may find that you have a split between functionality that is required at page load, and functionality that can be deferred through asynchronous loading.

If enough of your JS can be pushed into the second category, you can improve the perceived initial load speed of the page, creating a better experience for your users.

Improve this answer
1

I wouldn't suggest combining all of them. If you are useing a common library, you can leverage a CDN to deliver your javascripts. You can then take advantage of browser caching (assuming other sites are using the same CDN) and distributed delivery. Microsoft and Google each have solutions (I haven't honestly used either, but I am certainly going to start) and there may be others. On a related note, SO has this question:

When Does Browser Automatically Clear JavaScript Cache?

and the first answer is solid gold.

Improve this answer
2
  • 2
    I'm already using the Google hosted jQuery library, but I meant that question to refer to site specific files (ie for the stack exchange sites, when asking a question you've got the script to search for similar questions, the script to render the markdown, and the tag suggestions, all of which may be wanted to be developed in separate files). As an aside, if you use the Google jQuery hosted js, while 1.4 and 1.4.2 will both give you the same content (at the moment), 1.4.2 is cached for a year, but 1.4 is only cached for an hour.
    – Cebjyre
    Jul 15, 2010 at 16:17
  • cool tip! thanks for the insight into the caching duration on the hosted jQuery.
    – Larry Smithmier
    Jul 16, 2010 at 14:05

Your Answer

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

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