views:

1753

answers:

11

I would like to know when I should include external scripts or write them inline with the html code, in terms of performance and ease of maintenance.

What is the general practice for this?

Real-world-scenario - I have several html pages that need client-side form validation. For this I use a jQuery plugin that I include on all these pages. But the question is, do I:

  • write the bits of code that configure this script inline?
  • include all bits in one file that's share among all these html pages?
  • include each bit in a separate external file, one for each html page?

Thanks.

+19  A: 

The rule is simple: All script should be external. Both for maintenance and performance.

(Why performance? Because if the code is separate, it can easier be cached by browsers.)

JavaScript doesn't belong in the HTML code and if it contains special characters (such as <, >) it even creates problems.

Konrad Rudolph
Agreed. And I'll add that you can put the < script > inclusion tag AT THE END of the html code as yahoo recommands it for performance reasons too (http://developer.yahoo.com/performance/rules.html#postload)
e-satis
@zach: putting a script tag in your HTML is *not* obtrusive JS. @konrad: you can easily overcome the < > problems by wrapping your code in a CDATA section.
nickf
@Nick: most problems can be overcome. Better not to generate them in the first place, though.
Konrad Rudolph
A: 

In your scenario it sounds like writing the external stuff in one file shared among the pages would be good for you. I agree with everything said above.

mattlant
+1  A: 

During early prototyping keep your code inline for the benefit of fast iteration, but be sure to make it all external by the time you reach production.

I'd even dare to say that if you can't place all your Javascript externally, then you have a bad design under your hands, and you should refactor your data and scripts

Robert Gould
+2  A: 

Maintainability is definitely a reason to keep them external, but if the configuration is a one-liner (or in general shorter than the HTTP overhead you would get for making those files external) it's performance-wise better to keep them inline. Always remember, that each HTTP request generates some overhead in terms of execution time and traffic.

Naturally this all becomes irrelevant the moment your code is longer than a couple of lines and is not really specific to one single page. The moment you want to be able to reuse that code, make it external. If you don't, look at its size and decide then.

Horst Gutmann
That's one of my concerns. Having a separate HTTP request for a few lines of codes seems wasteful.
Dan
Could you perhaps post a sample configuration for your code? IMO if it's under 300 characters and absolutely page-specific, inline it.
Horst Gutmann
+6  A: 

Externalizing javascript is one of the yahoo performance rules: http://developer.yahoo.com/performance/rules.html#external

While the hard-and-fast rule that you should always externalize scripts will generally be a good bet, in some cases you may want to inline some of the scripts and styles. You should however only inline things that you know will improve performance (because you've measured this).

Joeri Sebrechts
I think Yahoo also recommend adding all the Javascript into one HTTP call too - this doesn't mean that the scripts should all be in the same file during development though
Paul Shannon
+1  A: 

I would take a look at the required code and divide it into as many separate files as needed. Every js file would only hold one "logical set" of functions etc. eg. one file for all login related functions.

Then during site developement on each html page you only include those that are needed. When you go live with your site you can optimize by combining every js file a page needs into one file.

Gene
+1  A: 

Three considerations:

  • How much code do you need (sometimes libraries is a first-class consumer !-)
  • Specifity (is this code only functional in the context of this specific document or even element)
  • Every code inside the document tends to make it longer and thus slower. Besides that SEO considerations makes it obvious, that you minimize internal scripting ...
roenving
+2  A: 

i think the specific to one page, short script case is (only) defensible case for inline script

Gene T
Thank you for the resource.
Dan
A: 

External scripts are also easier to debug using Firebug. I like to Unit Test my JavaScript and having it all external helps. I hate seeing JavaScript in PHP code and HTML it looks like a big mess to me.

Clutch
A: 

On the point of keeping JavaScript external:

ASP.NET 3.5SP1 recently introduced functionality to create a Composite script resource (merge a bunch of js files into one). Another benefit to this is when Webserver compression is turned on, downloading one slightly larger file will have a better compression ratio then many smaller files (also less http overhead, roundtrip etc...). I guess this saves on the initial page load, then browser caching kicks in as mentioned above.

ASP.NET aside, this screencast explains the benefits in more detail: http://www.asp.net/learn/3.5-SP1/video-296.aspx

Brendan Kowitz
+1  A: 

Another hidden benefit of external scripts is that you can easily run them through a syntax checker like jslint. That can save you from a lot of heartbreaking, hard-to-find, IE6 bugs.

Ken