load javascript asynchronously(without blocking browser)

[Denis]

Hello,
Maybe somebody already solved this task. I need to load JS
asynchronously without blocking browser. This means that I do not need
to block browser to load/render during loading script. The simple
construction to do this:

jsJSNode = document.createElement(“script”);
jsJSNode.type = “text/javascript”;
jsJSNode.src = “http:// den-01/Default.aspx“;
document.body.appendChild(jsMyNode);

works fine in IE6 & IE7. (By fine I mean – IE loads script
asynchronously and DOENT block the browser)

But the same code works synchronously in Firefox (blocks FF). The
strange situation because many websites say that download with be
asynchronously (e.g. http://ntt.cc/2008/02/10/4-ways-to-dynamically-load-external-javascriptwith-source.html).

My Default.aspx is:
protected void Page_Load(object sender, EventArgs e)
{
Thread.Sleep(200000); //just for show that FF is blocked
Response.Buffer = true;
Response.Clear();
Response.ContentType = "application/x-javascript";
Response.Write(“var var1 = 1;”);
}

And with this Default.aspx FF hangs. Does anybody knows how to solve
this task? (I can’t use XHR because there will be _crossdomain_ call
and this call will be blocked with FF anyway). I know that there is
attribute “defer” but it works for IE only.
Want to clarify task again: I need to get small JS that will contain
variable to my page. But this data is not critical and if server that
provides this data will go down for some reason I want to show page
anyway (the page and this data JS are in different domains). With IE
everything is fine but doesn’t work with FF (other browsers are not
critical at this moment)

Thank you,
Denis

 

[Thomas 'PointedEars' Lahn]

Maybe somebody already solved this task. I need to load JS
asynchronously without blocking browser. This means that I do not need
to block browser to load/render during loading script. The simple
construction to do this:

jsJSNode = document.createElement(“scriptâ€);
jsJSNode.type = “text/javascriptâ€;
jsJSNode.src = “http:// den-01/Default.aspx“;
document.body.appendChild(jsMyNode);

works fine in IE6 & IE7. (By fine I mean – IE loads script
asynchronously and DOENT block the browser)

But the same code works synchronously in Firefox (blocks FF).

It wasn't even a good idea to begin with. Why not generate the `script'
element in the first place?

[...]
And with this Default.aspx FF hangs. Does anybody knows how to solve
this task?
XHR.

(I can’t use XHR

Yes, you can. But it makes everything only less compatible.

because there will be _crossdomain_ call
and this call will be blocked with FF anyway).

And IE and ...

However, you can access the server-side proxy script available with the same
protocol, domain and port component in the URI.


PointedEars

 

[VK]

Hello,
Maybe somebody already solved this task. I need to load JS
asynchronously without blocking browser. This means that I do not need
to block browser to load/render during loading script. The simple
construction to do this:

jsJSNode = document.createElement(“script”);
jsJSNode.type = “text/javascript”;
jsJSNode.src = “http:// den-01/Default.aspx“;
document.body.appendChild(jsMyNode);

As you properly noticed, alas FF doesn't support "defer" attribute.
Try to add new nodes to the head section and not to the body.

var docHead = document.getElementsByTagName('head')[0];
docHead.normalize(); // before the first use
// it is not required but siggested
docHead.appendChild(jsMyNode);

be aware that there is some undocumented limit for <script> and
<style> elements in the head section. I didn't find yet any official
numbers, but while developing JSONet
http://jsnet.sourceforge.net
IE6 hanged up sporadicly on 32> <style> blocks and FF2.0 on about 52
blocks. This way if you are planning intensive script insertion, I
would highly suggest to provide finalize mechanics for used elements
(remove from the tree and kill all references). This is what I used
and ever after the program became stable on high load.

 

[Thomas 'PointedEars' Lahn]

As you properly noticed, alas FF doesn't support "defer" attribute.
Try to add new nodes to the head section and not to the body.

This is obviously not going to make it any better, because then nothing is
displayed at all until the script has finished loading.


PointedEars

 

[Denis]

It wasn't even a good idea to begin with. Why not generate the `script'

element in the first place?

What do you mean "generate"?

XHR.
Yes, you can. But it makes everything only less compatible.

No I can't - FF: "Permission denied to call method
XMLHttpRequest.open"

However, you can access the server-side proxy script available with the same
protocol, domain and port component in the URI.

Unfortunately not. I do not have access to server where page is
hosted. I can only ask webdevloper to put my JS on it. I have only
access to my server where only generated JS located.

 

[Denis]

Try to add new nodes to the head section and not to the body.

var docHead = document.getElementsByTagName('head')[0];
docHead.normalize(); // before the first use
// it is not required but siggested
docHead.appendChild(jsMyNode);

Thank you! I tried but this doesn't help - FF waits for script and
do not render anything.

be aware that there is some undocumented limit for <script> and
<style> elements in the head section. I didn't find yet any official
numbers, but while developing JSONethttp://jsnet.sourceforge.net
IE6 hanged up sporadicly on 32> <style> blocks and FF2.0 on about 52
blocks. This way if you are planning intensive script insertion, I
would highly suggest to provide finalize mechanics for used elements
(remove from the tree and kill all references). This is what I used
and ever after the program became stable on high load.

Good point, Thank you very much!

 

[VK]

Try to add new nodes to the head section and not to the body.

var docHead = document.getElementsByTagName('head')[0];
docHead.normalize(); // before the first use
// it is not required but siggested
docHead.appendChild(jsMyNode);

Thank you! I tried but this doesn't help - FF waits for script and
do not render anything.

Wait a second. What do you actually mean by "blocking browser"? I
meant script insertion into DOM tree some later, after document load
event. In this case there should be no "blocking" unless issuing
synchronous XHR call.

For the initial document load the page is not rendered until browser
processes all instructions in window.onload handler. This way
window.onload = someFunction doesn't mean "show the page and do
someFunction". It means "do not display the page, do someFunction,
then display the page. So window.onload - if set - is treated as the
last chance to alter the document before actually show it. This
behavior consistent across all browsers - not FF only.

If one needs to initiate some scripting on document load yet he wants
to show the document right away, use overlay call to release the
graphics context:

window.onload = releaseContextAndInit;

function releaseContextAndInit() {
window.setTimeout('init()',10);
}

function init() {
// now take you time
// to do what you need
}

 

[Thomas 'PointedEars' Lahn]

What do you mean "generate"?

I took it you have a server-side script could generate the `script' element
server-side instead. My bad.

No I can't - FF: "Permission denied to call method XMLHttpRequest.open"

This statement was made with the provision below, of course.

Unfortunately not. I do not have access to server where page is hosted. I
can only ask webdevloper to put my JS on it. I have only access to my
server where only generated JS located.

Ahh, now I see, it is the other way around? Well, then the problem would be
both on the part of the person who includes your script this way and your
ASP.NET resource. You should therefore ask in an ASP.NET group as the
problem would probably not be language-specific.

Using a registered MIME media type instead (recommended: text/javascript)
could help as well.

And please provide an attribution line next time.


PointedEars

 

[Denis]

Wait a second. What do you actually mean by "blocking browser"?

Sorry, my fault. Have to be more descriptive.

I have number of pages that reside on many different web
servers(assume very big for patching server side for each). And I have
another one server (name it MyServer) that provides some information
(e.g. var RedirectTo = "www.google.com". So all this pages (not
pages of course but their owners) agreed to include my small script at
the begging (right after <body> tag, I can change architecture at this
moment, this is requirement) and do redirection if needed. Also there
is another requirement: if MyServer is expecting any troubles with
response these pages have to load as usual (they all grant me 10ms to
make or not make redirection).
With IE I simple don't have issues - it loads JS from MyServer in
separate thread and I just check (several times during 10ms) is
variable here or not. If not here in 10 ms I allow page to be rendered
and than don't think about this variable. So with such task it is not
good to wait till whole page loaded and than do redirection (bad
customer experience).

-Denis

 

[Thomas 'PointedEars' Lahn]

Wait a second. What do you actually mean by "blocking browser"?

Sorry, my fault. Have to be more descriptive.

I have number of pages that reside on many different web
servers(assume very big for patching server side for each). And I have
another one server (name it MyServer) that provides some information
(e.g. var RedirectTo = "www.google.com". So all this pages (not
pages of course but their owners) agreed to include my small script at
the begging (right after <body> tag, I can change architecture at this
moment, this is requirement) and do redirection if needed. [...]

I think there is your problem. Your script has to be loaded *in* the <body>
tag, in the `onload' attribute value of the `body' element instead:

<body onload="loadYourScript();">

That way it won't block loading the other content but will be triggered when
the rest of the content has finished loading. It is also the only way you
can be pretty sure that you actually can modify the document tree as
required (don't forget the feature tests at runtime, though). Including
scripts this way is still not reliable, though.

Please provide an attribution line above the quote next time. You are using
Google Groups, it should not be that hard to leave it in.


PointedEars