When looking to improve a page's performance, one technique I haven't heard mentioned before is using setTimeout to prevent javascript from holding up the rendering of a page.
For example, imagine we have a particularly time-consuming piece of jQuery inline with the html:
$('input').click(function () {
// Do stuff
});
If this code is inline, we are holding up the perceived completion of the page while the piece of jquery is busy attaching a click handler to every input on the page.
Would it be wise to spawn a new thread instead:
setTimeout(function() {
$('input').click(function () {
// Do stuff
})
}, 100);
The only downside I can see is that there is now a greater chance the user clicks on an element before the click handler is attached. However, this risk may be acceptable and we have a degree of this risk anyway, even without setTimeout.
Am I right, or am I wrong?
The actual technique is to use
setTimeout
with a time of 0.This works because JavaScript is single-threaded. A timeout doesn't cause the browser to spawn another thread, nor does it guarantee that the code will execute in the specified time. However, the code will be executed when both:
Therefore calling
setTimeout
with a time of 0 can be considered as temporarily yielding to the browser.This means if you have long running code, you can simulate multi-threading by regularly yielding with a
setTimeout
. Your code may look something like this:Note: While it's useful to know this technique in some scenarios, I highly doubt you will need it in the situation you describe (assigning event handlers on DOM ready). If performance is indeed an issue, I would suggest looking into ways of improving the real performance by tweaking the selector.
For example if you only have one form on the page which contains
<input>
s, then give the<form>
an ID, and use$('#someId input')
.You are correct, there is a greater chance of a "missed" click, but with a low timeout value, its pretty unlikely.
setTimeout()
can be used to improve the "perceived" load time -- but not the way you've shown it. UsingsetTimeout()
does not cause your code to run in a separate thread. InsteadsetTimeout()
simply yields the thread back to the browser for (approximately) the specified amount of time. When it's time for your function to run, the browser will yield the thread back to the javascript engine. In javascript there is never more than one thread (unless you're using something like "Web Workers").So, if you want to use
setTimeout()
to improve performance during a computation-intensive task, you must break that task into smaller chunks, and execute them in-order, chaining them together usingsetTimeout()
. Something like this works well:Note:
setTimeout()
.1
. This is sufficient to cause a yield, and the browser will take the thread if it needs it, or allow the next task to proceed if there's time. You can experiment with other values if you feel the need, but usually1
is what you want for these purposes.