Any difference between lazy Javascript file downloads versus placing just before </body>

Having looked around, it was not possible to find this specific question. Quite accurately, the difference is insignificant, just curious as to your thoughts.

Scenario: All Javascript that does not need to be loaded before rendering the page was placed immediately before the closing </body> . Are there any benefits or hindrances to lazily loading this data instead through some Javascript code in my head that executes when the DOM load / ready event fires? Let's say this only applies to downloading a single .js file full of functions, and not lazily loading several separate files as needed when used.

Hope this is clear, thanks.

+7
optimization javascript jquery javascript-events pagespeed
source share
2 answers

There is a big difference in my opinion.

When you embed JS at the bottom of the <body> , you force the page to load those <script> synchronously (should happen now) and sequentially (in line), so you slow down on the page since you have to wait for these HTTP calls to complete, and the JS engine is to interpret your scripts. If you put a lot of JS, assembled together at the bottom of the page, you can spend user time on the network sequence (in old browsers only 2 connections per host at a time), because the scripts can depend on each other, so you need to download them in order.

If you want your DOM to be ready faster (usually what is most expected of event processing and animation), you should reduce the size of scripts as little as possible, as well as parallelize them.

For example, YUI3 has a slight dependency resolution and loads a script that you must load sequentially on the page (see YUI3 seed.js). After that, you browse the page and collect the dependencies and make 1 asynchronous and pipelined call to your CDN (or your own servers) to get a big JS ball. After the JS ball returns, your scripts execute the callbacks you provided. Here's a generic pattern:

 <script src="seed.js"></script> <script> YUI().use('module', function(Y) { // done when the ball returns and is interpretted }); </script> 

I'm not a big fan of placing your scripts in one big ball (because if 1 dependency changes, you have to download and interpret it all again!), But I am a fan of pipe lining (combining scripts) and an event-based model.


When you enable event-based asynchronous loading, you get better performance, but maybe you don't perceive performance (although this can be counteracted).

For example, parts of the page may not load for a second or two, and therefore look different (if you use JS to change the style of the page, which I do not recommend) or are not ready to interact with the user while you (or those that host your site) will not return your scripts.

In addition, you must do some work to make sure that your <script> have the correct dependencies for the correct operation. For example, if you do not have jQuery or Prototype, you cannot successfully call:

 <script> $(function () { /* do something */ }); </script> 

or

 <script> document.observe('dom:loaded', function { /* do something */ }); </script> 

as the interpreter will say something like "Variable $ undefined". This can happen even if you add both <script> parameters to the DOM at the same time , since I would put jQuery or Prototype more than your JS application (so the data request takes longer). In any case, without any restriction, you leave this in case.


So the choice is really up to you. If you can segment your dependencies correctly, that is, put the things you need and lazily load other stuff later, this will lead to a faster overall time until you reach the DOM ready.

However, if you are using a monolithic library such as jQuery, or if the user expects you to be able to see something related to JS animation or style right away, an attachment might be better for you.

+8
source share

In terms of usability, you definitely should not do this with nothing, that the user expects a quick response from how the button has a double load, since the load trigger in addition to it performs other functions.

OTOH replaces pagination with continuous page loading as user scrolls are a very good idea. I find this distraction when the load trigger is closer to the end of the page, it is better to put it 1/2 - 3/4 down.

0
source share

All Articles