Ridiculously slow startup time on Meteor iOS Cordova application (LocalMarket)?


#1

As you can see in the gif, the startup time of the localmarket ios meteor app is ridiculously long. It took around 7 seconds normally, however once i added fastrender and fastclick, it dropped down to 4 seconds. Why is this? I noticed the Verso app loads far faster. How can I make a meteor ios app that loads faster? 4 seconds absolutely kills users, and this happens everytime the app is restarted. Any fix to this?


Find what package depends on a give package
#2

I don’t see how fastclick can have any influence on startup time. The reason fastrender might help is because apps like LocalMarket deliberately keep showing the launch screen until a DDP connection has been established and data has been loaded. That makes sense if the UI depends on that data being available, but it does mean startup time is highly unpredictable (because it depends on network conditions). So it might be better to design your app in a way that makes it possible to show something even if the data has not yet been loaded.

Are you running the LocalMarket app in development or as a production build? In production, we concatenate and minify JavaScript, so that might help reduce loading time. Other than that, loading time is dependent on the device used, and there is definitely a lower limit to how fast a Cordova app can load.


#3

I agree it’s crazy slow and that has to be thought of in the design to show a placeholder or intro splash so the user doesn’t get put off.

minify and concatenate all assets (css,js) and compress images / also load from a cookieless domain will help to reduce load time also


#4

Hi Martijn,

Absolutely loving the improvements in 1.3, especially all the new Cordova functionality. Our only challenge (and it seems to be quite common across SO and the forum) is that we’re getting bizarrely long load times on Cordova (> 10 seconds).

Cordova apps can normally be brought down to a load time of 2-3 seconds, so there’s something going on here.

Is it possible to get guidance on at least a ‘happy path’ using one of the boilerplate apps that shows us a loading time of < 5 seconds? We can then copy that approach (splashscreen settings etc.) and can isolate any remaining issues to our own code.

Best regards from the Hive team,

John


#5

@jfurneaux: That sounds like an issue with the splashscreen, which has a 10 second timeout by default, but should hide automatically when the body renders.

Are you using Blaze or React?

Do you use hold() to hold the splashscreen longer, maybe to wait until data has been loaded? Because that would also explain the longer load time.


#6

Thanks Martijn, that definitely sounds like a possibility. To make testing easier, what’s the best way to completely remove the splashscreen, so we can include/exclude as a possibility? I’ve seen several suggestions online, none of which have worked for us.

Much appreciated,

John


#7

You should be able to remove the launch-screen package. It is usually included as a dependency of mobile-experience, so you may need to remove that one and add back the other dependencies (like fastclick) that you do want in there.


#8

Same problem here, removing lauch-screen does not help. Startup is taking 10 seconds, on a friends large cordova app it takes around 4…


#9

No worries. It is working fine on Meteor 1.3. Just remove the mobile-experience package and add back all of the dependencies except for launch-screen. I will publish an article soon showing how to do this. Stay tuned.


#10

Can you provide the link for the article soon as you publish it please ?


#11

I don’t know if this helps, but I did this within my layout onRendered

  if (Meteor.isCordova) {
    navigator.splashscreen.hide();
  }

#12

The article is finally published:

Works beautifully.


#13

When looking at the default configuration file (config.xml), it looks like the SplashScreenDelay value is set to 5000, but in the Launch Screen package there’s a timeout of 6000.

It turns out that our load time of over 10 seconds also had to do with this timeout. Is there any reason why the defaults of 5 seconds and 6 seconds are set? Or is it arbitrary?

Thanks so much!


#14

karl your navigator.splashscreen.hide(); snippet worked for me, and seems like a much simpler solution than removing packages and manually re-adding dependencies. Thanks!


#15

I am using Ionic/Angular not blaze and still having the same issue .

even though i tried both ways up , ( it worked with blaze exp. not Ionic/Angular )

So i removed launchScreen plugin and added : cordova-plugin-splashscreen@3.2.1

meteor add cordova:cordova-plugin-splashscreen@3.2.1

and in mobile-config.js

App.setPreference(‘SplashScreenDelay’, ‘0’);


#16

+1 for @hamzamu.

This worked great for me! I tried to just remove the package like @gg2001 said, but my screen would flash white for a second after the splash screen went away. It didn’t look good, but that cordova plugin worked much better.


#17

Do I have to rebuild a new app for @gg2001 solution? or @karls solution


#19

Maybe someone from this thread can help me here - How to debug imports to check startup time during imports How to debug imports to check startup time during imports


#20

My debugging of our app shows that most time is spent loading the different javascript modules which is significantly slower on mobile than on web,
since the introduction of npm there are tons of dependencies that accumulate with each utility package you add, plus it seems to me there’s no distinction between npm packages used on server only,so they are also packaged with the client code.
also meteor modules not specifying correctly dependencies required for server only might be causing client side modules to bloat.
Moving your code to the new dynamic dependencies seems unrealistic, to start writing all your code in callback hell style.
any ideas how to tackle this issue are welcome…


Meteor cordova startup time?
#21

some ideas

  • use the bundle visualizer to actually see what’s actually in your bundle. afaik meteor should only bundle npms that are imported in the client side code, so make sure there aren’t any unexpected things importing bloated npms
  • you can use await with dynamic import to avoid callback hell