Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
The Almighty Buck

Why Is Serving Ads So Difficult? 13

Chip asks: "Many moons ago ('85) I started a sports publication and we have been moderately successful. We finally put the entire site on the Web in '95 & have learned a little as we went along. It was much more expensive than we ever imagined & frankly we lost money keeping the site up & maintained every month. One of my subscribers introduced us to banner advertising (Flycast, DC, Burst) about nine months ago and we thought it was a God-send...at first. Now I have people complaining all the time since my site doesn't load as fast, sometimes kicks people off, and so on. I don't know what to do or who to call, every ad agency and ISP we use blames someone else. Can someone refer me to an ad agency (or software that I can use to do it myself) that delivers ads that don't slow my site down or ruin the experience for my readers? I desperately need the revenue generated but can't stand the 24/7 headaches. I know this may seem juvenile to all you "experts" but I have no clue how to fix it and don't want to go back to losing money on my site. Suggestions?"
This discussion has been archived. No new comments can be posted.

Why is Serving Ads So Difficult?

Comments Filter:
  • by ask ( 1258 )
    For serving ads Akamai is not always that great.

    The very short DNS ttl their load distributer uses gives extra DNS lookups / more latency. And it doesn't always do a very good job at finding a close server anyway.

    ValueClick are btw serving banners very fast and very reliable these days. :-) (I work there so I know, but I can't quote any numbers).

    - ask
  • if the ad company should sell text ads they would probably want to serve them (via some javascript / iframe stuff) and then they would slow down the site (slightly).
  • I don't think there is any major ad serving companies that do not allow the client and proxies on the way to cache the actual image. That would be stupid and a needless waste of bandwidth for everyone. :-)

    The redirect (less than 1KB) is never cached though (except on broken clients).

    - ask
  • If you're serving .gif ads, in addition to specifying width and height, you could use basic JavaScript to only load the ad when the rest of the page has been completely loaded.

    Something like this would run on Netscape >= 3 and IE > 3 (approximate, untested code):

    <html>
    ...
    <script>
    function getAd() {
    document.images[0].src = "http//ads.com/some_ad.gif"
    }
    </script>
    <body onLoad="getAd()">
    ...

  • I'm sure others will too.

    Until someone gets a patent through...

  • I'm afraid that you provide very little information that would allow one to solve your problem. Can you provide more details?

    1. What Ad engine are you using?
    2. What exactly is slow? Is it loading the page, loading the ad, determining what ad needs to be loaded?
    Any page that loads ad images from an ad engine will of course be slower than if you are loading the static images from your web site. Think about what is happening (in a simple case):

    1. The page gets loaded
    2. The browser requests an image url from the ad server
    3. The ad server replies with an image url redirect
    4. The browser retrieves the image
    In between, we have dns lookups, possible network congestion, maybe slow responses from whatever ad engine is being used, and who knows what else.

    One of the things that the ad engines are supposed to do is to provide cache busting so that new images (and old, already seen images) are reloaded from the ad server in order to more accurately count the impressions. This is great for the income of the ad agencies, but for people browsing the web site, it means a slower overall performance of the site. Are you just the victim of properly implemented cache busting?

    You are not going to solve this problem by storing the banners on your site, unless you are also doing the determination of what banner to display (which would basically defeat the purpose of using someone else's ad engine). It would also eat up your bandwidth considerably.

    There are ad engines that do work.

    Could you post or email me the address of your site?

  • Only thing I can think of is to only distribute ads by large-scale/well-connected banner companies like doubleclick. The problem is still there, but it's at least a little less noticeable. Or, if yours is a smaller local publication, tell your clients to send you the ad and you'll put it on your own server.
  • > Since the ad people think the weblogs indicate
    > something useful, they'd probably rather shove
    > bamboo under their fingernails than use any
    > sort of caching or asynchronous logging.

    Uhmn too many wrongs on so few lines to just ignore.

    1) Try to do the numbers and you'll find that the ad companies are doing customized and optimized and very much "asynchronous logging". You don't serve many thousand ads per second from one server (so you need to gather the "logs" to a central server for that), and you certainly don't do a diskwrite for each hit (and especially not a syncronous one).

    2) The "weblogs" are very useful. How else would you pay the host sites and charge the advertisers for the traffic? :-)

    3) The initial "hit" will not be cached, no. But the actual banner content (typically the ~10k .gif) will be cached as any other normal static image.

    - ask
  • You didn't provied a link to your site so I can't experience the problems you describe but here is one idea. (I don't mean to insult you if you know this already but you did claim not to be an expert.)

    Most ads are just an image so make sure you specify the image WIDTH="???" and HEIGHT="???" in the IMG tag. It will give the web broser enought extra info to speed the rendering of the page.

    hope this helps.
    Citrix

  • If you have over 250,000 page views per month, check out http://www.affinia.com/ppn/ [affinia.com] . I work for this company, so I am biased towards it (you are warned!).

    This doesn't completely solve the question you asked as we don't do the same thing advertising companies do (we are different enough that you can keep existing advertising revenue streams, such as Flycast/Double Click/Burst -- we are a totally incremental revenue stream).

    We do "product placements" instead of "banner ads". They look and work quite a bit differently, but I think you'll be pleased with them (not to mention that you can keep your existing ads).

    We also have very good performance and reliability (we shouldn't slow your page loads significantly), not to mention our customer support is easy to work with.

    --
    Joel Maslak
    Affinia Engineer
  • This is good advice, but in a sense, the increase in speed is sort of an optical illusion. Obviously when the page has to be resized to accomodate the newly-discovered dimensions of an image, it disrupts any reading the viewer had already started to do and forces him to reorient himself. But the amount of data to be downloaded is still the same. I do recommend that all web authors use width= and height= whenever possible, but depending on the primary cause of the complaints about "slowness" you've been getting, this may or may not help solve your problem.

    I'm also interested to know what the site is; it might be easier to spot problems in the implementation if we could see it in action. Don't be afraid of a little shameless self-promotion now and then. :P

  • by Matts ( 1628 ) on Friday June 09, 2000 @11:30PM (#1012354) Homepage
    Pick an ad server company that uses Akamai to distribute content. Akamai automatically sends content from a server close to the host requesting the ad. I only know about valueclick who do that - but I'm sure others will too.
  • by fishbowl ( 7759 ) on Friday June 09, 2000 @08:36PM (#1012355)
    Well, consider the average ad server is getting
    hit WAY more than your site, and that there is
    the aggregate of the latency between the client and the adserver, plus between the client and your server. If the ad were a static, cached element that came from the same point as your site, it would not be a problem. It's probably not the
    ad itself (what, a 20K jpg or a 80k animated gif?)
    but the latency of the separate request and dns lookup that you forced your client to make for the privilege. Not only that, but the ad is probably
    the FIRST element that the browser must resolve before it can display the rest of your site (the content!) And worse, if it's earlier in a frameset, or even worse, part of a table, then you
    get things like the client not able to display your page at all.

    Since the ad people think the weblogs indicate something useful, they'd probably rather shove bamboo under their fingernails than use any sort of caching or asynchronous logging.

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Working...