The important news from this update (for me at least), is a much smarter Omnibox that actually attempts to fetch matches from anywhere in the string of histories (middle of a url or word, etc). It's getting much closer to Firefox's Awesomebar in that regards.
That's definitely something that's kept me from adopting Chrome full time. A lot of people grouse about the AwesomeBar, but the Omnibox has taken a very long time to achieve feature parity, and still isn't there yet. Using the AwesomeBar is my preferred mode of searching through my history for things I half-remember reading, and it usually more convenient than either the Omnibox or Safari's history full text search.
That said, even the dev channel release of Chrome still doesn't get this right. If I want to go to the ESPN NFC East blog (http://espn.go.com/blog/nfceast), I usually type "nfcea" into the AwesomeBar and it pops up as the first result. The Omnibox suggests searching for "nfc east blog" but doesn't show the appropriate URL from my history.
I did a little experimenting on the dev channel. I found that after visiting http://espn.go.com/blog/nfceast once typing nfc would suggest it and this HN post and nfc through nfceast would suggest this HN page.
Doesn't work for me for whatever reason. Oddly, it will show the google search for "nfc east blog" from my history (www.google.com/search?aq=1&oq=nfceast&sourceid=chrome&ie=UTF-8&q=nfc+east+blog), but it won't show the actual blog url. Maddening.
This bothers me actually. When I start to type "facebook", it goes to "about:flags". It should have an additional check if the user doesn't end up picking what was autocompleted for them, then it puts back what the user originally typed. That way this feature can be used without frustrating the user.
True that, Chrome is maturing nicely while performance remains steady. I also noticed that by disabling the prediction service option, search suggestions aren't shown in the address bar anymore. IMO, they don't really belong in the address bar; They belong in the search box on google.com. Disabling them saves me from having to press the down key 3 times, just to select a recent page in history.
The Instant Page feature sounds interesting. Has Google released any findings on bandwidth usage during typical browsing scenarios with this feature? How severe is this going to be for users with restrictive data plans?
I don't see an obvious way to turn this feature off. There is an option to uncheck "Predict network actions to improve page load performance" but this says it is only doing dns lookups and then navigating based on IP address.
I'm also curious how this will affect analytics. As a website owner, I now have to use their PageViews API to accurately track my hits from Google? Can websites opt-out of this service?
The "predict network actions" option you mention is indeed the option to disable prerendering. [0]
If you use a third-party client-side analytics package, they've probably added support for the Page Visibility API [1] already, and you don't need to do anything. Server-side analytics will have problems, both with this and with HTML5 prefetching in recent versions of Firefox. I'd like to see opt-out available through an HTTP header (or even just a header to let the server know the page is being prefetched), but that's not anywhere in the spec right now.
A problem with a header solution would be the user does frequently then see the requested content. Google's pre-fetching only kicks in if it believes you're going to visit, so most of the time it does end up getting shown to the user.
Nope, you're right. It's particularly noticeable if you have something like the 1Password extension installed, whose icon used to perfectly match the shade of the wrench menu. That's no longer the case.
