Friday, September 10, 2010

Advertisers - Why you care about performance (speed)

One thing that has always amazed me while working on web performance is the need to push advertisers to care about the performance (speed) of their ads.  The hard part is that the way things are structured in advertising, the ones paying the money aren't even usually aware that it's something they should care about and it's not something they hold the agencies (that actually create the ads) or the publishers (that serve the ads) accountable for.

At some level, ads are largely accounted for at the impression level.  The publishers track the number of impressions and the advertiser pays based on the number of impressions that were served.  This is a bit simplistic because there are all sorts of variations as well as click or action-based arrangements but fundamentally they are going to be driven by the same pressures.  An interesting fact that isn't thrown around too much is that an impression is counted at the time a decision is made to serve your ad, not when the user actually sees it.

Let's think about that for a minute...What that means is you are paying for every time the ad publishing system starts to serve your ad but there is no guarantee that the ad itself ever made it to the user.  Let's say your agency and publisher ended up creating an ad creative that takes 12 seconds to load it's initial payload (yes, this is a real case and while most aren't this extreme they are usually pretty bad).  That means the user has 12 seconds to interact with the page (and even leave) before the ad you just paid for even shows up.  That is insane!

Faster ads = $$$

Getting the delivery time of the ads (at least the initial payload until something is visible) to be as fast as possible needs to be a requirement in all contracts, otherwise you are just throwing money away.  The publishers don't have any incentive to optimize the delivery since they get paid regardless.  Make sure the performance is also measured based on the users you are targeting the ads to (targeting mobile? try on an actual carrier on an actual mobile device).  Don't accept results from performance tests done from a data center on a high-bandwidth internet connection (or even worse, from someone at their desk) - you need to measure in the real world on real user connections because things can be exponentially slower without you realizing it.


  1. Patrick,

    Great post. I'm one of the inventors of mod_gzip so anything we can do to make the web go faster is a good thing. Wondered if you would be interested in a mobile solution. We've been chatting with Steve Souders who sent us a note about how there's no known solution to accurately measure HTTP traffic performance in a mobile browser. We've solved that problem and have a solution. Would you be interested in something like this?


    Peter Cranstone
    5o9 Inc.

  2. Pat,

    you work at AOL, a large publisher.
    What does AOL do to handle this issue?
    Please share any learnings/tips that other publishers/agencies/advertisers can benefit from, other than "Do thorough real user testing". Txs.

  3. @Aaron

    You may be surprised to learn that even the large publishers (most of them anyway) don't have a lot of direct control over the ad by the time it is delivered and running. That is why I'm encouraging (pleading, begging, whatever it takes) to get performance looked at and cared about upstream when the actual advertiser contracts with an agency to build and run an ad.

    They largely focus on the creative and how engaging it is, etc and everyone just assumes that it is going to perform well.

    From our end it's like pushing on a string. We contact the company that is delivering the slow creatives (or are doing stupid things like not gzipping text or using persistent connections) but they largely don't care since they aren't being paid to care about it.

    Without naming any names, here are some of the things we've seen even within the past month:

    - A rich media creative that took 12 seconds to display anything to the user (some 30+ requests and over 1MB - and none of it video)

    - A publisher whose CDN is configured to not compress content and not use persistent connections (and they deliver > 8 js and css files from the CDN for the ad run we were looking at)

    - A publisher whose images were all sending 100KB of data even though the images themselves were only 2-3KB (busted publishing tool on their side, will get fixed whenever they do their next release)

  4. I would also add that the proliferation of tags and redirects for ad delivery has led to astonishingly slow ad delivery.

    The worst part is that the user, if they have a status bar, sees that the ad is holding up the page.

    This is a precipitating crisis.


All comments are moderated and may take a while to appear.

Note: Only a member of this blog may post a comment.