Visual Studio Home Visual Studio
SIGN UP Help shape the TACO tools and get access to early releases.

Evaluate the performance costs of a Cordova app

Updated: 10/8/2015

Understanding the performance costs of Cordova will help you as you evaluate the platform, and plan ahead as you develop for it. There are some areas that deserve special attention: startup and resume overhead due to the interpreted nature of the web languages, memory overhead from hosting an entire browser in your app, serialization overhead when sending data to and from native code, and the general performance concerns that come with web applications.

Note: We used a Nexus 7, iPad Mini 3, and Lumia 928 to produce most of the results that you'll see presented in this topic.

The startup cost

The first impression you get to make is when a user launches your app for the first time. Are they pulled right into the app or is there a long loading period? Launching a Cordova app feels almost like setting off a Rube Goldberg machine: you’re launching a native app that hosts a WebView that points to an HTML file that initializes your application and pulls in all your JavaScript and HTML templates. Unsurprisingly, this can take a moment.

We don’t know the complexity of your app, but we experimented with launch times for a very basic "Hello World" app that updated some text on page when the “deviceready” event fires. For the timings in the table below, we used a camera to measure the time from when the touch was visually registered until we could see the text update. Additionally, we define “cold” as launching the app immediately after a reboot (when assets should be completely cleared from RAM) and “warm” as launching the app right after we close it (when maybe the operating system hasn’t really cleaned everything up yet).


Cordova Cold

Native Cold

Cordova Warm

Native Warm

Android 4.43425 ms557 ms 3358 ms454 ms
iOS 83142 ms5825 ms 1921 ms2000 ms
WP 8.02433 ms1667 ms 1083 ms1098 ms

If you’re experiencing large delays when your app starts up, see what you tasks you can defer or cut to minimize your time. Are you requesting all your resources when the app launches or can some of those resources be deferred to load on demand? Does the UI library that you're using include components that your app is not using?

The resume cost

Just like when your app starts, resuming your app doesn't happen instantly either. If your app needs to do anything to respond to the “resume” event, you’ll want to keep an eye on this.

We tested this with a “Hello World” app that changed its background color when the “resume” event fired. Then, by using a camera, we measured the time from tapping on the app and the switching of the screen being visually registered, until the background color was updated. We don’t have comparisons for native apps, but it seemed like the times that transpired were based more on the animation that the operating system used to smoothly bring the app to full screen rather than to wake the app up.



Android 4.4450 ms
iOS 858.3 ms
WP 8.0595.8 ms

If you're experiencing these issues, see what code is running when you resume your app and if you can move that activity to another place.

The memory cost

Cordova apps have a higher memory footprint than their native counterparts. Hosting what is essentially a browser inside of your app is not inexpensive. This can be a significant issue on low-end phones.

Android and iOS don't have hard numbers for allowable memory consumption. Each device and platform provides different usage allowances, and those allowances change based on how much memory the device has, and how much is in use at any given time. Windows Phone has some hard limits, ranging from 150MB to 825MB.

For a benchmark, here is the memory usage we recorded for "Hello World" apps across the three platforms. For the browser, we navigated to about:blank.





Android26 MB14 MB 59 MB
iOS7 MB20 MB 18 MB
WP30 MB23 MB 36 MB

While we haven't compared a full-featured app implemented both natively, and with Cordova across all three platforms, we did compare a native app across the platforms. This is a data point worth keeping in mind.

In the table below, you'll see that Android consumed more memory and iOS consumed less. To obtain these numbers, we launched the Facebook app, loaded the news feed, a profile page, and then recorded the memory usage.



Android 4.4101.4 MB
iOS 875.10 MB
WP 8.190.42 MB

If you’re struggling with these issues, see if your app is allocating large DOM trees or keeping extra copies of data in memory. Try virtualizing things that normally require large DOM trees, such as lists or tables, and make sure you are letting go of data you don’t need so that the garbage collector can dispose of it.

The communication cost

Due to the architecture of Cordova which provides a thin native shim hosting a WebView, moving application state from JavaScript to the native side and back requires expensive serialization and deserialization. You might be reading and writing files, getting photos from the camera, or getting the results of computationally expensive calculations performed in native code. The good news is that our testing indicated this time is linearly related to the size of the data being transferred. The table below shows the times that we recorded when sending an array of numbers across the barrier and back.






Android 4.44 ms22 ms 157 ms1121 ms
iOS 8.03 ms45 ms 135 ms1120 ms
WP 8.11 ms27 ms 139 ms877 ms

If you’re struggling with this, make sure you that you know what is being sent back and forth and try to figure out how to reduce it. Look for duplicate data or maybe even experiment with different data formats to see if one serializes faster than others.

The web cost

Although last here, perhaps the most important cost to consider, is the cost that comes from building with web technologies. This is a cost that your team may have already paid if you have experience building applications for the modern web. If you’re new to frontend web technologies, the learning curve appears deceptively low. This is not a magic bullet: just like any other tech stack, building a performant application requires planning and knowledge of the pitfalls. If you’re struggling with this, read this article: Optimize the performance of a Cordova app.

Final thoughts

One of the key attractors to Cordova is that you use web technology to build cross-platform apps. If your team has a strong web background or has an existing web app, leveraging that experience and those assets while tracking the costs listed here should enable you to bring a quality app to your customers.

Did you find this article helpful?


We're sorry to hear that! Feel free to email our team with your question.

Want FASTER answers? Our team monitors a special StackOverflow tag here.