Cleaning Up Ad Server Scripts
If you work on sites with ads you know that few things can muck up your efforts to improve a site’s performance like an ad server–3rd party ad tags, iFrames, lots of
document.write, and almost all of it out of your control.
In his P3PC series, Steve Souders is currently analyzing the performance of popular 3rd party content, including some ad server implementations. In the same spirit I’ve taken a critical eye to the ad implementation code for 24/7 Real Media’s Open AdStream (OAS) ad server, an ad server I’ve been working with for a few years. It does some things very well but like a lot of ad delivery engines, the code can get a little ugly.
Of the several implementation options that OAS offers, the most sophisticated, the one recommended for Rich Media delivery, and the one we’re going to look at is the “MJX” method.
The nice thing about this method is that all of the ads on the page are retrieved from the server in a single request. Unfortunately, the ads are written to the page with
document.write, which blocks other page components and limits our options for asynchronous loading.
Original Implementation Snippet
Here is the MJX implementation code as specified in the OAS documentation. The majority of the code sets up the call to the ad server; the last two lines are the local calls for the individual ads.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
As you can see there’s a lot of room for improvement here. First let’s take care of the easy stuff.
- It’s no longer 1996, so we can get rid of the HTML comments inside the scripts.
- For the same reason we can also remove the language attributes on the script elements.
Now let’s look at the
Next, the script browser-sniffs for Netscape Navigator 3 and what I think might be IE 4 (!). Just to remind you, these browsers were released in 1996 and 1997, respectively.
The next script block defines the function called in the ad unit calls. If
OAS_version = 11, the ads returned in the aforementioned request are loaded. Otherwise the previously defined
OAS_NORMAL function is called, loading static link-and-image ads.
Somewhat amazingly, the majority of the code is focused on providing compatibility for browsers that have been extinct for a very, very long time. It’s unfortunate, in 2010, to see code like this in official documentation for a major ad server. The good news: unless you have a lot of users accessing your site via a time machine, this is all code that can safely be removed.
Revised Snippet (In which we reduce 35 lines of code to 7)
OAS_targetapplied only to the fallback simplified implementation, that was removed.
- Line 10 provides a fallback for browsers that don’t support the
randommethod, so that was removed.
- Lastly, the function name for the ad calls was changed from OAS_AD to OAS_RICH since we no longer need to support an alternative to the OAS_RICH function (defined in the script returned by the main call to the ad server).
- Update: In the comments, kangax pointed out that the line producing the random number could be further improved by simply type converting the number instead of creating a String object. He also mentioned that we can remove the split of the opening script tag.
The set-up code can be reduced even further if you’re not using query strings to pass keyword data to your campaigns.
My tests revealed no problems with the revised version but I strongly recommend conducting your own thorough tests before making major changes to your ad code.
While these changes do not address the main performance problems of the ads—namely,
document.write— they do clean things up significantly. And I think that’s always a good start.