views:

88

answers:

4

I've noticed that $(document).ready(..) causes a noticable delay in applying javascript effects. However I also understand that just having the effect in a <script> can not always work because the DOM may not be ready.

When should you always put your code in $(document).ready and when is it ok to bring it out into a global <script> tag?

A: 

If you are going to work on the DOM (i.e. on any tag or element), make sure the DOM is ready. If this causes delays for you, consider making a simpler/smaller page so it loads faster. Simple $(document).ready() functions is often done before the page is rendered visually.

Emil Vikström
In firefox the lag for a typical page is like 3 seconds before the function runs...
Earlz
@Earlz - You have some other issue going on, did you open Firefbug to see what's running/waiting for so long? sounds like a slow-to-load script blocking.
Nick Craver
@Nick I'm getting 1.82s for `DOMContentLoaded` and 3.21s for `load`
Earlz
@Earlz - Can you look at your Net tab, check what's not loaded until then? Also try the same page in chrome, see if it's similar behavior or instant...lastly check that the HTML is valid here: http://validator.w3.org/ I've had FireFox hang up like this before, had to completely blow away the cache...if *other* browsers are instant, may be a similar situation for you.
Nick Craver
@Nick it is the same effect in Chrome and IE. The page is 80k in size..
Earlz
Ok so it has 118 validation errors.. guess I should try fixing those(most of it's generated code so really not that much work) before complaining more..
Earlz
@Earlz - That's not a huge page by today's standards, if you have a link I'll take a look after work.
Nick Craver
@Nick it's proprietary, so no I do not. but it is now down to 9 validation errors(all being missing alt attributes except for some extra `</table>` element that I'm currently tracking down) and it's still just as slow..
Earlz
+2  A: 

When the code needs elements to be ready, use $(document).ready(func), or just $(func), e.g. using selectors, anything to do with messing with elements at that time.

When the code doesn't need elements...e.g. defining (not using, defining) a plugin, don't wrap it in anything.

When you need elements and images loaded/ready, use $(window).load(func) instead.

Nick Craver
+3  A: 

There's no set rule for when you should and should not use it. The answer lies in whether or not your code needs to traverse parts of the DOM that won't exist when it executes. If you need to find an element by ID you can use this to let the DOM build before your code executes. If you don't care about the DOM then you don't need to use it.

The other approach is to move your script tags to the bottom of the body tag so that they are executed after the DOM has loaded. There's no major advantage / disadvantage to doing this either way, but it does make it harder to keep your code organized, while using $(document).ready() allows you to keep javascript in the head of your page even if it needs to execute at the end.

g.d.d.c
A: 

If I'm not mistaken, the $(document).ready(..) function should run on DOMContentLoaded, and not wait until the Load event is raised:

http://api.jquery.com/ready/

On the other hand, $(document).load(..) will execute once both the DOM is rendered, and all assets are loaded, which is useful if you rely on the properties of assets on the page (say, image dimensions).

Is the $(document).load(..) function in a <script> tag on your page, or is it in an external JS file that is referenced by your page? In the latter case, the delay may be partly due to script parsing.

Have you tried putting a global <script> tag at the bottom of your page, and run it in two different scenarios - once with just the $(document).load(..) function in it, and again with the contents of the load function in the script tag instead. Is there a significant difference in the JS effects running between those two cases?

Robert Hui