April 26, 2015

Stats for Chrome's Compression Proxy

A few Google engineers wrote an interesting paper (PDF) about Flywheel, Google Chrome's data compression proxy. The paper only talks about the data compression feature from Chrome for Android and iOS and offers a lot of stats.


Flywheel focuses on the mobile web because mobile devices "are fast becoming the dominant mode of Internet access", while "web content is still predominantly designed for desktop browsers" and mobile data is expensive. Google's proxy compresses web content by 58% on average and relies on the SPDY protocol and the WebP image compression formats, which are used by a small percentage of the sites (0.8% of the images use WebP and 0.9% of the sites use SPDY). The most significant data reduction comes from image transcoding, which decreases the sizes of the images by 66.4%, on average.


Data compression is disabled by default and only 9% of the mobile Chrome users enabled it. "Segmented by access network, 78% of page loads are transferred via WiFi, 11% via 3G, 9% via 4G/LTE, and 1% via 2G." Flywheel is not enabled for HTTPS pages and for incognito tabs and it's interesting to notice that only 37% of the bytes downloaded by Chrome users who enabled the proxy are received from Flywheel, while 50% of the total received bytes are from HTTPS and 13% of the bytes are from incognito mode, bypassed URLs and protocols other than HTTP/HTTPS. For example, the proxy bypasses audio/video files and large file downloads.

"For most users and most page loads, Flywheel increases page load time. For the majority of page loads, the increase is modest: the median value increases by 6%. Flywheel improves page load time only when pages are large and users are close to a Google data center."

The paper mentions that the Opera Turbo feature provides comparable data reduction, while the old Opera Mini proxy uses more aggressive optimizations, but breaks pages that rely on JavaScript or modern web platform features. "Maintaining an alternative execution environment to support whole-page transcoding is not feasible for Flywheel given our design goal of remaining fully compatible with the modern mobile web."

{ via Hacker News }

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.