What is the best performance between inline Javascript code and pure Javascript code?

Question

This is a piece of code which is normally used by the majority of programmers:

<input type="text" id="myID" onchange="myFunction()" />
<script>
 function myFunction (){
 //DO THIS
 }
</script>

But in my case I prefer to create a file with .js extension that contains only Javascript and .html that contains only HTML. So in my index.html I have this line:

<input type="text" id="myID"/>

And in main.js I have this line:

function myFunction (id){
 $(id).change({
 //DO THIS
 });
 }
 myFunction("#myID");

The two methods are the same and do the same thing, but what is the best? What is the best performance between inline Javascript code and pure Javascript code?

• random_user_name: normally used by the majority of programmers - do you know this? Or is this just your assertion?
• Daniel W.: No matter how you do it, your computer is bored and does it equally fast. The question is, how can you work best with that code. The only real difference is, when having JS in an extra script, there is a second HTTP request with some overhead. But you can cache it np.
• pherris: I think the question would be improved by removing the jQuery reference in the external code - that is confusing an interesting discussion.
• ndugger: The best way would be document.getElementById(id).addEventListener("change", function() {}) -- No jQuery, lol
• ndugger: Do you mean jQuery is faster to type, or do you actually think that jQuery runs faster than native JS? Because you'd be wrong on the second one.

Answer 1

for performance script should be external because for maintenance & performance. Its better because if the code is separate, it can easly be cached by browsers.

yahoo rules https://developer.yahoo.com/performance/rules.html#external

Answer 2

At first, jQuery isn't pure JS.

If consider these snippets only and disregard the timeouts on HTTP requests, page loading and function calls overhead, the second would be slower than the first one.

Why?

$(id).change({
 //DO THIS
});

There we have a jQuery selector. Selector can be heavy (as you know, jQuery and document.querySelector accept CSS-like selectors) and thus negatively impact the performance. But in your case if this just IDs, jQuery might use built-in function document.getElementById which be faster than CSS-like query, but people say it still slow.

If talk in general, you won't see this little difference if

• external JS is cached on client-side, low-weight and ping to your server is low (even a request that tell you that JS isn't modified takes time);
• you're not dealing with a page with huge DOM and don't have to do this many times in a loop (100K and more iterations)

Of course, you should load JS asynchronously, place <script> tags to the bottom of the page to avoid possible loading/parsing lags and show content first, but in general you won't see the difference.

So I prefer place bindings to onclick or in <script> depending on what I need, where I need it, how fast I need it and how it would be hard to maintain it considering framework I'm using to build the site.

Answer 3

The external script has to be loaded by an additional HTTP request. From Google (https://developers.google.com/speed/docs/best-practices/rtt?hl=fr-FR#CombineExternalJS):

most browsers prevent the rest of the page from from being loaded while a JavaScript file is being downloaded and parsed

Once the code is loaded the speed is probably the same, but since you have to make that extra HTTP request it would seem that the external JS will load slightly slower (approximately the length of time it takes to make that extra HTTP request).

• Daniel W.: That's why you should put script and style just before </body>.
• Sebastien C.: An additional request for the first time, but it will be cached, so the payload will be reduced after the first page.

Answer 4

Please check this post Does the <script> tag position in HTML affects performance of the webpage?.

In case of performance comparison, they had a good analysis with the following case:

QUOTED

it does affect the performance of the web page.

The problem with JavaScript is that is blocks the execution/loading of the rest of the page. If you have something that takes a long time in your JavaScript then it will prevent the rest of the page from loading:

See these examples:

 Script at top, blocks whole page: `http://jsfiddle.net/jonathon/wcQqn/`
> Script in the middle, blocks bottom:
> `http://jsfiddle.net/jonathon/wcQqn/1` Script at bottom, blocks nothing:
> `http://jsfiddle.net/jonathon/wcQqn/3/` You can see the effect the alert
> has on the rendering of the rest of the pag

e. Any JavaScript that you

put into the top of your page will have the same effect. In general, it is better to put anything critical to the layout of your page (i.e. menu plugins or something). Anything that requires a user interaction (popup handlers) or doesn't involve the user at all (Google Analytics) should go to the bottom of the page.

You can get lazy loaders that will inject your script tags into your code. Since the code isn't on the HTML, you can be sure that your whole page has rendered correctly and that the JS you're including will not block anything