Delay between ngAfterViewInit and ionViewWillEnter

Ionic Framework Ionic Angular
1

I’m trying to speed up our app launch time and I’ve found a long-ish delay between ngAfterViewInit and ionViewWillEnter. I’ve moved all my code into ionViewDidEnter and

constructor(…){
console.time();
console.log(‘Forecast constructor’)
console.timeLog();
}
ngOnInit() {
console.log(‘Forecast ngOnInit’)
console.timeLog();
console.timeStamp(‘Forecast ngOnInit’);
}

ionViewWillEnter() {
    console.log('Forecast ionViewWillEnter')
    console.timeLog();
    console.timeStamp('Forecast ionViewWillEnter');
}

ionViewDidEnter() {

    console.log('Forecast ionViewDidEnter start')
    console.timeLog();

…}

and this is the output

vendor.js:43681 Ionic Native: deviceready event fired after 236 ms
15:41:43.099 forecast-forecast-module.js:125292 Forecast constructor
15:41:43.118 forecast-forecast-module.js:125293 default: 18.72314453125 ms
15:41:43.148 forecast-forecast-module.js:125301 Forecast ngOnInit
15:41:43.148 forecast-forecast-module.js:125302 default: 48.5029296875 ms
15:41:43.152 forecast-forecast-module.js:125319 Forecast ngAfterViewInit
15:41:43.152 forecast-forecast-module.js:125320 default: 52.4951171875 ms
15:41:43.469 forecast-forecast-module.js:125296 Forecast ionViewWillEnter
15:41:43.469 forecast-forecast-module.js:125297 default: 369.56787109375 ms

As you can see there’s +300ms between the empty ngAfterViewInit and ionViewWillEnter. That’s actually the lowest I have seen. Is there something I can do to get that number even lower?

2

Why do you care about this difference between these two lifecycle hooks?

Unless you want to fiddle with either framework’s internals (Angular or Ionic) - requiring an insane level level of awareness on technology and intentions - there is no need to try to optimise these things you rather let the frameworks control for you

3

Here you get a Overview an a Explanation: Ionic Page Life Cycle - Ionic Documentation

4

I care because I’ve seen it take more than three seconds to change between pages on some phones (which are in another city and I don’t have the same model near by) so I’m looking at the things that are slowest on my test devices theorising they are what is slower on the other devices and I want to know if there is anything I can do to speed it up.

5

Thanks EinfachHans. That page shows most of the steps but doesn’t tell me what’s going on between ngAfterViewInit and ionViewWillEnter. What I’d like to work out is what happens between those two so I can make it faster. Maybe rendering the HTML and I can cut that down, or maybe it is loading plugins and I can cut some out. Or minified javascript? I figure there must be something because I don’t think everyone else sees such a long delay in just changing pages.

6

ok - without giving maybe the answer you look for, I would opt for the angular lifecycle hooks assuming/knowing the ionic hooks reside likely on top of them.

Besides, the delay could also be caused by lazy loading? That can cause delays in loading.

7

Ionic Lifecycle hooks have nothing to do with component creation. They are simply hooks for when the animation/transition of a page starts/end. No need to stress about it too much.

8

I realize that this is a large ask, and may therefore not be worth the effort, but if you are using Angular’s lazy loading, I think it’s worthwhile making a build that doesn’t (by putting everything in a single AppModule), and comparing benchmarks between the two.

Lazy loading tries to trade (what I as a user typically consider unexpected and therefore more annoying than usual) performance hiccups after the app itself has loaded and when you’re switching to functionality that hasn’t been loaded yet for monomaniacally attempting to reduce the initial launch time.

Once we’ve eliminated that as a source of discussion, some more general optimization opportunities are:

  1. Avoid busywaiting by making as much of your logic asynchronous as possible. If you have explicit setTimeouts in your code, try to get rid of them. If you don’t yet have proper data to display, come up with some sort of loading indicator or dummy data so that the screen at least appears to change ASAP.

  2. Minimize DOM elements. If you’ve got gigantic lists containing hundreds of items, find some sort of virtual scrolling system instead of just tossing them all into the DOM at once.

  3. Really concentrate on any code paths that get called by change detection. Try to minimize function calls from templates, except when they’re triggered by direct user interaction. Precompute values in the controller, stash them as properties, and reference them instead of doing {{figureOutHeavyFoo()}}.

3 Likes
9

I might be looking in the wrong place for the fix, but an app that takes 3 seconds to change between tabs is going to get me a lot of bad reviews so I definitely want to find the right bit to stress about.

10

In my app-routing.module I already have PreloadAllModules, and if I add it to the other routing.modules files I get errors about forRoot being called twice and recommending putting it back to forChild

RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })

11

I’m speaking of a much more drastic restructuring, to the point where a global search for @NgModule in your entire src/app/ directory returns only one hit: app.module.ts.

12

Is this happening on each page for only the first time or every time u select it?

And ig possible can u use devtools to monitor network to see how the requests go? Retrieving assets

How is the app deployed? As pwa? Or capcitor/cordova

Before undoing the lazy loadibg as per @rapropos suggestion, maybe first establish the cause?

Maybe there is some service eating cpu even though u dont expect

The alternative approach is to try a clean project with minimal features and see if it still happens

13

Each page is slower than I would like, but one is definitely worse. It’s a Capacitor project and I’ve moved everything into ngOnInit. But still switching back to that page (using tabs) is too slow. It looks like all it is doing is setting the class to be ion-page-invisible (or ion-page-hidden) and the z-index

14

Well, no other suggestion feom me other then start removibg chunks to see what part is causing delays

Changing classes shouldnt be an issue - so maybe some sort of hidden race condition or so?

Feel free to share suspicious chunks of code

15

I’m still suspecting a DOM with eleventy kajillion elements in it.

1 Like
16

True

Maybe some crazy ngFor construct (no pun intended)

Easy to go over the edge with that one

17

Just getting back to this… @CraigStanton big things to look for

  • Modifying dom during transitions
    Start by moving and requests/setters to being done after the transition has completed.
  • Simplify your structure
    If you have a very complex template, it can be expensive to render that. Simple is always better.
1 Like
18

I have made some progress in speeding up the transition. There are four tabs, switching between #3 and #4 is consistently fast. Anything involving #1 and #2 is slow. Even opening a modal over #1 is slow. I had thought the problem was in the modal. I have sped it up a bit by cutting the array down to just the items that can be on screen, until ionViewDidEnter is run. But even with an empty modal it was taking multiple seconds to open on some devices.

The biggest change so far seems to be in reducing the complexity of the page that the modal was being added to. It had an SVG with an enormous number of elements. I’ve pre-rendered some of them and it appears to be faster.