What is faster and why?

views:

answers:

+1 Q:

What is faster and why?

For maintainability reasons, I want to database drive my javascript, in that I only want to send the javascript which is needed based on the users options.

So, is it faster/less resource heavy to have links in the database pointing to javascript files, then using response.writefile to embed those files into the clientside page, or is it faster/less resource heavy to stick the javascript script straight into the database, and response.write it onto the screen as and when needed?

+3 A:

So, is it faster/less resource heavy to have links in the database pointing to javascript files

Usually yes.

External Javascript files can be cached by the browser, and will be loaded only once. Javascript code injected into the HTML page needs to be loaded every time, which increases bandwidth and loading times.

Also, having JavaScript code in a static file (instead of a dynamic one that fetches the code from the database on every request) is bound to be the fastest and least resource-intensive solution.

Pekka 2010-09-30 10:46:24

So it seems that response.writefile'ing a javascript link is better than response.write'ing javascript?

oshirowanen 2010-09-30 10:57:49

@oshiro I don't really understand why you need to use `response.write/writefile` at all? Why not just link to the static resource?

Pekka 2010-09-30 11:01:39

It was my idea that the OP will lookup the references to the files (from the DB) needed and then write them to the page.

m.edmondson 2010-09-30 11:03:50

@eddy yup, that would make sense

Pekka 2010-09-30 11:07:31

@ Pekka, basically, I have a lot of javascript files for maintainability reasons, and I thought that if I using static methods to stick links to these scripts straight into each page, even when the javascript is not needed, will that not make things unneccessarily slower than only using specific scripts based on user options from my web app?

oshirowanen 2010-09-30 11:07:46

@oshirowanen as long as those js files are libraries only (i.e. they don't actively *do* anything) I'd say it's usually better to have one big static file that needs to be loaded only once. There are no performance implications by having "dead weight" Javascript on a page as far as I know. Consider the example of jQuery: The whole library is linked to every time, even if just a small fading function is really needed. If splitting the library into dynamic chunks would improve performance, I trust the large JS libraries would employ the technique. But none of them does.

Pekka 2010-09-30 11:12:07

@oshirowanen - Couldn't agree more! Check my answer

m.edmondson 2010-09-30 11:13:58

+2 A:

Don't use Response.Write.
Be aware that if you send the entire JS file once, the client will / should cache it so it doesn't have to be sent again.
DB lookups for every page just to get the relevant JS will be slow.

ck 2010-09-30 10:46:32

So if I have lots of well named javascript files in a directory, and response.writefile them to the page, will that not cache the javascript files?

oshirowanen 2010-09-30 10:56:30

Why would you Response.Write when they already exist as files?

ck 2010-09-30 11:19:23

So I can dynamically choose which scripts gets sent to the user based on users settings instead of sending a huge amount of javascript.

oshirowanen 2010-09-30 11:23:59

If what you are sending is dynamic, then it can't be cached. If you only link to the correct files and let the browser pull them normally, then each file will be cached.

ck 2010-09-30 11:28:02

+1 A:

By only sending the links to the javascript to the client a seperate HTTP request will have to be created in order to go and get each file.

If you embed only the required javascript directly into the page when needed this prevents this. Look at jQuery, thats got a load of javascript available to the client that isn't being used.

Less HTTP requests generally results in a faster website so I would go with embedding the code directly.

Edit:

I disagree with the caching answers above. If you ensure only the smallest amount of javascript that is required is embedded then my answer should be faster. This page will be cached too!

m.edmondson 2010-09-30 10:47:19

If the page is dynamic, it won't be cached.

ck 2010-09-30 10:54:15

If you embed only the required javascript directly into the page when needed this prevents this.

oshirowanen 2010-09-30 10:57:01

Is that the same as response.writefile?

oshirowanen 2010-09-30 10:57:26

As there will be database lookups in both scenarios you're basically saying to replace some of these with seperate HTTP requests to the files? So replacing lookups from a database (in a network you can control) with requests over a network you can't (the internet) is faster?

m.edmondson 2010-09-30 10:59:12

So 10 js files, all statically linked to in my dynamic page, even though 9 of them are not needed for a specific users settings, will be faster than using response.writefile to get the single js file needed based on the users settings?

oshirowanen 2010-09-30 11:13:45

@oshirowanen - Thats not what I'm saying. My answer says to embed only the code you need (i.e. 1 js file) but to embed it DIRECTLY into the page, instead of forcing a new HTTP request to get it from elsewhere (i.e. the linking answers above)

m.edmondson 2010-09-30 11:17:00

@eddy556 - you only *force* an http request to get it elsewhere once. After that, the browser has it cached. However for small amounts of JS (i.e. one or two functions) embedding it in the page isn't a problem, except for the extra DB lookup(s) required to get the JS.

ck 2010-09-30 11:30:47

Okay I think this answer depends entirely on the amount of javascript we're talking. However I think my answer is valid for some quite sizeable chunks, especially if its been minimized.

m.edmondson 2010-09-30 11:34:49

ansaurus

tags:

views:

answers:

What is faster and why?

related questions