Anatomy of ads · 2007-01-25 17:57 by Wladimir Palant
I would like to take a look at the different costs connected to ads. Most of the time, the only cost people consider is our attention — ads are designed to be distractive, they don’t let us concentrate on what we are doing. Jeff Atwood analyzed the space occupied by ads in comparison to content on a particular page and came to alarming results. I want to pick another page to look at the other aspects. Dilbert.com has been mentioned quite a few times as an example of an ad-laden site, the server response time is quite stable (good for reproducible results) and it features a large variety of different ads. If you look at the space distribution on the main page, ads occupy roughly 32% of the space while the content area is quite small with 22%. Most of the remaining space is navigation.
That’s the visual appearance. But let’s look at the networking side. How much do the ads cost in download size? How much do they increase page loading times? I measured these parameters for a full reload of the main page both with and without ads (each experiment was repeated 10 times to get a reasonably reliable average). However, when you browse a site, you usually make use of your browser’s cache — so I also did measurements for the case that you come back to the main page by clicking a link. Here is an overview of the results, all numbers are given in the “from – to (average)” form:
| with caching, with ads | with caching, without ads | without caching, with ads | without caching, without ads | |
|---|---|---|---|---|
| amount of data transfered, kB | 22 – 60 (40) | 0 – 36 (11) | 675 – 707 (680) | 204 – 205 (205) |
| time required, seconds | 2.6 – 5.4 (3.5) | 0.0 – 1.2 (0.3) | 6.2 – 8.4 (7.1) | 6.0 – 8.1 (6.7) |
| number of servers contacted | 6 – 8 (6.7) | 0 – 1 (0.5) | 8 – 9 (8.9) | 1 |
| number of URLs requested | 12 – 13 (12.5) | 0 – 1 (0.5) | 72 – 77 (73.2) | 55 |
Summary of the highlights:
- Ads triple the amount of data one has to download (over 450 kB increase).
- When downloading the page the first time (without caching) the delay due to ads is not notable. However, these measurements have been made with a very good internet connection, modem users will see something very different. Also, it doesn’t consider the time for server name resolution (all names were already cached) — resolving nine server names instead of just one usually makes a huge difference.
- Dilbert.com is really good at caching, often you can go back to the main page without contacting any server at all. Unfortunately, ads pretty much destroy this advantage by requiring almost every ad server to be contacted. This means that instead of showing up almost immediately the pages take more than 3 seconds to load.
Now lets have a look at memory use. Restart Firefox, look at memory use, go to dilbert.com, check memory use increase. Comes out that this page needs less than 2 MB of memory without ads and around 9 MB with ads. Yes, we have quite an increase here.
Altogether dilbert.com includes 8 remote JavaScript files. They are allowed to execute on the page and access the same information that the page itself receives. What do they do, should you be concerned? Let’s look at those scripts in detail.
adsremote.scripps.com
Five of the eight JavaScript files included in the page are loaded from this domain. Three of them (ad types EXIT_POP and SUPERSTITIAL according to their addresses) do something weird: they insert an image wrapped within a regular ad link, but the image is a 1×1 transparent GIF. Who is supposed to click on that? I have no idea.
The other two (ad types UNSIZED_AD and LEADERBOARD) are more creative — they load other scripts, this time from a.tribalfusion.com. What do these scripts do? You probably guessed it already — they load more scripts, this time from media.fastclick.net. And one of those finally inserts an image ad, while the other inserts yet another script (cdn.fastclick.net) that finally checks whether you have Flash installed and inserts a Flash ad if you do. The image ad (animated GIF, 331 kB) is mostly responsible for the increase in download size.
All this craziness involving 10 scripts (have you been counting?) amounts to 31 document.write calls. Just to keep your browser busy. And of course each single script sets a cookie (altogether five cookies on three domains) so it can recognize you when you stumble upon another of their ads.
js.adsonar.com
This script defines a bunch of functions including its own error handler. Never noticed JavaScript errors on dilbert.com? That’s because the helpful ad script catches them all. The webmasters might not be very grateful once this masks a real problem but who cares…
It will add an unused hidden form to the page (memory is cheap, you know?) and then create the ad. The script lets the webmaster choose whether he wants a regular pop-up, a pop-under or an iframe. Dilbert.com chooses an iframe. In addition to the regular information about the account that should receive the payment it also transmits the full URL you have been viewing — just in case your firewall blocks the Referer header to protect your privacy.
The iframe actually contains an unobtrusive text ad, that’s the one you see above the text “Dilbert.com Marketplace”. It manipulates your status bar to make it appear that you will be sent directly to the advertised site. In reality it sends you there through redir.adsonar.com – each click is counted.
st.sageanalyst.net
That’s a tracker. It tries to get as much information about you as possible — whether you have cookies enabled, the address of the page you are viewing, the address of the page you came from, your screen resolution, JavaScript version supported by your browser. Then it creates an image that will transmit this data back to st.sageanalyst.net. And it sets a cookie to track you.
ssl.google-analytics.com
I probably don’t need to introduce this one. That’s Google’s visitor statistics service for webmasters who for some reason cannot afford proper log analysis. In terms of privacy there is only one difference to sageanalyst.net: instead of settings a cookie on their own server, Google sets the cookie on dilbert.com. I guess this has the advantage that one cannot easily block Google’s cookies without locking himself out of any cookie-dependent services on the domain (forums above all). On the other hand, this cookie is only useful for tracking the user within one site, on another site with Google Analytics you will receive a different cookie.
Alec · 2007-01-25 23:36 · #
Thanks
That was quite interesting!
Matt Nordhoff (Peng) · 2007-01-26 00:05 · #
I have a slow ADSL connection (but it’s still ten times faster than dial-up), and the main issue for me with ads is that DNS lookups will sometimes take 6-8 seconds, so page loads might get stuck for 10 seconds while some worthless ad script downloads.
7 MB larger memory increase, huh? That makes me want to Adblock the heck out of those advertising sites or get NoScript. I already block cookies from all domains except those that really need them (and my cookies.txt is now around 15-19 KiB, rather than 80 KiB), so I could do the same with scripts.
alta88 · 2007-01-26 16:10 · #
very interesting analysis. noscript is your friend here, until content is so mixed with ads/scripting that it will be impossible to separate the two.
but – why not get dilbert via rss ;)
Reply from Wladimir Palant:
I am too lazy to run NoScript, I prefer the comfortable browsing. And Adblock already takes care of all the annoyances.
Fox · 2007-01-29 13:07 · #
I did try NoScript 2 times last year, and i think it’s not user friendly extension.
Sometimes i was not sure what i need to allow.
And also it did made me little paranoid too.
I use Adblock Plus to block all those annoying scripts and ads, and it works very well.
I like to use those options:
http://adblockplus.org/en/filters#options
Thank you.
My parents also enjoy annoying script and ad -free surfing, but i think they don’t know that Adblock Plus and my subscription does it.
I just make sure that that subscription works.