Should You Minify Resources in Cordova/PhoneGap Apps?

In an earlier post, I researched the load times of Cordova when using jQuery and jQuery Mobile. Now, I want to dig deeper on how you should load your files in a Cordova application. This time I’m focusing on whether you should minify your JavaScript and CSS resources. I mean the local files which are not loaded over a network. I think the general belief is that there is no need to minify the files as they are loaded fast from the local filesystem. However, a smaller file will still probably be loaded and parsed faster, but the question is: how much faster?

Read More

Effect of jQuery and jQuery Mobile on PhoneGap/Cordova Startup Speed

App load time can have a significant effect on how users perceive your app (see these articles). While load time of Cordova apps is a complex thing made up of multiple steps, one (possibly big) part of it is loading all the JavaScript and CSS resources on the initial HTML page.

An often used framework for mobile apps is jQuery Mobile. Just look at the "related tags" statistics on Cordova questions on StackOverflow. Such libraries are useful for beginners. Lately, though, I have been trying to write plain JavaScript without libraries. To validate the performance gains from this approach, I wanted to see how much using jQuery and jQuery Mobile affect the load time of an app.

Measurements

I originally measured with four devices: iPhone 3GS, iPhone 4S, iPad 2, and 3rd generation iPad. While I procrastinated writing this post, new devices were released (and bought). So I made additional measurements on iPhone 5S and retina iPad Mini as well.

In all measurements, I used Cordova 3.0 (although 3.1 3.2 3.3 is already released). I had the console plugin installed, but no other plugins. The template I used was a stripped down version of the default project template (see this gist for the complete HTML I used). I had three versions:

  • without any JavaScript libraries, only loading cordova.js
  • with cordova.js and jQuery 2.0.3
  • with cordova.js, jQuery 1.9.1, and jQuery Mobile 1.3.2 (including CSS and JavaScript)

The versions of jQuery and jQuery Mobile are the latest versions at the time of making the first measurements.

I measured the time between a script element in the beginning of head and the deviceready event to fire (as you can see from the template). With each device, I measured every version 10 times to get more reliable data.

Results

The results are summarised in the figure below. The raw data is also available.

measurements.png

The results show no real difference between iOS 5 and 7 on iPad 2 and between iOS 6 and 7 on 3rd generation iPad. Neither is there much difference between those two devices. iPhone performance has clearly improved in newer devices. The same is true for iPad Mini. Nothing surprising in that, though.

What is notable is that jQuery Mobile does affect the start-up time of the application quite significantly. In most devices, it takes around 0.5s for the deviceready event to trigger. And over 0.4s even on the latest iPhone, not to mention the over a second on 3GS.

Take Aways

So what can we learn from the results? I’d say that if you target older versions of iOS which run on 3GS (or, perhaps iPad 1), you should think long and hard before you adopt a large library like jQuery Mobile. If you still device to go with jQuery Mobile (or similar libraries), the load speed of the app could (and should) be improved by loading the libraries after deviceready. Also, I used the complete library, and you should definitely build your custom version with only the needed components.

Another alternative is to use more lightweight frameworks such as Zepto + Topcoat. The fastest approach, performance wise, is writing JavaScript and CSS without libraries. If you are not comfortable with that, now might be a good time to learn.

All in all, just keep in mind that half a second can feel like a long time and can have an effect on your app ratings and business performance. On the other hand, if you do a lot of other processing on startup, the JavaScript loading times might not be a significant factor in app startup.

Conclusion

As with most questions in software development, my suggestion whether or not to use libraries in Cordova apps is “it depends”. It is a balance between app load performance and developer productivity. Just keep in mind that the libraries you use can have a big impact on load times. Personally, while I do have an app in the app store (published by my previous company) that uses jQuery Mobile, I would not use it in a new project.

What do you think? Do you use libraries in your Cordova apps?

Update: If you read this far, you might also want to check out the post about whether you should minify your resources in a Cordova/PhoneGap app.


Want to get more posts like this to your inbox?

Sign up for my newsletter to get an email on new posts like this. I don't email you too often, only when I have a new interesting post to share with you.

Safari on iOS 7

Last week, iOS 7 was released and, again, the speed of adoption has been amazing. Maximiliano Firtman has a great post summarising the changes in Safari in iOS 7. A lot has changed, not all for the better as he says: "this is the buggiest Safari version since 1.0".

To me, the interesting new features include:

  • video <track> support for subtitles and closed captions
  • <progress> element support for creating progress bars
  • Airplay API for streaming content to other devices
  • paginate mode to enable easy pagination of pages in a UIWebView

There are some not-so-good news as well:

  • Nitro JavaScript engine is still not used in UIWebView
  • Support for input type datetime has been removed

The last point required me to update my app, since form fields using the type datetime are now rendered as text fields.

There are plenty more interesting details, so I suggest you read the whole post.

PhoneGap Files, Filepaths, Backups, and a Nasty Bug

I recently updated my main phone to iOS7. To my surprise, images within my The Fisher app no longer appeared. All the stored data was there but instead of the images I only got a white screen.

My first hope was that this was due to my app not being the version downloaded from the App Store and the restoring from backup not working for non-App Store. But I had to test it with my backup phone which I can easily erase and restore from backups. After testing, I was in a bit of a panic mode since the images really were not restored from the backups. To put it mildly, in an app with user-generated content, losing that content is not good.

Inspecting the contents of the app bundle with iExplorer (which I highly recommend), I found out that the files were there but they were not shown in the UI. Comparing the catches from the backup with newly added catches, I noticed that the file paths were different.

PhoneGap Files and Filepaths

On iOS (and when working with PhoneGap), files have a path like this:

file://localhost/var/mobile/Applications/C5875140-A4D2-4310-A6A7-55CC2F504F2A/Documents/1377869303030.jpg

In my app, I was saving these absolute paths to the database. And apparently you should never do that! As the Apple File System Programming Guide says, file paths consist of application home directory and the location of the file within the apps sandbox. The thing is, the application home directory can change at least when restoring from backups.

Fixing is Easy

Fixing the problem is easy. Instead of storing the absolute path of the file, you should only store the part of the file that you specify. In my app, the file names are based on the time they were created, so they are all of the form 1377869303030.jpg (or, [0-9]+\.jpg). Thus, whenever wanting to access the file, I can simply replace the beginning of the stored file path with the correct path to the application persistent file directory. To get this directory path, I have the following code executed on deviceready event.

function setFsRoot(callback) {
  window.requestFileSystem(LocalFileSystem.PERSISTENT,
                           0,
                           gotFS,
                           fail);
  function fail() {
    // handle the error
  }

  function gotFS(fileSystem) {
    // save the file system for later access
    window.FS_ROOT = fileSystem.root.fullPath;
    callback();
  }
}

A file path is then window.FS_ROOT + fileName. Changing all file access to work like this I was able to fix the issue with relatively little changes. If you are storing absolute paths, you should make this fix now, before everyone upgrades to iOS7.

Conclusion

Accessing files is critical in my app, so I really should have done a better job in testing backup restores. However, I do think that the Apple documentation as well as PhoneGap API docs should mention this potential pitfall.

Now my problem is fixed and an updated version 1.1.1 is already available in the App Store. Hopefully, no major harm was done to my users. I was also lucky that file removals used the same file path, so the user was not able to remove the catches before I updated the app.

Two Useful Tips for (iOS) PhoneGap Developers

Developing with PhoneGap? Great, me too. Might I suggest two great tips by Raymond Camden:

  • Modify the WWW template: A tip on how to change the template when creating a new PhoneGap project. Since I understood how the PhoneGap project was structured, the default template has bugged me. Also, there's a little bonus tip for Sublime Text users who, like me, were not aware of the subl command.
  • Safari Remote Debugging and PhoneGap: If you develop for iOS with PhoneGap, you really should know how to debug your application with Safari developer tools.

Update Feb 8th 2013: Might as well add a third tip from the same source: