Google Chrome pre-rendering distorts advertising stats (ex: OpenX) and causes server logs to record fake visits

December, 8 2011

As announced in another post yesterday, Google Chrome's Pre-rendering feature is causing serious headaches for webmasters. 

The issue

Latest Chrome update (Chrome 13+) includes a pre-rendering technology designed to speed up browser page loading. What it does is preload pages sometimes 5 to 6 times before the visitor even goes there.

The impact

The impact is simple:

  1. it uses real server bandwidth which we are paying for. 
  2. It causes server hits to be recorded as individual visits (each hit session is different - web servers use sessions to identify visits) 
  3. It fails to include information allowing web servers to identify pre-rendering requests from normal web requests
  4. It causes advertising impressions without eyeball impression.
  5. Google is aware and provides Javascript guidelines to deal with the issue - which is useless to 99% of the webmasters.

Google's response? They don't care.

Google maintains its own page where it talks about Chrome Pre-rendering and the issues it raises to all of us in the industry.

To top it off, Google event admits it's not allowing web servers to tell the difference between a normal visit and a pre-rendering visit:

 They "have plans" to improve the feature, but as we all know... this is just a bad feature costing us money.

The irony

The irony is pretty funny.

Google's guidelines ask web developers to reduce the number of requests made to the Google APIs and Google search engines because unecessary requests cost Google bandwidth and resources. 

But Google has no problems allowing its own Chrome web browser to consume up to 5 times the server resources that all other browsers are consuming, which costs all the webservers of the world more bandwidth and resources ...

It would be great if google could apply its own server guidelines to its own web browser.


10/14/2014 06:08 / Travis said:
THIS. This article is spot on. I am furious that I have to try and jump through hoops to 'fix' my code, that was working perfectly, just because Google decided they think they know best.

They could have at least sent a specific HTTP HEADER, so I could check for that. Instead, they want us to resort to a BROWSER SPECIFIC, EXPERIMENTAL Javascript API.

Absolutely crazy.

Post A Comment

We'd love to hear your thougts. All comments are subject to administrator approval before appearing on this website. All comments of spammy nature are automatically rejected.

Email Address: (will not be displayed)

Signup For Newsletter

Email Address: