views:

68

answers:

4

Hi All,

PageSpeed and Yslow suggest that to combine javascripts file to reduce HTTPRequest. But this is becuase (I think) pre ie8 browser has no more than 2 serverhost connection.

But nowaday, browser has 6 serverhost connections, which means it has download javascripts in parrallel. So let say we have 1MB of javascript, should we break it down into 6 different files in similar size to obtain max download speed? Please let me know.

Micahel.S

A: 

Most browsers will cache your JavaScript files anyway, so after the first page load, it won't matter.

But, you should split your JavaScript logically and in a way that would most help you in development, since browsers vary in the number of simultaneous connections they allow.

For speed, you can obfuscate your code (via a minimization routine) and serve it in a way no human would have the patience to read.

palswim
Obfuscation has nothing to do with speed. (Do you mean minify?)
SLaks
@SLaks: Yes, I meant the minimizing version of obfuscation. It's purpose may not be obfuscation, but minimizing your code certainly obfuscates it.
palswim
+3  A: 

No, because each HTTP request involves overhead (less if pipelining is used)

SLaks
Is there a way to know how big is the overhead?
Michael.S
@Michael: Measure it with Fiddler or Firebug.
SLaks
@Michael: [HttpFox](https://addons.mozilla.org/en-US/firefox/addon/6647/)
Chris Shouts
I perform some test, and i send over a js file that is 237.3KB and 856.2KB, and the response header's content length says that it is 242990 and 876752. Does that mean the the over head is about 5KB and 20KB repective? is that relatively small? and does it make more sense break the javascripts for Modern Browser for Faster download time?
Michael.S
A: 

The answer to your question is no. However, assuming you are able to serve your content in a completely isolated environment where only IE8 is used (like company intranet), then the answer to your question becomes: no.

Since you aren't designing for IE6-7 I assume you are in an isolated environment (otherwise you are making a poor designing decision). In this environment, yes you might see small benefits from breaking down JavaScript files, but I recommend against it.

Why? Since you are optimizing for speed, I assume you are putting JavaScript at the bottom of the body tag in your HTML document, in order to prevent JS from blocking download of DOM. This is a fundamental practice to make the page appear to be loading faster. However, by placing the content in the bottom of the body, your question becomes moot. Since the DOM is no longer being blocked by the script tags, whatever speed benefits you could achieve by using parallel downloading would be lost on the user because they see the page load before the browser even requests the JavaScript files.

tl;dr: There is no practical speed advantage to break JS into multiple files for parallel downloading.

Moses
That really depends who your audience are.
Daniel Cassidy
You have to take what I say with a grain of salt and look at it more generally. Slower browsers need page optimization a lot more than faster browsers. Breaking 1 JS file into 6 to allow for parallel download could help modern browsers shave off a few MS, but it adds 6 times the latency to older browsers. Perhaps out of pure hate for IE you could do this as punishment (I would)... but hopefully you all aren't as cruel as I am.
Moses
Hi Moses, i agree with you that if your audience is everyone then your answer might be right. But what if i am talking about IE8 only? Will breaking down JS file make any sense at all? I did some test, it seems like it's faster, but everyone on the web is saying it's not the best practice, but i don't know why
Michael.S
I changed my submitted answer to address that question.
Moses
A: 

Splitting the files won't make too much of a difference really. If you want to see performance gains in terms of download times for your Production environment what I always do is use YUI Compressor (http://developer.yahoo.com/yui/compressor/) to get my JS file size down as small as possible then serve a gzipped version of the js to browsers that support it.

In a development environment you shouldn't be too worried about it though. Just split them logically based on their purpose so they're easier to work on then bring them all together into one file once you're ready and optimize it for production.

jduren