Friday, September 12th, 2008

Delayed Script Execution; An Opera feature that has Steve excited

Category: Performance

Steve has found a new tidbit that has him excited. The feature at hand comes from Opera

Primarily for low bandwidth devices, not well-tested on desktop. Ignore script tags until entire document is parsed and rendered, then execute all scripts in order and re-render.

Steve explains how you he is a fan of splitting up JavaScript into a small core, and then loading other functionality asynchronously later. This defer gives you some of that benefit, and also groks document.write, which no other technique works with:

One limitation of these techniques is that you can’t use document.write, because when a script is loaded asynchronously the browser has already written the document. Hardcore JavaScript programmers avoid document.write, but it’s still used in the real world most notably, and infamously, by ads. A feature of Opera’s “Delayed Script Execution” option is that, even though scripts are deferred, document.write still works correctly. Opera remembers the script’s location in the page and inserts the document.write output appropriately.

So, this is why Steve is interested to dive deeper and see if this has the performance benefits that make sense theoretically:

One immediate benefit of this Opera preference is that web developers can see the impact of delay-loading their JavaScript. A practice I’m advocating a lot lately is splitting a large JavaScript payload into two pieces, one of which can be loaded using an asynchronous script loading technique. This is often a complex task as the JavaScript payload grows in size and complexity. With this “Delayed Script Execution” feature in Opera, developers can get an idea of how their page would feel before undertaking the heavy lifting.

I’m even more excited about how this shows us what is possible for the future. To be able to have asynchronous script loading and preserve document.write output is like having your cake and eating it too. It’s difficult for users to find this feature in Opera. And it’s beyond the reach of web developers. But if Opera’s “Delayed Script Execution” behavior was the basis for implementing SCRIPT DEFER in all browsers, it would open the door for significant performance improvements by simply adding six characters (”DEFER ”).

This is most significant for the serving of ads. Often ads are served by including a script that contains document.write to load other resources: images, flash, or even another script. Ads are typically placed high in the page, which means today’s pages suffer from slow loading ads because all their content gets blocked. And really, it’s not the pages that suffer, it’s the users. Our experience suffers. Everyone’s experience suffers. If browsers supported an implementation of SCRIPT DEFER that behaved similar to Opera’s “Delayed Script Execution” feature, we’d all be better off.

Food for thought for Safari, Firefox, and IE.

Posted by Dion Almaer at 7:35 am

3.4 rating from 20 votes


Comments feed TrackBack URI

6 letters…?
That’s 13 letters actually unless you don’t use XHTML but relies on normal HTML…

Comment by ThomasHansen — September 12, 2008

People actually use document.write for scripts? Whatever happened to creating a node/fragment and then appending it?

Comment by TNO — September 12, 2008

“People actually use document.write for scripts?”
Well, a lot of people used to. Some older scripts still in use do. It’s still quite common to use on iframes, though I don’t think that’d suffer from a deferred script issue as the parent document would have already been rendered. At any rate, someone might want to use legacy code rather than rewriting, but may still want to improve performance for end users using some kind of delayed execution, in which case one would want to not break document.write().
Note, I’m not defending all of that. Just saying it’s plausible.

Comment by eyelidlessness — September 12, 2008

The main use of document.write is in ads, where 3rd party content is being stuffed into pages. In this situation it’s not realistic for the ad developer and web site developer to agree on how to integrate their code. To get the ad inserted in the right place they use document.write.

Here’s an example from AOL (not picking on them – notice they use Doubleclick). They include a script –;MN=93227127;u=r572ebd845c53ba7d;wm=o;tac=51095;rm=1;!c=d-jav;sz=300x250;tile=3;dcove=d;ord=292563415? . The script contains document.write('<img src="">'). (I’ve omitted the anchor wrapping the image.)

Improving the way ads are served is one of the top 3 most important performance challenges today (the other 2 are javascript and widgets).

Comment by souders — September 13, 2008

Thanks Steve for alerting us to this hiding feature. but, to your conclusion:
What’s all the excitement?!

Do web developers really need a browser switch to see the impact of delay-loading their JavaScript??
I don’t see what’s complex about asynchronous script loading :
I break my scripts into two sets : those I need on pageload, and the rest. After displaying some welcoming html, a tiny script pulls in the first compacted payload via xmlhttp After this runs all initialisation and re-rendering, just wait a moment before requesting the remaining (second) compacted payload. I have yet to need to trip more specialised scripts, but once the initial libraries are loaded there’s nothing complex about using available frameworks for further asynchronous loading.

and do we want to facilitate the use of document.write in ads?
I have no empathy with those devilopers pulling in ads, but, given they’re out there, I agree the browser feature is a useful one for users.
OK eyelidlessness, your scenario is totally plausible, but why would we care about nurturing bad practice?

so I agree this is a good browser feature, but I’m not concerned with programatically switching it, because we don’t need document.write

Comment by justinnt — September 14, 2008

Leave a comment

You must be logged in to post a comment.