tags:

views:

48

answers:

3

Consider the following document

<html>
    <body>
        This is some content
        <script type="text/javascript" src="verySlowToRespond.js"></script>
        This is some more content
    </body>
</html>

I'd like first to check my assumption that it is unsafe for the browser to parse beyond the script tag until the script has loaded and executed.

This means that (if my assumption is correct), say verySlowToRespond.js takes 20 seconds to respond, the page DOM cannot be fully assembled until this dependency is resolved.

Supposing verySlowToRespond.js hung about indefinitely? At what point would the browser give up and continue with the parse?

+2  A: 

Yes your first assumption is correct. Browsers stop rendering until <script> tags finishing loading AND executing.

The behavior on very long running scrips is browser-dependant. Newer browsers will often give you a chance to abort the script. Older browsers may need to be force-closed.

Triptych
+2  A: 

Correct: the browser won't continue beyond the script tag until it's read and evaluated it.

The browser gives up based on the same timeout rules it uses for pages. It depends on the browser, and on the exact nature of the timeout.

I'm wondering why there'd be such a thing as a slow-to-respond script. Is there something wrong with your hosting? Is the script slow to respond, or does it load and then take a really long time to run?

Pointy
It's a hypothetical question that I have to ask because we are delivering a Javascript based widget to third party pages, and in the case that our servers are not in tip top shape they might run into issues caused by us. We wouldn't want a snappy CDN'ed site to be slowed waiting for us to deliver. I already have a much better delivery mechanism in place, but I am trying to write documentation to support the issues I found with the previous delivery method.
spender
Well one way to get around the problem is to have your content included inside an `<iframe>`. If you do that, then the browser won't wait because the frame is treated as a completely separate page environment. Inside the frame of course the browser *will* wait, but that won't affect the containing page.
Pointy
+1  A: 

You are correct. The browser will not render the rest of the page until that script has finished. The timeout would be dependent on the underlying socket properties I suppose.

If you are concerned about the loading time of a script, it is important that the script not make any DOM changes that need to be executed before the rest of the page renders. Then you can add an onload handler to call setTimeout to execute code to load the script asynchronously.

Dan