Cordova Apps are slow

Hello, I have noticed that running my app as an Android app it runs slower compared to running it as a web page in Chrome on the same device. I did some searching online and people have recommend using “Crosswalk” but it doesn’t have any improvement for me.

The most notable speed difference is during transitions (example, when the F7 dialog shows/hides).

Does anyone have any suggestions which would improve performance?


1 Like

Sounds like you face an similar issue with hardware accelleration as on the below topic. Framework7 uses css animations, which should be very smooth as they should be hardware accellerated, even on quitte old/low budget devices.

Thanks for the response @Tim!

I did a directory search for “AndroidManifest.xml” in my project folder and found a dozen instances. Could you indicate the location to this file?


My android and ios apps are quite large and so far pretty snappy.

Did you try lowering the animation times in the .css?

Do you have your .js files compressed? If you have a lot of them this can slow down the webview considerably.

@PPetree, thanks for your response.

How do I lower the animation times for the F7 dialog?

I am referencing the “.min.js” version of Framework7 in my app. I only have one other JS and CSS file and each are very small (<1KB).


First, check the docs (really… do this first) and see if there’s a .not-animated class for the dialogs and if so, add that and see if that’s what you want. If you still want animation then you’ll have to open the framework7 .css file you included and then search for:


In the non-minified bundle the dialog stuff is down below line 6200. You’ll have to change the transition-duration time from what ever ms value it currently has to something less. Then experiment and test it.

Hello @PPetree. I confirmed that there is a .not-animated class for dialogs. However, this doesn’t solve my issue as it merely disables animations. I would like to have animations for opening/closing dialogs in my app.

I also played around with the values for transition-duration but they are still visibly slow when running in Cordova.

Are there any other suggestions?


or use cordova-custom-config plugin, its best way but harder

<platform name="android">
    <!-- custom preferences examples -->
    <custom-preference name="android-manifest/application/@android:hardwareAccelerated" value="true" />
    <custom-preference name="android-manifest/@android:hardwareAccelerated" value="true" />

if this not help try add this plugin

@Overman thanks but it didn’t seem to make any difference. However, when I tested the same app on a different Android device it wasn’t slow at all. So I guess the issue is device related.

Could be GPU memory related. Eliminate opacity values everywhere you can. Calculate the color for text based on the background value (assuming plain background).

@sroussey I think you are on to something! The dialog appears slowing on a page that I have hundreds of divs with opacity. So that might be the reason why this is happening for me :roll_eyes:

Each opacity creates a layer for the compositor. These are uncompressed bitmaps and can get large. F7 also adds various opacity settings. In v5 the text has opacity (will need to research if text adds a layer—not sure; I know chrome devs and can ask).

For animation to be fast, F7 adds stuff to CSS to force layers (which is why it should be fast). You can have too many and exhaust GPU memory (even on expensive hardware) and WebKit/blink will make choices of its own. And can choose non-animating divs to accelerate.

There are hints you can make to the browser engine. In a few weeks I may have a few days to dig in and propose changes.

However, the easiest thing to do is to remove opacity and shadows. Both force layers.

1 Like

@sroussey understood! Thanks for the clarification :+1:

BTW: the layers panel in various browsers dev tools are rarely enabled by default, so you will need to enable them in advanced settings or similar. This is of my app, and you can see that there are too many fullscreen layers on top of each other.

There can be a lot of diagnostic information. If it says “overlap” that likely means opacity or shadow. Things not visible will get excluded (see the 0 memory) – usually.