better to serve one big js file or several smaller ones?

[petermichaux]

Hi,

I'm curious about server load and download time if I use one big
javascript file or break it into several smaller ones. Which is better?
(Please think of this as the first time the scripts are downloaded so
that browser caching is out of the equation.)

Thanks,
Peter

[Randy Webb]

pe**********@gm ail.com said the following on 3/22/2006 1:45 AM:

Hi,

I'm curious about server load and download time if I use one big
javascript file or break it into several smaller ones. Which is better?
(Please think of this as the first time the scripts are downloaded so
that browser caching is out of the equation.)

That depends on your aim. IE will load them faster using separate files
and using separate files will allow the browser to go ahead and parse
them as they are downloaded.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Jim Ley]

On Wed, 22 Mar 2006 01:52:42 -0500, Randy Webb
<Hi************ @aol.com> wrote:

pe**********@g mail.com said the following on 3/22/2006 1:45 AM:

Hi,

I'm curious about server load and download time if I use one big
javascript file or break it into several smaller ones. Which is better?
(Please think of this as the first time the scripts are downloaded so
that browser caching is out of the equation.)

That depends on your aim. IE will load them faster using separate files
and using separate files will allow the browser to go ahead and parse
them as they are downloaded.

Assuming a good connection, lots of the world doesn't have a good
connection or are using high latency mobile connections (where even if
the transfer speeds are high the overhead of making a request is also
high, so small files take a long time to be requested.

one gzipped large file is your best bet.

Jim.

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] Randy Webb [...] wrote:

pe**********@gm ail.com said the following on 3/22/2006 1:45 AM:

I'm curious about server load and download time if I use one big
javascript file or break it into several smaller ones. Which is better?
(Please think of this as the first time the scripts are downloaded so
that browser caching is out of the equation.)

That depends on your aim. IE will load them faster using separate files
and using separate files will allow the browser to go ahead and parse
them as they are downloaded.

Assuming a good connection, lots of the world doesn't have a good
connection or are using high latency mobile connections (where even if
the transfer speeds are high the overhead of making a request is also
high, so small files take a long time to be requested.

one gzipped large file is your best bet.

Not at all.

1. Not every UA supports gzip-compressed responses. Those which do not,
will (hopefully) be served the uncompressed version of that large
resource, with the known drawbacks. If one relies on gzip compression,
inevitably the resources will grow larger than usual, and so will the
loading time considerably if gzip compression is not supported by the
client.

2. Ideally each resource should be less than 1160 bytes, to easily fit
into one TCP/IP packet. It is therefore a Good Thing if resources
are not too large. However, one has to find a healthy balance between
the number of chunks the resource is split into and the size of each
chunk, because too many chunks require too many HTTP requests.

3. Functionality should be splitted into libraries that deal exactly
with a particular feature. That allows for easier maintenance of,
usually overall smaller download size if only a particular feature
from that feature set is needed, and it avoids problems for people
with older editors (that have a size limit).
PointedEars

[@sh]

> one gzipped large file is your best bet.

Jim.

I presume thats some sort of text compression? Does it make the file
unusable for editing without dezippin?

[Jim Ley]

On Wed, 22 Mar 2006 16:40:44 +0100, Thomas 'PointedEars' Lahn
<Po*********@we b.de> wrote:

Jim Ley wrote:
1. Not every UA supports gzip-compressed responses. Those which do not,
will (hopefully) be served the uncompressed version of that large
resource, with the known drawbacks.
Of course, there's no associated drawbacks, the total size of all the
files together or one file is the same, but you've saved all the bytes
in the headers, both request and recieve - gzip is also likely more
efficient on the larger single file (more identical tokens)
If one relies on gzip compression,
inevitably the resources will grow larger than usual,
There's no reason to conclude that.
2. Ideally each resource should be less than 1160 bytes, to easily fit
into one TCP/IP packet.
1160 bytes leaves you about 200 bytes for your js code, less if there
are large cookes etc., that's a pointless amount of code to split your
files into.

3. Functionality should be splitted into libraries that deal exactly
with a particular feature.
I can't agree, delivering multiple javascript files is slow,
particularly on high latency, or slow upload connections - such as
mobile services, you also increase the chance of a single of the many
failing which leads to more unpredictable failures - of course if you
live in the first world and use nothing but broadband connections, you
simply won't comprehend this, but please try and think outside your
own experiences.
That allows for easier maintenance of,
maintenance and what is delivered to the client are seperate issues,
don't confuse them, have a good build environment, much better than
imposing your maintenance constraints on your users experience.
usually overall smaller download size if only a particular feature
from that feature set is needed

You should never be serving redundant code, but that's got nothing to
do with the files you deliver to the client. Stop confusing authoring
practices and consumer practices.

Jim.

[Jim Ley]

On Wed, 22 Mar 2006 15:50:40 -0000, "@sh" <sp**@spam.co m> wrote:

one gzipped large file is your best bet.

Jim.

I presume thats some sort of text compression? Does it make the file
unusable for editing without dezippin?

well you normally handle such gzipping transparently in your
webserver.

Jim.

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Jim Ley wrote:
1. Not every UA supports gzip-compressed responses. Those which do not,
will (hopefully) be served the uncompressed version of that large
resource, with the known drawbacks.
Of course, there's no associated drawbacks,

There are.
the total size of all the files together or one file is the same,
No, it is not, by definition. In fact, one big library is very likely
to be smaller when gzip-compressed than the concatenation of several
gzip-compressed libraries, because there is greater redundance in it.

However, that does not help you with the fact that gzip-compressed
resources have no ultimate support on the Web nowadays. Content
negotiation (that fails sometimes, but I would disregard that as a
bug of the UA) cannot mitigate the fact that if gzip-compressed
responses are /not/ supported, the resource that is to be downloaded
is considerably greater than with support for such responses.
but you've saved all the bytes in the headers, both request and recieve -
gzip is also likely more efficient on the larger single file (more
identical tokens)
The drawback is that it is larger than the gzipped version, no matter how
many chunks there are. Using gzip compression as an argument that large
resources are OK nowadays simply does not hold water. Unless one wants
to completely disregard users of the mentioned UAs and slower connections.

If one relies on gzip compression,
inevitably the resources will grow larger than usual,

There's no reason to conclude that.

Yes, it is. It is simply human nature. If you rely entirely on something,
without understanding the repercussions of using it, you do not care about
what happens if it is not supported. How some people use, or rather
misuse, client-side scripting is a clear indication of this.

2. Ideally each resource should be less than 1160 bytes, to easily fit
into one TCP/IP packet.

1160 bytes leaves you about 200 bytes for your js code, [...]

How did you get that idea? I said _"ideally"_.
[...]

3. Functionality should be splitted into libraries that deal exactly
with a particular feature.
I can't agree, delivering multiple javascript files is slow,
particularly on high latency, or slow upload connections - such as
mobile services, you also increase the chance of a single of the many
failing which leads to more unpredictable failures - of course if you
live in the first world and use nothing but broadband connections, you
simply won't comprehend this, but please try and think outside your
own experiences.

Think of a third-worlder who simply wants to access vital information, and
you are forcing him to download a, say, 100K script file as-is (because his
UA is old enough not to support gzip-compressed HTTP responses), of which,
say, 1% of that code is really used on the site. Then reconsider what you
just said.

That allows for easier maintenance of,

maintenance and what is delivered to the client are seperate issues,

No.
don't confuse them, have a good build environment, much better than
imposing your maintenance constraints on your users experience.
Users' experience will be greatly tarnished by waiting to download for
code that is mostly not needed.

usually overall smaller download size if only a particular feature
from that feature set is needed

You should never be serving redundant code, but that's got nothing to
do with the files you deliver to the client.

It has. Using one big library for everything is serving loads of
redundant code.
Stop confusing authoring practices and consumer practices.

"Consumer practices"? You must be kidding.
PointedEars

[Ian Collins]

Thomas 'PointedEars' Lahn wrote:

Assuming a good connection, lots of the world doesn't have a good
connection or are using high latency mobile connections (where even if
the transfer speeds are high the overhead of making a request is also
high, so small files take a long time to be requested.

one gzipped large file is your best bet.

Not at all.

2. Ideally each resource should be less than 1160 bytes, to easily fit into one TCP/IP packet. It is therefore a Good Thing if resources
are not too large. However, one has to find a healthy balance between
the number of chunks the resource is split into and the size of each
chunk, because too many chunks require too many HTTP requests.
I can't agree with this. The higher the request to response packet
ratio, the more you suffer from latency issues, a real bugger on a poor
dial up or mobile connection.

A better argument would be to say the ideal size is the buffer size of
the client's TCP/IP stack (which tends to be at least 16K, less on
embedded devices, much more on desktops OSs). The server will send
multiple packets for one request, based on the clients advertised buffer
capacity.
3. Functionality should be splitted into libraries that deal exactly
with a particular feature. That allows for easier maintenance of,
usually overall smaller download size if only a particular feature
from that feature set is needed, and it avoids problems for people
with older editors (that have a size limit).

Agreed, but I don't think the editor argument is relevant these days!
This has nothing to do with optimising download times, more of a 'best
practice'.

--
Ian Collins.

[Thomas 'PointedEars' Lahn]

Ian Collins wrote:

Thomas 'PointedEars' Lahn wrote:

Assuming a good connection, lots of the world doesn't have a good
connection or are using high latency mobile connections (where even if
the transfer speeds are high the overhead of making a request is also
high, so small files take a long time to be requested.

one gzipped large file is your best bet.
Not at all.

2. Ideally each resource should be less than 1160 bytes, to easily fit

into one TCP/IP packet. It is therefore a Good Thing if resources
are not too large. However, one has to find a healthy balance between
the number of chunks the resource is split into and the size of each
chunk, because too many chunks require too many HTTP requests.

I can't agree with this. The higher the request to response packet
ratio, the more you suffer from latency issues, a real bugger on a poor
dial up or mobile connection.

(sic!)

Please learn to quote. With Mozilla/5.0, you should disable format-flowed
for posting, then the bug should go away.
A better argument would be to say the ideal size is the buffer size of
the client's TCP/IP stack (which tends to be at least 16K, less on
embedded devices, much more on desktops OSs). The server will send
multiple packets for one request, based on the clients advertised
buffer capacity.
The server will not send more packets than required, even if the TCP/IP
stack buffer size of the client is greater. The argument is void.

3. Functionality should be splitted into libraries that deal exactly
with a particular feature. That allows for easier maintenance of,
usually overall smaller download size if only a particular feature
from that feature set is needed, and it avoids problems for people
with older editors (that have a size limit).

Agreed, but I don't think the editor argument is relevant these days!

You know /all/ users? And it is still a fact that editing a large file
is considerably slower than editing a small file.
This has nothing to do with optimising download times,
Yes, it does. If you split features into one script file each, you will
only have to serve the code for the needed features instead of all the
code you have ever written. The overhead by more requests is negligible
compared to the overhead from a large amount of served, but in the end
unused code.
more of a 'best practice'.

A best common practice that has several grounds.
PointedEars