- 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>
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
Received on Friday, 9 November 2012 10:15:18 UTC