I wonder how fast you could make simple PhoneGap app loaded. My simple app takes 6-8 seconds on Galaxy S3 (all resources are stored in local drive). Not sure whether it is
You Can increase speed of app by:
1. Using minified versions of js which you have included in you project.
2. Avoid using images with bigger size. tune them with web compatible PNG files
Optimize Images
Use CSS Sprite Sheets
.icon {
width: 14px; height: 14px;
background-image: url("glyphicons-halflings.png");
}
.icon-glass {
background-position: 0 0;
}
.icon-music {
background-position: -24px 0;
}
.icon-search {
background-position: -48px 0;
}
Use the right image size (don't scale images in HTML) Host images on scalable, distributed systems (i.e. S3) Avoid 404s for images
<img src="{{pic}}" onerror='this.src="nopic.jpg"'/>
3. Avoid using much of CSS.Limit Shadows and Gradients link box-shadow,border-radius,gradients,text-align
Try disabling some of the CSS that slows it down. In your jquery mobile .css file add this to the bottom:
* {
text-shadow: none !important;
-webkit-box-shadow: none !important;
-webkit-border-radius:0 !important;
-webkit-border-top-left-radius:0 !important;
-webkit-border-bottom-left-radius:0 !important;
-webkit-border-bottom-right-radius:0 !important;
-webkit-border-top-right-radius:0 !important;
}
4. Use CSS Transitions + Hardware Acceleration Use Native Scrolling
5. If you are using any Live url to get JS better download them and use locally.
6. FastClick FastClick is a simple, easy-to-use library for eliminating the 300ms delay between a physical tap and the firing of a click event on mobile browsers.
7. use Slpash screen.
8. Avoid using framework use only if necessary. Try to make responsive design.
9. Don't generate the UI on the server.Create the UI in JavaScript at the client-side
10. Minimize Reflows
slow
$("#header a.back").on("click", clickHandler);
$("#header a.back").css("color", "white");
$("#header a.back").css("text-decoration", "none");
$("#header a.back").attr("href", "#");
Fast
var $backButton = $("#header a.back");
$backButton.on("click", clickHandler);
$backButton.css("color", "white");
$backButton.css("text-decoration", "none");
$backButton.attr("href", "#");
11. Avoid Network Access
Dont make network dependend apps for getting content
$.ajax({url: "services/states"}).done(function(data) {
states = data;
});
use Cache Static Data LocalStorage, Database & File slow
$.ajax({url: "slow/feed"}).done(function(data) {
});
fast
dataAdapter.getItems().done(function(data) {
});
12. Don't wait for the data to display the UI
// Display view
displayView();
// Get data
$.ajax({url: "product/101"}).done(function(product) {
// Update view
});
Anecdotal data:
My phonegap apps can load in 2 seconds (from tapping the icon) on an iPad 3. Even so, you are advised to use the splash screen plugin to maintain the splash until your app's UI has loaded so as to prevent any flickering, etc.
Things You Can Do:
1) Don't wait on your data to start displaying your user interface.
In one of my apps, the file system provides the backing data. Although the file system is fast, there's no reason to block the initial display of the user interface while waiting for it. Although there will be an initial blank interface for a moment, this is OK -- in fact, Apple's guidelines for splash screens are to show the user interface as if it were unpopulated. (Not that most people agree or follow the advice).
The same holds true if you are loading any network data -- show the UI as soon as you can to eliminate the feeling of a slow-loading app. Then if your data is going to be slow to load, put up a spinner. The user will see that your app has loaded quickly and that the network is now the bottleneck.
2) Reduce the size/number of starting assets
The fewer scripts, stylesheets, etc., that you can load at startup, the better. Most web views are reasonably good at pipelining these as much as possible, but fundamentally the more data the web view needs to load just to show your UI, the slower the load time of your app will be. (This is why Apple's advice for the splash screens make sense: showing an unpopulated UI nearly immediately is supposed to help users feel that the app has loaded quickly, even when it hasn't. I'm not entirely convinced by that argument...!)
Essentially, you should try to load the bare minimum number of assets required to generate an unpopulated UI, and then load the rest in after it is displayed. If this is going to take time, throw up a spinner.
3) Reduce the number of plugins to the bare number required for your app's functionality
Plugins take time to initialize, and they do so prior to deviceready
being called. The more plugins you have, necessarily, the longer your app takes to get going. You can mitigate this to some degree if you can throw up an unpopulated UI prior to deviceready
, but this only works if you aren't completely dependent on one or more plugins being loaded. Again, this is why the splash screen plugin is useful.)
4) Avoid any complex computation at startup until after the UI is presented
If possible, of course. Even if your app needs to push data around (say to create a database upon first launch), throw the UI up first, and then a spinner while the data is handled. If your app needs to calculate something complex, throw up the UI first, and then crunch your numbers.
5) Understand that some of the load time is out of your control
The native wrapper has to be loaded, which then has to initialize a web view (which takes time), which then has to load cordova.js (in order to interface between the native and web sides). This is stuff you really can't avoid (although you could avoid cordova.js if you weren't using any of Cordova's functionality. But then why not just build a simpler shell in that case -- no need to use Cordova at all.)
6) Devices vary widely
Of course, a load time on one device has no bearing, what-so-ever on another device. This is true on any platform, though I suspect it's more visible on Android due to the wide cost range of devices. A slow android device is obviously going to take far longer to load your app than a top-of-the-line android model. The same generally holds true for newer devices as well. For example, if my app can load in 2s on a brand new iPad, chances are good it will take slightly longer on older hardware. (For me, I figure that if I can load the app in 2-3 seconds on an iPad 3 -- which isn't the newest -- it should load even faster on newer hardware).
Finally:
I'm not sure you're going to get much below 1-2 second load times here. I can also state that 2-3 second load times is usually not hard to achieve -- I haven't put any special effort into most of my apps, and they load quickly and efficiently. (In fact, my one native app loads more slowly than my phonegap apps -- 4 seconds vs 2-3.)