Do multiple inline JS scripts slow down loading time of a page?_问答_开发者

I'm trying to optimize the loading time of a site that has a lot of JS spaghetti code. Some of it actually l开发者_开发问答ooks like this:

<script>var x="foo";</script>
<script>var y="bar";</script>

Instead of the sane-programmer code:

<script>
    var x="foo";
    var y="bar";
</script>

So I was wondering whether this kind of thing actually does harm? Aside from the aesthetics, would combining the scripts into a single script tag bring any loading time benefit?

When a browser encounters a script element during the parsing of a page's HTML the following happens:

The browser pauses processing of the HTML.
The browser initiates an instance of its JavaScript interpreter.
The JavaScript interpreter compiles the JavaScript and adds it to the current page's global JavaScript pool.
The browser continues parsing the HTML, repeating 2. and 3. as many times as there are script elements in the HTML.

So, having multiple script elements will slow down rendering of the page. The fewer script elements present in the HTML the faster the page will render.

If your document is including scripts via the src attrbute (e.g. <script src="http://example.com/myscript.js">) then you can use the async attribute to delay script processing. This is a feature supported in newer browsers (e.g. Firefox 3.6 and Webkit based browsers released since September 2010). But inlined scripts will still block parsing until they have been interpreted.

Insofar as there are more bytes to download, the first example is slower.

However, I'm certain that you will never be able to differentiate between the negligible micro-optimization of the latter example and the former example. Other than organization, there's no reason to bother.

That said, for the sake of organization, I would definitely bother! Keeping your code organized will speed development time. Keeping all of your JavaScript in one place will prevent you from running around searching for a snippet.

I would strive to move as much code first into an external file, and anything else into the foot of your document.

You will garner the most speed benefit by using an external file (due to browser caching) than anything else.
You will allow your markup to be rendered by the browser before downloading or executing your JavaScript if you move the <script> tags to the footer of the page. This will create the illusion of a faster download.

Incidentally, (and just as trivially) the most optimized version of your script (aside from using an external file) would be:

<script>
    var x='foo', y='bar';
</script>

There's a difference between perceptive loading time and actual loading time.

The former is the most important to the end user. Some sites are never fully loaded because they have ads which are always continuing to refresh and load new content - that's why you see the status bar still working, even when it looks like the page is finished.

Your question seems theoretical, so I'll attempt a theoretical response.

When your first case might be faster

The optimal perceived loading time depends on what the two scripts do and what your site requires. If your site is JS-oriented, meaning the layout, styling, and HTML elements are created/controlled primarily by JavaScript, then the first way may be faster. You'd want to do all the visual processing and element creations in the first script. Really, you could have a blank HTML page and a purely JS created site (highly unadvised), but possible. This is hardly ever the case, but in that circumstance all the visuals and elements should be placed there. The second script should include all the other code that a user would not notice in a split second (slide show animations, hover effects, click methods).

Don't quote me on this, but I think that is because each script (in the HTML head) is interpreted after it's loaded, breaking the necessary and unnecessary scripts up could speed up some pre-processing.
Network/Interpretation Speed | Second case for most

Most sites are not as JavaScript dependent, though, so the second case is the general way to do things. There are size/cache-ing reasons for breaking custom code up, but for non-custom code, such as the various frameworks, there's a reason why there isn't a combined jQuery/Prototype framework, for people that use both. There are also some situations of placing inline code (in the body) might be more beneficial.

In most cases the second method, or a method similar to what Stephen listed is preferred. This is only because you are reducing the byte overhead that is transferred over the network; additionally you're minimizing the amount of characters the browser has to translate. The true over-optimized method would be <script type="text/javascript">x='foo',y='bar';</script> (no var needed).

When you type more things (js in your case) on a page, the page size increases which definitively slows down the performance.

You should combine your code in single <script> tags as well as js file.

You can use Google's Page Speed (addon of Firebug) which will suggest you about how you can improve the performance of your site :)

It's actually better to do it the second way that you have. It makes the code easier to maintain and read in that form. Another way would be to use external scripts.

The reason you sometimes see it the first way is because the site is including different files at different times.

you should definitely try using this cool tool cuzillion. It will help you locate fine-grained subtle speed effects like the one you are mentioning.

In your case it seems to say that there is a very small yet existing effect of opening several times the tag.