Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

On a few of my sites, we use Javascript/CSS bundles to reduce load time. I've always used two bundles for each type (4 in total) so I have

  • JS Bundle 1: Contains scripts that are standard on every page (jQuery, cross page functions etc.)
  • JS Bundle 2: Contains scripts specific to that page
  • CSS bundle 1: Contains general site CSS (Layout, colors etc.(
  • CSS Bundle 2: Contains CSS specific to that page

My theory behind that is, JS Bundle 1 and CSS Bundle 1 never change, so by having them in a separate bundle they can be cached and re-used on every page, whereas JS bundle 2 and CSS bundle 2 contain the code that changes per page. Sometimes these might only have one or two lines of code in them. I did some freelance work for a web development company using this method, and they told me it was bad/wrong and I should only use one bundle for each media type because using two bundles increases the number of requests and slows the page. I don't understand why this is slower than using two bundles?

Just as an example with Javascript (Though almost identical for CSS)

First page visited (Say page1.html): 100kb of standard scripts used on every page and 5kb of custom scripts
With my method a user would have to download 105kb of media in two requests
With their method a user would have to download 105kb of media on one request
So on the first visit, I accept their method is faster but

Second page visited (page2.html): 100kb of standard scripts and 3kb of custom scripts
With my method, the standard scripts would already be cached so they would only have to download 3kb of scripts
With their method the user would have to downoad 103kb of scripts, just for the 3kb of custom scripts.

Yet they insist their method is faster, how is this possible? I'm sure having to make one extra request can't decrease the page load so much it's more effective to re-download 100kb of data they already have, and that's just the JS, adding the CSS that becomes nearer to double

share|improve this question
    
I think they don't understand caching. –  paulmorriss Jun 7 '11 at 15:37
    
@paulmorriss It seemed odd to me, the site was using Edgecast too but they're quite a bit web services company in the UK (Over 50 employees) so I don't want to just say "No you're wrong" because I'm sure they have much more knowledge than me, but Google Pagespeed/YSlow gave me downpoints for having multiple bundles =S –  sam Jun 7 '11 at 15:40
    
Because YSlow takes a view on a single page it doesn't appreciate that what you're doing across the site with a common script. –  paulmorriss Jun 7 '11 at 15:42
add comment

2 Answers

up vote 2 down vote accepted

They are probably* right.

It can be bad to split your JavaScript and CSS code into multiple files. Even if some of the code in those files is used on one page only, it's worth keeping it all in a single file to reduce page requests. Let me show you why:

Their method (all CSS in one file):

  1. First page loads (1 request, 108KB CSS file loaded over HTTP)
  2. Second page loads (0 requests, 108KB CSS file from browser cache)
  3. Third page loads (0 requests, 108KB CSS file from browser cache)

Your method (CSS in multiple files):

  1. First page loads (1 request, 100KB CSS master file loaded over HTTP)
  2. Second page loads (1 request, 5KB file over HTTP, 100KB file from browser cache)
  3. Third page loads (1 request, 3KB file over HTTP, 100KB file from browser cache)

With each page load, you need an extra HTTP page request for the custom CSS that would otherwise have been included in the request for the original master file. If the custom code for each subpage grows much bigger, then you might want to test to see which is faster, but in the scenario you describe, I would wager that a single 108KB request is faster than three requests for a 100KB, 5KB, and 3KB file, because HTTP requests are expensive.

Beyond that -- and the actual performance difference is likely tiny anyway -- it's easier to keep one file open when editing code than it is to hop between multiple files. A big site could quickly result in 10 or more separate CSS files, and that's never fun to manage. For that reason alone it's worth keeping code in one file if you can.

*I say probably because there are other factors to consider. e.g. There are times when splitting up big CSS and JavaScript files makes sense. If one rarely-visited page needs an extra 500kb of JavaScript, you could argue against including it in the site's main JS file. You can also use things like minify to reduce HTTP requests when multiple CSS/JS files are requested, but it still doesn't get away from the fact that you've got to juggle all those files in your code editor in the first place.

share|improve this answer
    
If we were to bundle ALL our JS into one file we'd have a single file over 2MB (It's a huge site) so each page must have it's own unique bundle. I'd say 90% of our users aren't going to need all of that scripts. Both the bundles are minified and GZIPped into static files on each deploy –  sam Jun 8 '11 at 12:42
    
Your compressed JavaScript file is 2MB? Seriously? If you know that 90% of visitors only need 10% of that stuff, then that's a different scenario to the one you posed in your question, and serving separate files makes more sense. I would suggest optimising that JavaScript code before splitting it up, though. –  Nick Jun 8 '11 at 13:22
    
@Nick It's for a company that builds custom computers, so we have the main site scripts, the scripts that power the shopping cart (Quite big, it's all done in AJAX), the scripts that power the 'Computer Builder' thing (Quite big too), there's also the scripts that power the forum and support pages etc. so lots of completely different stuff. I didn't write the frontend/JS (I'm a backend guy) but I had to do the optimization. I think the javascript has been written with the attitude of "DRY sucks, I'm going to reuse the same 100 lines of code 20 times" =) –  sam Jun 8 '11 at 14:54
    
@Nick also we use Edgecast which supports keepalive which, if I remember correctly, can reduce the cost of having to do HTTP requests but I'm not sure of the exact efficiency. –  sam Jun 8 '11 at 14:57
1  
@samarudge That clarifies things a lot; it sounds like splitting the files is definitely the way to go in this case. Treat each distinct part of the site (e.g. the 'computer builder') as an application separate from the main website to segregate them and reduce the size of files sent to 90% of visitors. The extra HTTP request is no big deal if only 10% of your audience uses that app. For regular 'text and pictures' sites, my answer above still stands. –  Nick Jun 8 '11 at 15:11
show 1 more comment

My theory behind that is

That's your problem. Don't theorize - test. You can use the network profiler in Firebug or IE dev tools to see exactly, down to the millisecond, which method is fastest.

share|improve this answer
    
agree - the results will speak for themselves. Certainly use WebPageTest.org for 1st/2nd-load waterfall analysis, graph the results from YSlow/PageSpeed using gtmetrix.com –  Mike Hudson Jun 8 '11 at 6:55
    
The issue I have with this (As discussed in the comments on the main post) is Firebug/Pagespeed etc. only test on one page. My method is almost certainly slower on a single page on the first visit but on subsequent visits I think it's a better solution –  sam Jun 8 '11 at 12:39
    
In Firebug you can test with it both cached and uncached. You may be surprised at what you find. On most sites I run, the page loads faster when the CSS and JS needed at page load is included directly on the page - than when pulling from cached, external CSS and JS files. Even if a resource is cached the browser still has to do a HTTP lookup, get a 304 (Not Modified) response, and load from the cache. –  Will Peavy Jun 8 '11 at 13:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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