W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2012

Re: Native delta updates

From: Robert Hundt <robert.hundt@gmail.com>
Date: Mon, 12 Nov 2012 11:31:57 -0800
Message-ID: <CAOWjH=CTrMqyqcKpdcP+q5MdOdzvQCL90SYzA-im6Q+Sy4kk0A@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
Thanks, Tobie,

Needless to say, we (Gmail/Apps/others at Google) are really interested in
this and welcome any help and participation.

The slides are here:


On Fri, Nov 9, 2012 at 2:14 AM, Tobie Langel <tobie@fb.com> wrote:

> Hi all,
> I saw Robert's slides on delta updates and read the workshop's minutes.
> I would like to add a couple of points as native delta updates are, with
> AppCache, one of the keys to allow building rich client-side apps on the
> mobile Web platform.
> A typical rich client-side application is easily composed of hundreds of
> different JS files nowadays. In order to fight latency issues, developers
> (rightfully) concatenate all of their JS files together to transport them
> to the client. Admittedly, with SPDY/HTTP2 this might no longer be
> necessary, but that still needs to be proven.
> While concatenating JS files is a net gain in terms of latency, it also
> implies that a single line change in a single JavaScript file causes a
> complete cache bust. This issues is orthogonal to whether or not AppCache
> is being used. With continuous deployment techniques increasingly getting
> traction (e.g. Twitter and Facebook push daily to their mobile website),
> this implies daily cache-busts, which artificially inflates bandwidth
> usage and increases load times.
> There are various techniques to fight this. Among the mobile web apps we
> surveyed[1][2] as part of our fixing-appache effort[3], pretty much all of
> them stored their JS in localStorage and did some form of delta updates on
> it (whether it was true diffs or per module updates). But there are
> performance associated costs with this (getting stuff from localStorage is
> not free[4]), security concerns[5] and a large engineering overhead which
> is paid for every app that wants to implement this. While WebCrypto APIs
> help mitigate the security threat, they still imply an overhead to the
> developer who needs to be aware of the threat and defend against it
> accordingly.
> For these reason, diff updates should be transparent to client code and
> probably belong at the http level. Some vendors have already expressed
> interest in this. It would be fantastic to see it through. Suggestions as
> to what the best platform for moving this forwards, and what stakeholders
> besides vendors should be sitting at the table are more than welcome.
> Best,
> --tobie
> ---
> [1]: https://etherpad.mozilla.org/appcache-london
> [2]: https://etherpad.mozilla.org/appcache
> [3]: http://www.w3.org/community/fixing-appcache/
> [4]:
> http://www.nczonline.net/blog/2012/04/25/the-performance-of-localstorage-re
> visited/
> [5]:
> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Aug/0057.
> html

Robert Hundt
Received on Tuesday, 13 November 2012 14:32:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:33 UTC