Today’s Chrome Beta for Android update brings your saved passwords and autofill entries from your desktop to your phone and tablet. This release also introduces an experimental data compression feature that will yield substantial bandwidth savings. This feature is powered by a connection to a SPDY proxy running on Google’s servers, paired with content optimization performed by our open-source PageSpeed libraries, specifically tuned for Chrome Beta on Android.

By using SPDY, the proxy is able to multiplex multiple request and response streams in parallel over a single TCP connection to your phone or tablet. When this new feature is enabled (enable the “Experimental Data Compression Proxy” under chrome://flags) the browser-to-proxy connection is over SSL, for a more secure browsing experience. In addition, only HTTP traffic is routed through and optimized by the proxy, so secure (HTTPS) requests will bypass the proxy and continue to connect directly to the destination. Furthermore, DNS lookups are performed by the proxy, instead of on the mobile device. Turning on this experimental feature also enables Safe Browsing.

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

For a deeper dive into the technical details, check out our whitepaper in Chrome for Android’s developer documentation. The latest version of Chrome Beta for Android is available on Google Play (use the link, you won't find it in search)! We look forward to your early feedback.

Posted by Matt Welsh, Software Engineer & Mobile Web Performance Gearhead

Update April 10, 2013: To enable this experimental data compression feature, go to “Bandwidth Management” in Settings and enable “Reduce Data Usage.” From the most recent Chrome Beta for Android release onwards, no need to look under chrome://flags.

Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed SSL False Start, a client-side only change to reduce one round-trip from the SSL handshake.

We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%¹. That is a big number. And reducing the cost of a SSL handshake is critical as more and more content providers move to SSL.

Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.

To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.

To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.

All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.

---

¹Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.

Posted by Mike Belshe, Software Engineer