I’ve been working for the past few days on improving the performance of page transitions for ionic. I haven’t reached the results that I want yet, but here’s everything I was able to understand, hopefully we can combine everything we have in order to improve page transitions.
After you record a page transition, if you see bars that go on top of the 60fps and reach maybe 30fps this means that we have a slow transition. (Why? more on that in the conclusion)
In order to eliminate external factors, I stopped working on my app and downloaded an official ionic starter app: side menu.
I was still seeing bars/spikes going on top of the 60fps limit. Which suggestions that the issue does not depend on the following:
- heavy markup
- filters (they are a bottleneck in general but not in this scenario because we haven’t used them yet)
- route controller (the routes that I was testing didn’t even have a controller)
- custom user code (although this could make it worse)
- I also disabled page transitions (globally and via the nav-transition=“none”) and I was still getting almost the same results!
Here’s where I realized that the bottleneck is not the actual CSS transition, but everything happening before (more on that in the conclusion)
- All my tests were done on a previously cached route:
- enable route caching
- visit page
- go back
- start profiling
- click on link that opens next route (which is already cached)
- stop profiling
If you are seeing good results, I usually try simulating poor mobile performance on my desktop by making the app’s viewport much larger than a mobile display. And if you want to test the actual performance, you can
ionic run androidyour app and connect using Chrome’s webview debug (available on android >= 4.4.4).
These are the steps that you need to follow if you want to see the FPS counter and Flame chart:
Chrome developer tools > Timeline > Select: Causes, JS Profiler, Memory, Paint > Record > open cached view > Stop
- Flame Chart:
Timeline is also showing the following for Layout painting: Forced synchronous layout is a possible performance bottleneck.
You can argue that ~68ms is fine when opening a cached view. But note that as soon as you add any HTML to the route that you’re opening, this number will get much bigger.
Here’s the conclusion that I came up with, feel free to correct me or to improve upon it:
Let me know what you think