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. 

Tagged with: , , , ,
2 comments on “Content Transformers 2: Dark of the SPDY
  1. Julien says:

    Hum. I am a bit scared by this kind of tactics. Minifying code can also come and bite you seriously. We used Cloudflare to distribute SubToMe and their minification broke the the JS. That’s a problem and not being able to tell for a dev if someone in the middle is “toying” with the data is quite scary.

    I’d much rather see more adoption for stuff like AppCache which do make things much better and will reduce the amount of data transfered from servers to clients.

  2. Andy Davies says:

    I’m not sure whether pagespeed supports cache-control: no-transform or not but that in theory should prevent images from being manipulated.

    On the other hand as opting into the proxy is an end-user choice why should a site owner be able to override that preference perhaps the caching control need a bit more work?

    The good thing about pagespeed is that it’s OSS so we can see how it behaves, indeed this whole pagespeed and spdy as a proxy was prototyped by someone who didn’t even work at Google (Frank Denis) and of course Amazon did something pretty similar with the Kindle fire.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.