Can’t we all just 302? Report on redirect timings
September 16th, 2008
In this blog post I examine the time difference between three different methods of “redirecting” users from one adserver to another. I find that there is a significant difference in latency between 302, IFRAMEs and JavaScript redirects. Specifically — JavaScript redirects are 70% more likely to last longer than a second than 302 redirects. Read on for the details!
Introduction
In the advertising world today there are three primary methods of “redirecting” a user from adserver to another: “302″ redirects (aka URL creatives), IFRAME tags and JavaScript.
302 Redirects: The HTTP 302 status code means that the site being accessed is called “Moved Temporarily”. This is the simplest and easiest way to redirect a user from one adserver to another. When the user’s browser loads the first ad-tag the server responds that the service the user is trying to request (the ad) has “moved temporarily” and passes a URL where the proper content can be grabbed.
IFRAME Tags: In this scenario the adservers responds with a simple HTML page that contains an IFRAME HTML tag with a src URL pointing to the next adserver from which to load content. An IFRAME tag can be most simply described as a page within a web-page. The browser generates a mini web page within the parent page and loads content from the specified source URL.
JavaScript: In this scenario the first adserver responds with javascript code which subsequently called the function “document.write” to inform the browser where to load subsequent content.
So if all we’re trying to do is accept an ad-call and determine which party it is best to redirect to, what’s the difference between the three? Using JavaScript has a minor advantage that it enables the first adserver to execute some logic before redirecting off to the next partner. For example, if the browser language is set to english and timezone is EST then redirect to advertiser A, otherwise redirect to advertiser B. Other than that there are minor technicalities that can be discussed but really — each method accomplishes the same thing.
The Experiment
I’ve always been curious about the performance difference between the three different redirect types and a recent surge in traffic was the perfect opportunity to test this out! So since August 1st I’ve been running a little experiment on the visitors of this blog.
On each page load I make the browser run through a simulation where a fake publisher adserver redirects off to a fake advertiser adserver. Each time this happens I time how long it takes for the browser to load the advertiser adserver after loading the initial publisher ad tag. How it works is simple.
On the top of every page there is an IFRAME that points to “/redirect_testing.php”. This page randomly decides either to do a simple 302 redirect, write out an IFRAME or return JavaScript — each method redirects to the same page and the results are shocking.
First off, out of a total of 476,635 samples there was a nice even distribution between the three — 159,897 redirects, 158,193 iframes, and 158,545 javascript redirects — almost exactly a third each. I split the result data into four different ‘speed categories’.
Fast Requests: These are requests in which the advertiser adserver content was loaded in under a second.
Medium Requests: In these it took greater than one second but less than two seconds to hit the advertiser adserver.
Slow Requests: If it took longer than 2 seconds to load the adv-server they are certainly slow requests!
Timeouts: The second request never happened! Uhoh.
The Results
speed | type | count(*) | avg_time |
---|---|---|---|
fast | redirect | 133008 | 0.365 |
fast | iframe | 120544 | 0.395 |
fast | script | 113264 | 0.445 |
medium | redirect | 10937 | 1.384 |
medium | iframe | 14307 | 1.408 |
medium | script | 17626 | 1.389 |
slow | redirect | 14255 | 6.519 |
slow | iframe | 20720 | 5.889 |
slow | script | 22035 | 5.877 |
timeout | redirect | 1697 | null |
timeout | iframe | 2622 | null |
timeout | script | 5620 | null |
The first thing that popped out at me when I looked at the above table is that redirects appear to be 80ms faster than javascript on “fast” requests. On medium requests redirects continue to be the fastest although only marginally more than javascript. The anomaly appears in the “slow” category, although at this point we’re looking at a very low percentage of requests.
The second thing that popped out at me was that redirects and iframes seems to be significantly more likely to be “fast” requests than javascript. Digging further:
Redirect | IFRAMEs | Javascript | |
---|---|---|---|
Fast (< 1s) | 83% | 76% | 71% |
Medium(>1s, < 2s) | 7% | 9% | 11% |
Slow (> 2s) | 9% | 13% | 14% |
Timeout (> 30s) | 1% | 2% | 4% |
Wow. 17% of “redirects” were slower than one second versus 29% for Javascript. Putting that in other words –> Javascript redirects are 70% more likely to take longer than a second than simple 302 redirects.. The second surprising bit is that IFRAMES aren’t that much better with 24% of requests taking longer than a second.
Why should you care? Well, latency matters. And not only from a “keep your users happy” perspective. Every additional 100ms of latency increases the likelihood that your user moves to another page, stop loading the page .. or in other words -> every 100ms of latency added is another subset of your users that are lost.
So how are you redirecting over to your advertisers? Can we all please just 302?
Related Posts:
- How to get informative feedback on ads from your users
- Redirects and Integration, Part II: Hacking Around the Browser
- Insight into a domainer
- Myspace to Acquire Photobucket
- Industry starved for data?