In my test environment over the last couple of days, I worked towards eliminating page display requirements on adsense javascript calls. I actually did successfully find a way to display my html pages in a single http request, with image loading, css acquisition, and javascript downloads coming afterwards, but the thing that really turned out to be a bugger was adsense.
I did find a solution, although I'm loathe to implement it right now because I'm not entirely happy with the results.
Here's what I found:
- The only way to implement adsense without including the code on each individual page si with an iframe
- You cannot implement the code within an iframe locally via a dynamic ajax routine. It will work in IE, however, firefox will not display ads
- Implementing iframes for adsense dramatically reduces any click-tracking capabilities you have
- Click tracking routines for adsense are not very reliable anyways
For my purposes, the most desirable result is as follows:
- Page Displays completely with original HTML file download
- Adsense injected into the page in a manner that will not affect the load time
You could potentially load adsense in an absolutely positioned element and place that element into your footer, but that is not an option with my current layout templates. This is the one solution that I haven't tried at this point.
I found that injecting javascript code into an element that is not at the bottom of the page will result in that code not being executed in any browser that I tried. I'm not sure why. It is possible if you create a script element using DOM, then append the child to the parent element that you are working with, but doing so would violate Google's TOS, as it would inherently require a change to their code, albeit a minor one.
The only way to make it work is to insert an iframe element into your page. That iframe element needs to reference a source file that includes the adsense code. The problem with this structure is that there are permission structures in place because of various XSS hacks that inhibit inter-frame communication. The inter-frame communication would be necessary if you want to do click tracking at all. I've found that IE seems to be very friendly with click tracking and allowing you to pass events, but in firefox the results are often non-existant and the problem amplifies itself within a nested iframe - which is essentially what you would be doing - Your page, with a document in an iframe, and within that iframe another iframe with the adsense ads. To top it all off, the nested iframe is from a different domain and that incurs another set of permission structure issues.
After doing a lot of experimenting with nested iframe click tracking using my own static html file hosted on a separate domain, I found that IE reports potentially false clicks and can fail to report clicks, although the communication channels are open enough to at least garner some basic statistical information. IE works much better, though, without nested iframes in place. Firefox on the other hand fails to report click information - even with some pretty fancy event passing code in place. All of the experimentation led me to the conclusion that click tracking via event triggers for foreign domain or even subdomain hosted content is at best a guesstimation. (I did learn a good deal about local click tracking that I'll pass on soon).
Freshly lacking faith in click tracking mechanisms, I see some other potential pitfalls with an iframe solution. Google now has an FAQ entry up that says "IFrames can lead to untargetted ads", although on my test pages there were some good ads showing up, who knows if they will hold up on new pages. They used to have a frame variable available when you generated your ad code, but that is no longer there. I didn't delve very deeply, but I did check the document.location property for the nested iframe page and it showed the URL of my ad rotation script and not the document location you would hope for. I suppose it would still be possible to obtain the proper location, but like I said I didn't delve very deeply.
I saw a report of an IE7 default preference that loaded nested iframe links in a new tab, which would be another potential problem as ad clicks opening in a new window are a TOS violation. Unfortunately, I couldn't find anybody doing that to test the theory out, and the date of the report puts it in the beta stage so I don't know if that default setting has changed.
So after all of this work, it seems as if holding off on google response time to get a page view is really the only workable solution. I will play around with iframes again in the near future because the idea of rotating ads while serving static html files is a good one, and I already have the back end code for doing so at a rate of about 751 requests per second on an already over-taxed server - significantly better than any other ad rotation system I've played with and with much more intelligent database connectivity (i.e. no potential for maxing a server out on available sql connections). The code directly translates into my development framework and looks to be easily repeatable, scalable, load balance-able, geographically dispersible and all that other good stuff. In fact, with what I have in place right now, an ad management system will be one of the first applications I develop because the only requirements beyond what I currently have in place are user interface and some data model changes to make it user friendly.
Talk About Ad Rotation with IFrames
