I always felt like one of the big downers to web browsing on mobile was typing in passwords. Of course, the built-in password management for Chrome (and other mobile browsers) can sometimes take care of things for you. But I'm sure if you do a lot of signing in, you know there are some sites whose login system just doesn't work with the browser's password manager. With Chrome v51, now in beta, Google is taking some steps to help smooth things out.

W3C, the web standards group, has created an API to help homogenize the relevant aspects of signing into websites. This isn't about the actual authentication part, but giving websites a standard way to tell the browser where the username and passwords go. That is, after all, where the breakdown in communication is happening. Chrome would fill in your info if it just knew where to put it. The API also uses this information to help the browser know when to ask if you would like to have it remember your login info.

Chrome v51 represents Google holding up its end of the deal in implementing the API. For any site that supports it—and W3C emphasizes that it is trivial to do so—Chrome will bring up a prompt asking if you'd like to sign in with the credentials it has saved for the site, much like when you use Smart Lock to sign into apps.

As you can see in the video above, this API solves another problem besides login flows that confuse the browser. The built-in password managers aren't well-suited to federated sign-ins, when you use your Google or Facebook or some other site's account as a way to log in. The API gives an interface between the site and the browser to make that work.

While this all sounds great, it will only work as well as the sites that implement the API in their end. With that said, it shouldn't take much effort for web developers to make the necessary changes.

There are some more goodies in the v51 release, of course. One that Google seems especially pleased with has to do with efficiency. Lots of websites include videos, widgets, and such that can really bog things down. What can be really irksome is when the page elements that are drawing the power and using the bandwidth aren't even on the part of the page you are looking at.

To address this, Chrome v51 won't render any third-party animations if they aren't visible on the screen. What difference can that make, you ask? Well, below are the results of their internal tests on several real sites plus some demo sites they loaded with ads and such. The red bars represent the fix put into v51:

png;base645071c2e0dedced56

Yep, they even tested us out. The average power reduction was 37%. The only site that actually increased in power consumption was Forbes, which is one of the most miserable places to browse on the web from a design standpoint.

Beyond that, there are many smaller, more technical changes that you can read about at the Chromium Blog. Other things of note about the v51 release, covered previously, include the elimination of merged tabs and a material bookmarks widget.