304 latency vs inlined javascript

There seems to be a general conclusion floating around the internet that external js files are better.

The main reasons are caching, maintenance, and debugability.

However there does not seem to be much discussion on the overhead of the 304 http requests. I went to yahoo.com, and noticed that 304's for each javascript file has an overhead of around 30 ms per file (mostly connection & response overhead).

I have separate javascript files (solving the maintenance problem). I don't have much need for debugability (automated tests are very helpful).

I'm considering whether or not to package and inline them into a single script tag on top of the html document. I'm aware there is a point where this does not 开发者_如何学编程make sense (when my javascript is very large) and I should benchmark this.

I'm just wondering if anybody has already done benchmarks on this on what sort of results have they gotten?

i also don't have benchmarks, it really depends on your connection latency also. but subjectively i never felt this latency much.

still i would recommend to split the dynamic content (html you render on server) and the static content (css, js). first of all the payload of your html gets much less (you save server render time + payload is lower) and further more it is a clean separation and from code perspective better maintainable.

if you want to avoid conditional GET (e.g. through Modified-Since or Etags headers), you can also use Expires header. Conformant browsers then don't make a http call at all.

Sorry, I have no benchmarks. I doubt the 30ms would be worse than having larger HTML documents and having to recompile the JS every visit (assuming newer javascript engines can or will in future keep and reuse the compiled bytecode if the JS file is cached).

Also, doesn't this depend on caching policy? Most sites I develop won't even issue a request if the JS file is cached, certainly not during a browser session, it'll go direct to the cache (I know this because I occasionally get calls from clients who need to press F5 to see my changes).

Another benefit is validity, it's not trivial to have valid JavaScript embedded into a XHTML+XML document. It's much easier to have external JS files if this is a factor.

You can also distribute your JS files and serve them from a Content Distribution Network, you'll definitely forfeit this opportunity to reduce server load if you choose to inline your JavaScript into your HTML.

I had a similar question a while ago, and decided to ask @getify and @zoompf, two front-end performance experts.

When is it acceptable to use inline <script> elements? When is it better to use separate .js files? The same question can be asked about inline vs. linked CSS — where do you draw the line?

See http://mathiasbynens.be/notes/inline-vs-separate-file for their responses.

I think the 304 requests could be avoided with the correct setting of caching headers.

cache-control:public, max-age=3600

As long as we set it to public it will allow the browser to cache files locally. So it will not even make a request to the server to validate if the file has changed for an hour.

If we only set

cache-control: max-age=3600

It seems that most browsers will think that they cannot cache the file, so it will check every time.

As for lots of js files which really adds a lot of overhead. I would crush them at build time using something like http://code.google.com/p/talifun-web/wiki/CrusherModule and serve up one js file with a strong etag by adding a querystring with an md5 hash of the file. So we are guarenteed a fresh file even if it changes before max-age expires.