Content Transformers 2: Dark of the SPDY
So I read with some interest a tech note from Google on the impeding use of a transforming proxy server for Chrome for IOS & Android. The idea is to speed up the Web on mobile devices where network bandwidth is constrained. If I understand correctly, the proxy will first of all route all http traffic over a single #SPDY connection. It will compress images to WebP on the fly, minify code and move DNS resolution to the proxy. All of this holds the possibility to greatly increase browsing performance – essentially giving you Opera-Mini like performance but with a “full web” experience. I’m excited about that. I’m also glad that they’ve explicitly excluded https traffic from the proxy – although increasingly more and more services are redirecting users to https versions of their pages by default (including, amusingly, the page on developers.google.com that describes the data compression proxy).
I do have a few questions that don’t seem to have been addressed in the brief. First of all, what options do I, as a content developer, have to deactivate the features such as image compression? One example of where I might want to do this is if I am trying to transfer a file (rather than display an image) or I want to make sure that an image is sent at its highest resolution and clarity – for example, if I am trying to enable a doctor to examine an X-Ray image).
A few years ago, the Mobile Web Best Practices working group developed a set of Guidelines for Web Content Transformation – http://www.w3.org/TR/ct-guidelines/ (with some input from Google as well as from other players in the compressing proxy landscape, such as Novarra, which has since been acquired by Nokia and incorporated into their Asha product). This document could best be described as an attempt to re-educate implementers about some of the already existing features of http that they should be using to be more transparent to Web developers when they develop software that gets into the middle of the http transaction, especially when it attempts to meddle with the contents of what is being delivered to the client, or what is being communicated back to the server. Unfortunately, this document never got beyond the Note stage, but I think it’s a none-the-less very instructive.
I wonder if the implementers of this new Google Data Compression Proxy for Chrome on IOS and Android have read it? If not, I suggest that they do. If there is one thing I learned back then, it was to tread lightly when attempting to “optimize” Web content in the network: http://techcrunch.com/2007/09/21/vodafone-in-mobile-web-storm/
Liked this post? Follow this blog to get more.