OK so this isn’t a technical question about my code but more of a higher level conceptual question about what influences ionic app load times.
Basically, my app is a digital textbook with around 300 pages and about 2000 small audio files (1-4 seconds each) stored locally (average 8 audio files per page) Right now my load time on iOS is around 20 seconds.
My root page is a table of contents that imports and can push any of the first pages in each of the 30 lessons (so it imports 30 pages). I’m using native-audio so I don’t think that it loads the audio files until they are activated through user input.
I’m just curious what factors might be influencing the load time - the sheer number of pages? The audio files even though they aren’t pre-loading? The number of pages imported in my home page?
Any advice on where I can try to optimize would be much appreciated. I would love to get my load time under 10 seconds if possible.
I’m using ionic 3.1.0 with all dependencies updated and the most recent version of Xcode.
So overall, the number of pages that you have in your app is a lot, like REALLY A LOT.
Are these static pages? Mostly loading set data and are not dynamic?
Whats really going on under the hood, is that each time you have a new page, it gets added to the JS bundle and causes an increase in file size.
Typically the bigger the the main.js bundle is, the longer it takes to parse. So the long start time can be attributed to this.
What I really suggest in this case: remove excess number of pages, make things more dynamic.
An app really shouldn’t have that many pages over all, but rather have a few templates that can be dynamically updated to the data that it gets passed.
Thank you for responding, Mike! It’s disappointing to hear that the sheer number of pages is the issue since that will be a rather lengthy re-write to fix and possibly above my skill level.
All of the pages are almost entirely static but there a lot of grids of various sizes on most pages and these grids have tap events.
Would your recommendation be to somehow store all of this ion-content information in a database and then have the content pulled from the database and loaded as needed?
Believe in yourself! You got this!
What you could do to start, is move your data from static to some sort of JSON format. Just as a step 1 to move from the static content.
This will give you chance to look over the content you have, and figure out a way to organize it all so that you can start making the pages dynamic.
After some refactoring, you’ll probably want to consider using something like ionic-storage for this, but build out the JSON first.
Alright thanks so much for providing some direction! I’ll start doing some reading now
@mhartington - one quick follow-up question.
If I wait for lazy loading to become more stable would there be a way to implement lazy loading within this many page project in order to speed up load time? Or regardless of lazy loading do you recommend using JSON formatting and dynamically generating page content from the JSON?
Obviously I can’t speak for Mike, but for my money I’d still probably recommend using dynamic pages. If nothing else it’d reduce the overall build size, which even with lazy loading is still a desirable goal. Both for just the app size as well as loading time.
Thanks for responding, SigmundFroyd. I just wasn’t sure if lazy loading had any impact on the bundle size or not, but obviously switching over the JSON seems to be like the recommended way to go.
I was just hoping to avoid making any major changes at this point since I was so close to finished and was really hoping to move on to optimizations before publishing. I guess that optimizations might be a fairly large undertaking
Mike actually just posted a new article on the Ionic blog regarding lazy loading, Lazy Loading Pt. 1.
In particular he even mentions:
“Now it’s important to note, that this does not mean our apps final bundle size is smaller, but we’re distributing the bytes and only loading what is needed.”
Which should, perhaps coincidentally, answer the question of bundle size.
In my experience, optimizing takes up far more time than I’d like.
@SigmundFroyd the confusing thing about that blog post that you linked discussing lazy loading is that though it says bundle size will be unchanged, it also says: “Consider apps with 50+ different pages and many more UI components. Loading these all up front is very resource expensive. Instead, if you can only load 2-4 different components up front and lazy load the rest, users will have a much better experience.”
So the way it would work out using your app as an example, is this:
Without lazy loading, it compiles all of your code & views, and sticks them in main.bundle.js, aye?
So on start-up, it naturally reads this file as it defines how your app functions. In your case, that means it’s reading through all 300 pages and thus is loading them on start-up.
For an example I will get to in a moment, let’s just say this results in a bundle size of 10 MB.
With lazy loading involved, it compiles all of your code & views, but instead of sticking everything into main.bundle.js, it only puts your core app.component.ts stuff into it (e.g. core Ionic stuff and your home page or what have you).
It then takes those 299 other views (i.e. everything but your home page), and creates a separate js file for them (in this case named 0-299.js).
On start-up, it reads through your main.bundle.js like before, however this go round it only has a little bit to read. Then, when you want to go to page 255, it’s like oh hey, lemme read this 255.js file now. Hence an increase of speed on start-up.
So, hopefully that explained it well.
That’s great and very clear explanation - thank you for writing it up. I guess my only questions is whether there is an appreciable difference in the time it takes to start up an app under the two circumstances you described.
So in scenario 1: “Without lazy loading, it compiles all of your code & views, and sticks them in main.bundle.js. So on start-up, it naturally reads this file as it defines how your app functions”. Let’s assume that this takes 10 seconds.
In scenario 2: with lazy loading it compiles your codes and views and then “on start-up, it reads through your main.bundle.js like before, however this go round it only has a little bit to read.” Would this save very much time or would it be negligible?
I’m just not sure what percent of start-up time is related to compilation of codes and views and what percent is related to reading the main.bundle.js and I’m not even sure where I would start investigating if I had to figure it out myself!
Ah, fair enough. I worried I didn’t spend enough time on start-up time.
I would imagine that in your situation it would probably be a noticeable improvement in start-up time with lazy loading.
This is also the reason I believe it would improve the start-up time of your app, right now your 300 views are being stuck into main.bundle.js and so it has a lot of code to parse on start-up.
As far as how much exactly it would improve…I’m afraid can’t say. I wish I could say, as obviously if I knew it would help your decision as to whether or not you should wait for lazy loading to mature or not.
Does your app have many/any providers or anything like that?
The only provider I’m using is the default status bar, splash, and errorhandler. The app is just basic HTML pages with ionic grids and limited typescript for user interaction with native audio plugin.
I understand that you can’t give numbers on speed up time but I think based on the info that you provided and Mike’s blog post today that lazy loading will likely speed my boot up time to a point where it’s acceptable.
Running my app on device or simulator it’s plenty fast and responsive, the boot time is the only aspect that I’m not happy with.
Thanks so much for providing this information - it is really helpful!
This app sounds to me like the absolute poster child for the current lazy page loading system. I think it will provide drastic improvement for you.
Awesome that’s great news. I’m going to finish all of my final content edits and quiz system and then when I finish I’ll implement lazy loading following the guides from the ionic team.
I’ll report before and after results here after I have some data on app size, load times, etc. If I have time I will try to make some charts to show the differences!
I hate disagreeing with folks like @mhartington and @SigmundFroyd, but I would go so far as to suggest sticking with your current 300 pages, because from your description it will probably be pretty difficult to abstract out enough similarity between pages to make some sort of JSON-based cookie-cutter solution very practical.
Your ToC page won’t even have to eagerly load those first 30 pages. Under lazy loading, all your interaction with the navigation system uses strings, and you won’t need a single lesson page until it is selected.
Yeah I’ll make the switch to lazy loading and hope that cuts startup time enough that I won’t need a switch to JSON based dynamic page generation.
Literally each of the 300 pages is unique and there are over 200 grids with probably 50 different sizes with respect to rows/columns/widths, etc.
I’ll make sure to record android and iOS app size and boot time before and after lazy loading to make some good comparisons. Hopefully when I’m ready to load lazily in a few weeks there will be a New Ionic point release with some more stability, since things are moving so fast right now.
Could you report back to us how the lazy loading improves your start up times? Really curious!
Yeah of course! I’ll report back once I make the switch