Some thoughts about our and probably other people struggle with performance in general. There are 2 major performance problems hitting us all the time:
- Startup time
- Runtime performance
There is a good article about how the guys at gmail reduced their startup time in an HTML5 environment like the iphone. They summarize the startup latency is the sum of these three:
- Network time to fetch the application (JavaScript + HTML)
- JavaScript parse time
- Code execution time to fetch the data and render the home page of your application
What the gmail guys are suggesting to do is to split everything up into small modules that can be loaded lazily. That makes a lot of sense. Now they figured, that at least on the iphone, javascript parsing (2) is what takes the biggest amount of time. So they suggest to load the code in a script tag but then interpret it later (using eval)
...
<script id="lazy">
// Make sure you strip out (or replace) comment blocks in your JavaScript first.
/*
JavaScript of lazy module
*/
</script>
<script>
function lazyLoad() {
var lazyElement = document.getElementById('lazy');
var lazyElementBody = lazyElement.innerHTML;
var jsCode = stripOutCommentBlock(lazyElementBody);
eval(jsCode);
}
</script>
<div onclick=lazyLoad()> Lazy Load </div>
</html>
That make some sense and they seem to increase initial startup time by that a lot. I tend to believe them. However what I'm wondering is: Is using eval there going to disable any efforts the Browsers JavaScript JIT might take to precompile? That at least was my understanding how it would work: Whenever there is an "eval" no JIT.
Then the lazy loading with eval comes at some price of reduced runtime performance. That might be pretty okay for gmail (since I guess they don't do any computation intensive stuff) but for other applications it might not.
On reducing startup time for mobile web apps, we can cut down the modules on which it operates and move some modules to the web application server for access.
Posted by: web design perth | 08/18/2011 at 08:13 AM
n a world where the line between mobile and non-mobile is necessarily blurred and a document that restricts its focus solely to best practices that are uniquely mobile would most likely be very short. With this in mind, the focus of this document is to address those aspects of Web application development for which there are additional, non-trivial concerns associated with the mobile context. This applies equally both to the limitations of the mobile context (e.g. small screen, intermittent connectivity), and also the additional scope and features that should be considered when developing for the mobile context
Posted by: web design | 12/28/2011 at 07:05 AM
Deep touhght! Thanks for contributing.
Posted by: Luckie | 01/09/2012 at 10:14 AM