Google recently unveiled their next batch of new services, including a technique called pre-rendering. The idea being that when a Chrome user runs a websearch on Google, the first few links will be automatically loaded in the background for instant display should the user choose to view it.

For those operating websites, this has a number of huge disadvantages. Firstly, those who monitor how many times their pages have been viewed (“hits”) are going to find their statistics are heavily skewed. A basic hit counter will not know the difference between an actual page-view and a pre-rendered page.

This could, of course, be very misleading when trying to identify which pages on your site regularly attract visitors.

Unfortunately, the issues don't stop there. Because your page will be downloaded by the browser, regardless of whether the user actually views it, pre-rendered pages will use your bandwidth in the same way that ordinary visitors do. If you regularly appear towards the top of Google's search results and don't have an unlimited bandwidth allowance for your site, this could become very costly.

So why have Google made this choice?

They've done some research and found that the average page loading time is 5 seconds. This, apparently is too long and so with pre-rendering they aim to make page loads appear instant to the user.

Adjusting your site to report correct hitcounts

Google want people to use the (still in draft) PageView API to identify when a page is actually being viewed by the user. This API uses a small amount of Javascript to identify the current state of the window that the page has been loaded in, making it possible to identify when a page has been pre-rendered (and therefore not adding to the hit count).

Unfortunately, for many this is not a suitable solution. Unless your site's hit counter uses Javascript it may be difficult to integrate the Pageview API, and it doesn't approach the issue of your bandwidth being wasted by un-necessary pre-renders.

There's also some concern amongst the developer community that Google seems to be trying to force developers to rely on client-side scripting to complete a very simple task (recording hits).

Previous Similar Attempts

It's not actually the first time a company has tried something similar, albeit for different reasons. In 2008 the Anti-Virus company AVG integrated a product called LinkScanner into their antivirus suite. It worked by loading each link in the background (much like Google's pre-rendering) to detect so called 'drive-by' downloads (used by malware authors). The product received a horrifically bad reception due to the fact it was artificially increasing hit counts and wasting bandwidth.

A ZDNet poll found that 77% percent of the 1000 people surveyed now considered AVG to be 'badware' as a result of the change. Many web developers took steps to actively block linkscanner from accessing their sites, and within a month the company was forced to pull a turnaround.

AVG's LinkScanner stopped pre-scanning all links on a page, and instead scanned the page when (and only when) the user actually clicked on a link.

The 'damage' caused by LinkScanner was widely reported, with one Australian site receiving an average of 12 'hits' per second from LinkScanner. The bandwidth unnecessarily wasted by this ill advised move will have counted against each sites monthly bandwidth quotas.

But it's good for users, isn't it?

Google claims that pre-rendering will improve user's experience of the Internet, because they won't have to wait quite so long for a page to load.

Unfortunately, this statement ignores a number of known issues with the technique, all of which put users at risk in one way or another;

Bandwidth usage – It's not just website operators who may see their bandwidth usage rise, when Chrome pre-renders a page it needs to download it in the same manner as if the user was directly viewing it. Over time, this could take quite a toll, especially in the UK where Internet Service Providers still impose stricts bandwidth caps.

Risk of Malware – Google have stated that the technique poses “no additional risk” to users because each page will be checked against Google's blacklist of malicious sites before it is pre-rendered. To take this at face value is to remain ignorant of the one major failing of a blacklist – it's impossible to have a 100% comprehensive blacklist!

There was some speculation as to whether or not active content (i.e. Javascript etc) would execute when a page is pre-rendered, but as the Page Visibility API is being recommended it suggests that it probably will.

Illegal Content – This was also a wide concern when AVG released LinkScanner. The pre-rendering software lacks a human insight into what a certain link may lead to. If you were to (for example) enter a term into Google that returned links to a Child Pornography site, there's a good chance that Chrome may pre-render that page. To anyone viewing your Internet access logs, it looks like you loaded that page, which depending on the content could lead to a few legal worries.

Will it happen?

The feature is already available in the Chrome browser, but this does not necessarily mean it won't be withdrawn in an update: AVG were forced to change their software as a result of user dissatisfaction, but this doesn't necessarily mean that Google will. Google are orders of magnitude larger than AVG and tend to focus on their core business as much as possible;

There's been speculation that by forcing sites to use the Page Visibility API (and so forcing other browsers to adopt the specification) it would become possible to detect whether a user is actively viewing a page (as opposed to it just being open in a window). Imagine if an advertiser could tell when someone is actively viewing a page containing their advert!

Google's primary business is the selling of adverts, so it's quite possible that there's an ulterior motive in play. If that's the case, it seems highly unlikely that Google will back down.

What can we do?

Whether or not businesses make changes to their site needs to be an individual decision, although it seems unlikely that Google will change their plans, spending money on a developer to implement the PageView API could prove to be a mistake if pre-rendering is scrapped.

Over time, developers may find that there is a way to identify pre-rendering without relying on the PageView API. If this is the case, it may be possible to configure your website not to server pre-rendering requests.

For the time being, the best move may be to wait and see whether the community can force a change or find a workaround. One things for sure: with rising uptake of Chrome browser, we can all expect our bandwidth bills and hit counts to rise a little in the short term and possibly in the long term as well.

Be aware that if the technique is implemented by other web browsers, it may not just be Google searches that trigger the pre-render.