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]

(e-mail address removed) 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.

 

[Jim Ley]

(e-mail address removed) said the following on 3/22/2006 1:45 AM:

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]

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

 

[Jim Ley]

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]

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]

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.

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.

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.

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

 

[Thomas 'PointedEars' Lahn]

2. Ideally each resource should be less than 1160 bytes, to easily fit
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.

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

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/22/2006 12:36 PM:

There are.

Just as there are drawbacks to the converse. Everything has
drawbacks/negatives.

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.

gzipped or not is irrelevant as to whether you should use 10 small files
or 1 large one.

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.

You are arguing against gzip, not about whether to use 1 large or
several small files.

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.

Very true.

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.

As is the use of over-bloated code by people on broadband. If you argue
that larger files would become predominant with gzip then the same
argument holds for broadband users. And with the popularity of broadband
in the US that is going to become more the norm for websites - they use
broadband and ignore the non-broadband users.

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"_.

And he showed why it is not the "ideal" file size.

[...]

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's ignorance on the author's part, not a flaw in the mechanism used
to implement his/her ignorance. And has nothing to do with gzip.

Users' experience will be greatly tarnished by waiting to download for
code that is mostly not needed.

Again, that is ignorance on the author's part. If the page needs 100K of
script to be operational, are you better off with 1 100K file or 10
files that are 10K? And the answer depends on what the code is and there
is no blanket "Do this" answer.

It has. Using one big library for everything is serving loads of
redundant code.

Only if the code is redundant.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Tue, 21 Mar 2006 22:45:15 remote, seen in

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.)

There can be no safe, general answer, because it all depends on the type
of usage.

If you have 100 pages and 100 routines each used on only one page, and
if the nature of the pages is such that visitors are expected to go to
one page and then leave the site for long enough for cache expiry, then
there is clearly no point in delivering all 100 routines in one file.

OTOH, if the pages fetched by the anticipated visitors in one session
will between them use all the routines available, then all will have to
be delivered.

Faster is not necessarily better. If, as an author, you can make your
user saturate his link with your stuff, your page will load fastest.
But then the user cannot do anything else at the same time; he may wish
to be running, at the same time, a low-bandwidth server-CPU-linited
process.


Consider a target audience of many on-campus students in affluent first-
world universities : links will be high-bandwidth, and non-browser
cacheing may be active. How consider a target audience of third-world
fishermen : low-bandwidth, less effective cacheing. Clearly, it's
likely that the optimum solution will be different.


If you need to know the optimum, then the best you can do is to make the
tests, with typical data and users.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

[...]
Please learn to quote. With Mozilla/5.0, you should disable
format-flowed for posting, then the bug should go away.

I'll change the way I post when you get a proper sig.

I have a proper sig, for I have _no_ sig most of the time. There are two
signatures: the name, and the signature part (which is delimited with "--
"). Neither is the name required to be in the signature part, nor is the
signature part a requirement at all. In fact, you will see this seldom in
Usenet.

Proper quoting, however, is more of a necessity, because few people will
take the time to decipher unreadable discussions, so few people will read
your postings. Proper quoting is therefore recommended by Netiquette and
this newsgroup's FAQ Notes, et al.

No, read what I said again, the server will send several packets (if
required) for one TCP request if there is space in the client's receive
buffer. If a 4K page is requested, you will see three response packets
before the server waits for their ACKs. It's called windowing.

Read before declaring things void.

But in contrast to the standardized size of an TCP/IP packet (which I
considered more a side comment than a strong argument in favor or against),
you cannot know how big the actual client's TCP/IP stack buffer is. You
say that yourself.

So your argument, if it even qualifies as such, although it provides some
interesting information, /is/ void, or let us say irrelevant, regarding
the question how large resources should be, and so regarding the question
discussed, whether it is better to split a large script resource or not.


PointedEars

 

[Jim Ley]

No, it is not, by definition.

Of course it is 10 1000 byte files and 1 10000 byte file are the same
total size.

The drawback is that it is larger than the gzipped version, no matter how
many chunks there are.

What are you discussing, the question was do we have 10 1k files or 1
10k file, that's the topic at hand, and it's clear that 1 10k file is
better, especially if the client supports gzip, but even when it
doesn't also particularly on a slow uplink or intermintent
connection.

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"_.

Yes, but pretty irrelevant given the fact that so few scripts meet
your ideal.

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.

I would never suggest sending anyone 100k script file, but I would
certainly recommend it to anyone suggesting they send 10 10k script
files. You seem confused by what the question was. I certainly don't
recommend libraries.

No.

Of course they are, if they're not, you should improve your build
techniques.

It has. Using one big library for everything is serving loads of
redundant code.

This was not a question about libraries, stop pretending it was, it
was about is it better to send 10 10k files or 1 100k file, you
answered wrongly, and now you're trying to pretend it was a question
about libraries, where few here are going to disagree with you.

Jim.

 

[Thomas 'PointedEars' Lahn]

Of course it is 10 1000 byte files and 1 10000 byte file are the same
total size.

Will you please read more carefully? As I have already said, what you are
ignoring is that gzip compression is done per delivered resource, not per
connection. One 10000 byte (uncompressed) large resource can usually be
compressed better than 10 resources of a tenth of that size (uncompressed)
each because the large file contains more redundancy. That more redundancy
in the data allows for better compression of the data is a rule of thumb
about data compression.

I have also said that this fact (which worked in your *favor* -- did you
not recognize even that?) does not matter here because gzip-compressed
responses have no ultimate support on today's Web.

The drawback is that it is larger than the gzipped version, no matter how
many chunks there are.

What are you discussing, the question was do we have 10 1k files or 1
10k file, that's the topic at hand, [...]

And you have been arguing that because gzip compression exists, it does
not matter if it is one large file. Which is utterly wrong, as I have
pointed out. Do you have anything to say about this, or are you going
to do only another red herring?

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"_.

Yes, but pretty irrelevant given the fact that so few scripts meet
your ideal.

What you are ignoring is that I did not say the total amount of data
downloaded for a document and included resources should be less then
1160 bytes. I was referring to the resource, and there are several
scripts out there that would meet this standard, including your some
of your own (e.g. your xmlhttp.js is 510 bytes large, _uncompressed_).
However, as I already pointed out, that was only an /ideal/ mentioned
as a hook for the actual argument that resources should be small.

I would never suggest sending anyone 100k script file, but I would
certainly recommend it to anyone suggesting they send 10 10k script
files.

But, as you are kindly keep reminding me, the question was: One file or
many? At first you were recommending one file, and I have pointed out
that since it is likely that one file will grow large, it is not viable,
despite the possibility of transparent gzip compression. Now you are
saying you recommend many files. ISTM you are not really clear with
yourself which position your are going to take, and to argument for or
against.

You seem confused by what the question was.

/You/ really seem confused by what the question was.

I certainly don't recommend libraries.

That is an entirely different question. I wonder what you regard as
a library, though. Every script file could qualify as a library.
Especially the type of script file you argued for before would.

Of course they are, if they're not, you should improve your build
techniques.

In this case they are not, because the design decision has direct impact
to what is delivered to the client. Certainly you are not recommending
to create a library (or a script file, if you wish), and then not use it
as is (compacting code, for example by removing documentation comments,
considered already), are you?

It has. Using one big library for everything is serving loads of
redundant code.

This was not a question about libraries, [...]

The question was whether one should use one (big) script file or
several (smaller) ones.

I still wonder what you would call a library, however that does not matter
regarding the question discussed. What matters is the size, hence I wrote
"one *big* library". I could have also wrote "one *big* script resource",
the argument would still the same, and still be valid.

ISTM you are being deliberately obtuse, and are misunderstanding me
deliberately, because you know that your gzip argument does not hold
water. Probably by acting this way you think you can make anyone
believe that you do not have to defend it against the arguments being
brought up.


PointedEars

 

[Thomas 'PointedEars' Lahn]

I hadn't noticed the long line, in fact you are the first person to
mention it after many years of posting. Mozilla is set to wrap at 72
characters, I'll check into why what I see isn't what appears to be sent.

I you weren't so rude, people might not react the way they do to you
'hints'.

Rude? My original words were:

| Please learn to quote. With Mozilla/5.0, you should disable format-flowed
| for posting, then the bug should go away.

Your reaction to that kind request and advice was:

| [full quote again]
| I'll change the way I post when you get a proper sig.

And then I explained to you in great detail that and why you were wrong.
Now, who of us was rude?

I am not referring to your other "arguments", because your entire "argument"
is only a red herring (ignoratio elenchi[1]). Please troll elsewhere.


Score adjusted

PointedEars
___________
[1] <URL:http://en.wikipedia.org/wiki/Ignoratio_elenchi>

 

[Randy Webb]

Ian Collins said the following on 3/23/2006 12:40 AM:

Thomas 'PointedEars' Lahn wrote:

I am not referring to your other "arguments", because your entire
"argument"
is only a red herring (ignoratio elenchi[1]). Please troll elsewhere.

Well that's another first, I've never trolled or been called a troll in
a decade of Usenet use.

Welcome to the "Thomas called me a Troll" Club. You are member # 1232132
to date. Every time he calls you a Troll, you get a vote. I have around
16 million votes to date.

Welcome to the club and enjoy the benefits of membership

 

[Jim Ley]

Jim Ley wrote:
I have also said that this fact (which worked in your *favor* -- did you
not recognize even that?)

It was mentioned in my first post in the thread, so it's not
particularly relevant.

What are you discussing, the question was do we have 10 1k files or 1
10k file, that's the topic at hand, [...]

And you have been arguing that because gzip compression exists, it does
not matter if it is one large file.

No I've not, I've said because gzip exists, it adds even more
advantages to the single file.

What you are ignoring is that I did not say the total amount of data
downloaded for a document and included resources should be less then
1160 bytes. I was referring to the resource, and there are several
scripts out there that would meet this standard, including your some
of your own (e.g. your xmlhttp.js is 510 bytes large, _uncompressed_).

xmlhttp.js is not a file I'd use in a commercial environment (it
doesn't do anything), it's specifically designed as an education tool.
It's also completely irrelevant to a discussion about if it's one file
or many.

But, as you are kindly keep reminding me, the question was: One file or
many? At first you were recommending one file, and I have pointed out
that since it is likely that one file will grow large, it is not viable,

One file will grow no larger than many files, if you're incompetent
enough to let your pages grow indiscrimately, you'll do it regardless.

I still wonder what you would call a library,

any code that is specifically designed to be re-used across pages and
situations rather than doing the minimum required to solve the problem
relevant to the page.

Jim.

 

[Randy Webb]

Ian Collins said the following on 3/23/2006 2:09 PM:

Ian Collins said the following on 3/23/2006 12:40 AM:

Thomas 'PointedEars' Lahn wrote:

I am not referring to your other "arguments", because your entire
"argument"
is only a red herring (ignoratio elenchi[1]). Please troll elsewhere.

Well that's another first, I've never trolled or been called a troll in
a decade of Usenet use.

Welcome to the "Thomas called me a Troll" Club. You are member # 1232132
to date. Every time he calls you a Troll, you get a vote. I have around
16 million votes to date.

Welcome to the club and enjoy the benefits of membership

Do I get a T-shirt?

Yeah but you gotta get 100 votes first