Every time a service like this appears (along with Fiber, Google DNS, Ajax Libs, Google Analytics, ..) I'm left feeling that traffic data produced as a side product is somehow being reused internally. My wild (and least paranoid) guess is search quality: measuring site popularity using bandwidth as a proxy would be incredibly difficult for spammers to fake on a large scale, and when capturing logs for what increasingly appears to be the comprehensive majority of Internet traffic, we're talking really large scale.
Given user reports and experiences of Google DNS, it seems at least its stated aim is barely satisfied in the general case: it is often slower than local ISP servers. Similarly, sticking a proxy between a user and their destination may add more latency than it could ever save, leading me to somewhat doubt the public reason these services exist.
> I'm left feeling that traffic data produced as a side product is somehow being reused internally
Of course. One has to be very naive to believe data traveling to their servers is being immediately discarded.
This reminds me of a story I saw once by Onavo, a mobile app which reduces data usage by acting as a middleman and compressing the data before it reaches the phone. The story however talked about which apps made the most revenue; and guess how they knew: http://techcrunch.com/2013/01/08/onavo-mobile-games-grossing...
The company looked at game usage among their U.S. iPhone users in November. Then they looked at the market share, or the percentage of their U.S.-based iPhone owners that use these games on a monthly basis.
> Given user reports and experiences of Google DNS, it seems at least its stated aim is barely satisfied in the general case: it is often slower than local ISP servers.
I don't think the claim is being made that it's better in all cases. As I understand it, Google DNS is (positioned as) a secure, ad-free resolver, and tries to be as fast as possible. In practice if there is a better resolver - say, run by your ISP - for you to use, you should use that. But often ISP resolvers fail in one dimension or another, in which case Google DNS is available as a viable alternative.
> Similarly, sticking a proxy between a user and their destination may add more latency than it could ever save, leading me to somewhat doubt the public reason these services exist.
Again, in the general case that might be true. I wouldn't want to use a SPDY proxy on my desktop at home, for example, as it wouldn't be able to offer me any speedup. But it's already known that similar services can provide significant benefits on mobile - look at Opera Mini. Useful feature != beneficial for everyone.
The title is somewhat misleading - this change is using Google servers to proxy SPDY traffic to/from a client browser for speed. It's not using the proxy for "rendering" of actual pages, or parts thereof.
Yet another great post from François Beaufort introducing an upcoming feature being developed in Chromium. I wonder - does François work for Google, or is he just a watcher on the repositories?
Learn from the best - again, a leading browser vendor is adopting a feature pioneered by opera. I wonder whether there is any correlation with the demo of a new opera mobile version last week that is essentially chrome with turbo.
Not exactly true (unless you have some inside information). Opera announced they are replacing their rendering engine with WebKit. There's been no announcement that they are dumping the entire browser (which is a lot more than just the rendering engine) to release a custom Chromium build.
On android we switched to a thing called impl side painting which helps hugely with scrolling performance and other graphics. It could be that, file a bug on crbug.com/new with your system details and pages where it happens.
Besides possible interpretation issues (with the text of TFA), what is so great about something like that? The whole idea of the web is: the client decides how it renders the data. If we targeted a remote hosted bit mapped graphics terminal with a VNC like sharing protocol then the web would have never taken off. But of course, the last line of defense in undoing the web is to host VMs running your application and just sending over the bitmaps.
In the end this may be inevitable but I'll stick to HTTP as long as it is feasible. These 'improvements' are a step back. More bandwidth to mobile would be an improvement, as would be a mobile infrastructure without silly caps (you know, like we had 5 years ago).
The major benefits would come from mitigating the (generally) higher latencies and lower bandwidth of mobile. What gains you'd get on desktop would be countered by the extra hop traffic would require. Overall I doubt desktop users would get much benefit from this feature.
Given user reports and experiences of Google DNS, it seems at least its stated aim is barely satisfied in the general case: it is often slower than local ISP servers. Similarly, sticking a proxy between a user and their destination may add more latency than it could ever save, leading me to somewhat doubt the public reason these services exist.