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?"
Re:Akamai (Score:1)
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.
- ask
Re:Text ads (Score:1)
Re:So, what is your problem really? (Score:1)
The redirect (less than 1KB) is never cached though (except on broken clients).
- ask
maybe use JavaScript to avoid slowdown? (Score:1)
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()">
...
Re:Akamai (Score:1)
Until someone gets a patent through...
So, what is your problem really? (Score:1)
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?
yeah, what he said (Score:1)
Re:ad servers (Score:2)
> 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
- ask
Are you using WIDTH= and HEIGHT= (Score:2)
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
Affinia (Score:2)
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
Re:Are you using WIDTH= and HEIGHT= (Score:2)
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
Akamai (Score:3)
ad servers (Score:3)
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.