Speeding page load with dynamic JavaScript

I’m delighted that ITWriting.com is sufficiently popular to sustain some advertising. I’m not pleased though with the impact on performance. The problem is that ads such as those from Google Adsense or Blogads are delivered by remote scripts. It usually looks something like this in the HTML:

<script type="text/javascript"
  src="http://some/remote/script.js">
</script>

When the browser encounters this script, it stops and waits until the script returns. This means that your site’s performance depends on the performance of the site serving the script. At times I’ve noticed significant slowdown – though to be fair, Google is normally faster than most others in my experience.

So how can this be fixed? I’ve spent some time on the problem, but with limited success. Ideally I’d like an Ajax-y solution where the ads flow in after the rest of the page had loaded and rendered, because the content is more important than the ads. The first step though is to place the scripts at the end of the page, so that the rest of the content is downloaded first. However, the ads have to appear towards the top of the page, otherwise the advertisers will not be happy. I tried inserting the script dynamically like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var theScript = document.createElement("script");
theScript.type="text/javascript";
theScript.src = "http://some/remote/script.js"; 
addiv.appendChild(theScript);

While this works after a fashion, it does not do the job. The problem is that the script typically calls document.write. If you are lucky, the ad will appear at the bottom of the page. If you are unlucky, the ad will replace the entire page.

What I needed to do is to capture the output sent to document.write and then insert the HTML dynamically. It turns out that JavaScript makes this easy. We can simply override document.write with our own function. Like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var adHtml = ”;
var oldWrite = document.write;
document.write = function(str)
{
    adHtml += str;
}
<script type="text/javascript"
  src="http://some/remote/script.js">
</script>
document.write = oldWrite;
addiv.innerHTML = adHtml;

This is brilliant, and in fact works perfectly for some of my ad scripts. Unfortunately it does not work for the slowest performer. The problem is that I have no control over the content of the remote script. In the non-working case, the remote script does not return HTML. It returns another script, which references another remote script. Now I have to figure out how to handle all the possible cases where scripts return scripts, which might or might not call document.write.

I’d be interested if anyone has a generic solution. There is a library here that looks like it might be helpful.

Another reflection is that it is in the interests both of advertisers and publishers to have scripts that execute fast and/or behave in a predictable manner that is friendly towards deferred loading techniques. It is no use writing convoluted code to deal with a particular script, when it might change at any time and break the site.

5 thoughts on “Speeding page load with dynamic JavaScript”

  1. Pretty clever, Tim. This is beyond my level of JS expertise to try but could you load the ads in a hidden IFRAME and set a javascript event to copy its contents over to your ad div after it’s done loading & rendering?

  2. Full disclosure, I am the author, but document-right attempts to provide complete pre-load emulation for document.write.

    Because of this, it makes late-loading all the scripts on a page really simple. No need to write additional code or track down dependencies: Just change the type and src attributes of your script elements and add two new scripts at the bottom.

  3. Joel P — The problem I’ve always seen with moving elements like ads is that FireFox seems to reload iframe elements when you do this. This can be problematic when an ad, loaded in your iframe, also writes out an iframe element of its own. Then when your page’s code moves that iframe into the real document, it gets reloaded potentially double-counting impressions. FF iframe support continues to evolve so this might be moot

Comments are closed.