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

Native delta updates

From: Tobie Langel <tobie@fb.com>
Date: Fri, 9 Nov 2012 10:14:56 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
CC: Robert Hundt <robert.hundt@gmail.com>
Message-ID: <F9981AFB970564408FEB7DFCF62D44084369C5F7@SC-MBX01-4.TheFacebook.com>
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

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.



[1]: https://etherpad.mozilla.org/appcache-london
[2]: https://etherpad.mozilla.org/appcache
[3]: http://www.w3.org/community/fixing-appcache/
Received on Friday, 9 November 2012 10:15:18 UTC

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