问题
It is always recommended to avoid inline Javascript codes by putting all codes in a JS file, which is included in all pages. I wonder, if this does not cause performance problem in heavy pages.
For example, imagine that we have tens of functions like this
function function1(element){
var el=document.getElementsByClassName(element);
var size=el.length;
if(size==0) return;
for(i=0;i<size;i++){
// the process
}
}
on every page, we need to run the functions to know if there are corresponding elements in the HTML or not.
window.onload = function(){
function1('a');
....
function26('z');
};
but if keeping all functions in an external JS file, and calling functions through inline JavaScript, we can call only the functions, which are required in the present page:
<script type="text/javascript">
window.onload = function(){
function6('f');
};
</script>
Doesn't it beneficial from performance point of view to call functions via inline Javascript (which is of course not best practice) to avoid call of lots of functions, which are not needed in a page?
Of course, this is not limited to functions only, as we have lots of addEventListeners for the entire website, which are fired on each and every page, where they are not needed.
回答1:
It's not recommended to inline static resources (in your case, the inline javascript) since you can't cache them.
Caching a static resource reduces the size of page loads – thus increasing the page load speed – for returning visitors. However it comes at the cost of an additional HTTP request which should be avoided.
Whenever the static resource is so small that the additional size is negligible in comparison to a HTTP request, then it's actually recommended to keep that resource inline.
It's usually a good idea to keep javascript libraries in external (cacheable) documents, while keeping small amounts of scripts inline.
So, in response to your headline – inline javascript isn't bad per-se. It's a balance whether or not it's worth a HTTP request to cache the resource.
回答2:
Avoiding inline js is not performance based...but its more about maintainability and separating the presentation layer(html) from the controller layer(js).
Having inline js on different pages will make it difficult to maintain for you and others as the project scale increases.
Moreover using separate js files you can encourage reusability and modular code design.
keeps your html clean and you know where to look when any js error occurs instead of multiple templates.
回答3:
You should read about unobtrusive javascript, http://en.wikipedia.org/wiki/Unobtrusive_JavaScript.
There are other solutions for not loading all the javascript files in your assets directory for each webpage, one called requirejs that should check out, http://requirejs.org/ .
Moreover as a general rule of thumb you should not be adding all your event listeners when page loads, what about dom objects that don't exist? It will throw up javascript errors and will break your code more than usual.
回答4:
It's possible that running unnecessary JavaScript on a page will cause that page to be slow to load. It depends on the JavaScript being run.
You could test your example code by timing it, and seeing how long it takes for JavaScript to run getElementsByClassName repeatedly.
(I'd bet it doesn't take very long at all, even if you've got 26 functions looking for elements with different class names, but with performance, always measure first.)
If execution time is a problem, you could write your JavaScript so that it's mostly in one file, but expose functions that you run from inline JavaScript on the pages it's required on, instead of running it via onload events in your JavaScript file.
It's worth remembering everything that has to happen when a page is loaded though:
- The browser fetches the page from its cache, or sends an HTTP request to see if the page has changed since it was cached, and/or sends an HTTP request for the page itself.
- The browser parses and renders the page, pausing to fetch and run any external JavaScript, and fetching stylesheets and images concurrently with parsing and rendering.
- The browser runs any JavaScript set to run on document ready.
- The browser runs any JavaScript set to run on page load.
Although you certainly can write JavaScript that runs slowly, it's likely that it's better overall to have your JavaScript in an external file, and therefore in the user's browser's cache, rather than having it increasing page size by being inline. Network, in general, tends to be much slower than JavaScript parsing/execution.
But, and I'm saying this again because it's the most important point, this will all be different depending on your code. If you want to keep your performance good, your first and last act must be to measure it.
回答5:
there are variuos case that needs to be keep in mind while placing js code.
For inline :
there is no need to navigate to an external file if you need to change something quickly, so its better in locality
if you are using AJAX in some elements of your page you may loose all the dom element onclick etc for that section, that obviously depends on how you binded them. for ex you can use live or delegate in case your using jQuery to avoid above said problem... but i find that if js is small enough it is preferable to just put it inline.
Now there other theory for ex
Externalizing javascript is one of the yahoo performance rules:
http://developer.yahoo.com/performance/rules.html#external
回答6:
Making js inline to all pages make the application heavy so we should go with external js which includes to require pages that will help us to utilization of js code to each functionality.
回答7:
Inline styles/script gets muddled with html content and can get hard to differentiate. One of the the keys to having maintainable code in web development is writing code that is easily readable by someone who didn't write it. Mixing script tags into your html can make it very hard to find a function that is affecting the rest of you code. Putting Javascript in .js files and Styles in CSS files makes code cleaner more readable.
来源：https://stackoverflow.com/questions/19002690/why-inline-javascript-is-bad