CODEWITHSUNDEEP
javascripthtml
Ant
Ant

Reputation: 131

JavaScript as part of the page VS. <script src="">

I have 500 lines of JavaScript code on my page and right now it is placed in the footer.

If I move it to a separate file and include as <script src="script.js"></script>, will it affect the loading speed or performance in any way?

Upvotes: 0

Views: 586

Answers (2)

connexo
connexo

Reputation: 56744

If included like you suggest, your external script will be a render-blocking resource, meaning the HTML parser will stop at the point where it finds your <script> tag, fetch the external resource (meaning your page causes an additional GET request), then parse and execute the Javascript it contains, and only then the HTML parser will continue parsing the HTML after the </script> tag.

If the execution does not necessarily have to be at that point in time, but can also happen later, after the HTML is fully parsed, you have two options:

<script src="script.js" defer></script>

Adding the defer attribute will do two things:

  1. It delays execution of the Javascript until the DOM is fully parsed.
  2. It delays the end of the DOMContentLoaded event until the script is fully executed.

Note that fetching the script is still render-blocking, meaning the HTML parser will stop until the external script is loaded (but not until it's executed!).

<script src="script.js" async></script>

Adding the async attribute will do two things:

  1. The browser initiates the fetching of the external script as soon as it meets your script tag, but immediately after launching the request it will continue parsing the page.
  2. As soon as the script is fully fetched, the script will execute.

Please note that 2. also implies you cannot predict execution order if you have several async loaded scripts. Whatever loads first runs first.

async loaded scripts also don't wait for DOMContentLoaded, which means the event may already be over, or still come, you don't know with async.

Upvotes: 1

t.niese
t.niese

Reputation: 40842

Depends, in a normal HTTP/1.x setup will slow down the time until the script is executed for the first load if nothing is cached, as it needs to issue two requests, one for that page and one for the script as soon as the script tag is encountered. If it is noticeable depends on how many other files are loaded.

For subsequent requests, it depends on how your caching policies are set for the files. In the worst case, it will still issue a request to the file, and get 304 response from the server if the file was not modified, this will be slightly faster because no data is transferred but there will still be an additional request. But it might be faster than your solution because the script data is not sent on each request.

Again if it will be noticeable depends on how many other requests are sent to the server and how large the embedded script is.

You can set the caching policy in a way that the browser won't recheck if the file was updated, in that case no additional request will be done and it shouldn't be slower then embedding the script, but you then need a strategy how you can force an update. This is normally done by placing the static resource in a path that is prefixed by a hash or timestamp and change that.

With HTTP/2 you can send all files that are required with the request, so in that case, the client would not have to issue a second request for the script, and it would be as fast as having an embedded script. And with respect to the transferred data, it would be the same as your solution. But then you need a strategy that you don't send the script with each request as this would slow down subsequent requests. This can be solved with e.g. cookies.

Upvotes: 1

Related Questions