Framework: Aurelia takes 3 seconds to load on Samsung Galaxy S6/Android/Chrome on small bundled project with few deps

[insidewhy]

mkdir blah
cd blah
yo aurelia
gulp serve
gulp bundle # in another window after the serve completes

Loads in the blink of an eye on desktop browser. Takes 7-10 seconds to load the page on my Moto E using Chrome on Android 5.1. This is a reasonably powered (if budget) smartphone. I was surprised to have to wait so long and that it is the same no matter the state of the cache.

I'd love to use Aurelia for a project I'm working on but I can't consider it with that mobile performance. Is there any likelihood this will considerably improve within the next few months?

[dpinart]

we're also seeing large load times in mobile devices. About 20 seconds if bundled

[kollster]

We are experiencing extremely long startup times in Microsoft Edge on the desktop. Take http://aurelia.io/docs.html as an example - the startup time is over 20 seconds. In Chrome on the same devices, the startup time is about 3.5 seconds.

[insidewhy]

@kollster on my Moto E http://aurelia.io/docs.html takes 7-10 seconds to load, the same as the skeleton app. It makes me suspect there is a fixed cost to startup. Any idea how long Edge takes to load the skeleton app?

[zsmorris]

http://aurelia.io/docs http://aurelia.io/docs.html only takes 2-3 seconds
on my 2013 Moto G.

• Zac

On Mon, Nov 30, 2015 at 8:29 AM, Mr Friend [email protected] wrote:

@kollster https://github.com/kollster on my Moto E
http://aurelia.io/docs.html takes 7-10 seconds to load, the same as the
skeleton app. It makes me suspect there is a fixed cost to startup. Any
idea how long Edge takes to load the skeleton app?

—
Reply to this email directly or view it on GitHub
https://github.com/aurelia/framework/issues/254#issuecomment-160626849.

[francoishill]

I am myself frustrated with this long load times. But I had to realize this is not for Aurelia to solve. It is probably more JSPM. If you look at your timeline (in chrome developer tool's Network tab) you will see the files are loaded one-by-one. This is now with or without bundling. Bundled is just less files.

So if your latency is high (which is usually the case with internet based apps), it will take quite long. Because it does a full round-trip for each file.

First system.js is loaded, then browser-sync-client...js, then aurelia.js, then app-build.js, etc.

[insidewhy]

@francoishill I'm only loading 4 files here over my home network, 2 seconds latency per file? On mobile but not desktop, via the same local network? I don't think your reasoning is correct on this one.

[francoishill]

@ohjames If what you're saying is the case, then yes I would also not think that latency could be the issue. Have you tried hooking into it with chrome remote debugging?

• https://developer.chrome.com/devtools/docs/remote-debugging
• chrome://inspect/#devices

And then the other thing could be to ask this question on the Aurelia Gitter channel (https://gitter.im/Aurelia/Discuss). If you do so please also mention me on the channel so I can get updates. My nick is also francoishill on that.

[kollster]

I have just tried the skeleton-nav app - it also takes 20+ seconds in Edge.

[lares83]

I also checked skeleton-nav on Edge and having the same issue

[mastermaq]

Same issue here on Edge, takes forever to load the kit or the docs.

[EisenbergEffect]

This is multiple issues.

First, we have some issues with IE/Edge we are investigating. We aren't convinced they are entirely in our code, but we are looking into it.

Second, now that we are in beta, we are looking deeply into performance. There are many aspects of performance. We had our first major perf upgrade this last week. You can read about it here: http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/ It wasn't related to initial render time though. We are specifically looking at improvements related to render time as well.

[tuath]

Yep, having the same slowness on Edge. Everything is bundled and cached locally so that's not it. Latest version of the beta files...

I suspect something in system.js... when I profile on edge I see a lot of "timers" and a long time between each plugin initialisation.

Hope this is fixed soon !

[EisenbergEffect]

We have discovered a two things that are related:

• IE/Edge DOM rendering is 3-4x slower than every major browser. It's way, way behind everything else. It looks like Microsoft has spent a lot of time optimizing the JS engine, but almost no time working on DOM rendering.
• Something appears to be going on with system.js. We don't know what just yet but we are actively looking into it right now.

[tuath]

Rob - did you guys do something to aurelia.io/docs.html ? it loads as fast a chrome on edge since this morning...

[EisenbergEffect]

Yes, we did. That release includes some general perf improvements, but @jdanyow also looked into Edge specifically and he discovered that Edge's Promise implementation is ridiculously slow....I mean unbelievable. So, we dropped in Bluebird to replace the Promise implementation and that fixed it.

That said, @tuath are you able to load the docs on Edge without the developer tools open? For me, it only works with the dev tools open. I'd like to know if you can confirm one way or the other.

[EisenbergEffect]

FYI We'll have a blog post today with details on the perf work including the Edge stats and fix info.

[tuath]

@Rob, it works fine for me with developer tools closed. I eemailed you perso 2-3 weeks ago, and you just fixed the slowness I was referring to... also that intermittent bug I had at the time, maybe that was the developer tools bug I was running into ! good job, can't wait to "update" to the latest version !

[dpinart]

I still need to have developer tools open in edge in order to load the docs page can't believe it :( Performance is good but it was good too for me previously

[tuath]

@dpinart, what version of windows (edge) are you using ? I am on 10586 which is the latest

[rob]

No problem @tuath!

[EisenbergEffect]

@dpinart We are still looking into this. As you might imagine...a problem that goes away when the dev tools is open...is a little tricky to track down. I'd like to figure out what is different with @tuath 's Edge instance.

[dpinart]

@EisenbergEffect Sure. I understand your point and right not we don't have any customer pushing to view any app in Edge. I'm reallys surprised that the developer tools are so powerful that they can arrange apps :lol
@tuath I'm on Microsoft Edge 25.10586.0.0. So I guess is same than yours

[tuath]

let me know if there is anything i can do...

[tuath]

well, I just rebooted and as soon as I open the doc site with edge, it did not load correctly till I opened the dev tools, I guess I just hadn't rebooted in a looooong time.

[EisenbergEffect]

It behaves erratically from what we can tell, depending on a number of variables. There may be a race condition somewhere. We're working on it...stay tuned.

[CasiOo]

Yes it feels very much like a race condition. Keep refreshing the page, and eventually it will load correctly.

It always seems to load correctly in our own application at work. Neither have we noticed any of the long load times that have been mentioned in this issue. Our app. always starts at the login screen with not a lot of bindings, if that could be of any help at all.

[EisenbergEffect]

Here's one thing I'm curious of. @CasiOo Are you using our http-client or our fetch0client (or neither)? Also, are you using bluebird?

For those of you who do have apps working fine in Edge. I'd love to know your answers to the above.

[CasiOo]

We are using neither. Instead we're using the ajax part of jquery (I don't remember the reasoning behind it).
Our services are using bluebird, because we needed the finally part. We aren't creating any native promises at the login page, but we do at later stages in our app.

Feel free to contact me on gitter, if you have any more quick questions

[tuath]

@EisenbergEffect I am just going with Aurelia-fetch-client. no bluebird

[EisenbergEffect]

I'm wondering if it's a conflict between our http-client and bluebird...

[gheoan]

I have an app working fine in Edge. Im using native fetch with polyfill, no http-client, no fetch-client, no bluebird.

[lares83]

@dpinart, @EisenbergEffect I have the same issue on my Edge browser (ver 10586 ). Docks page is not being loaded until I open DevTools

[genadis]

@EisenbergEffect I'm working on app without http-client & without bluebird for now, takes very long time to load on Microsoft Edge 25.10586.0.0 with or without dev tools open. Loads same time with or without dev tools open.

If not bundled takes over a minute, when bundled takes about 20 seconds.
The resources are loaded serially one after another, and with pauses between them so the difference between bundled and non bundled makes sense.

hope it helps...

[EisenbergEffect]

@genadis If you are targeting edge, you need to try out Bluebird. That will likely solve your perf problem. It might introduce the load issue above though. We are trying to find out the source of that still.

[SamDeBlock]

After the last update the docs now open (almost instantly, nice!) in Edge without dev tools open.
I'm running 20.10240.16384.0, before the update the docs would only load with dev tools.

[Aniel]

Docs don't load (Edge: 25.10586.0.0) without dev tools.
After first load with dev tools it works without.
If i clear the cache and try loading again without the dev tools it doesn't work again.
So if dev tools are open a file gets downloaded and cached that is causing the issue when dev tools are not open.

[SamDeBlock]

@Aniel You are correct. Just tried this with 20.10240.16384.0.
New InPrivate window, dev tools closed: docs open

New InPrivate window, dev tools open: docs open
Close dev tools, F5 to refresh and docs don't load anymore

[csrow]

For those who can load the docs without dev tools open, try clearing the cache and then try again.
In my case, after the clean cache requires dev tools to be open. Afterwards, docs open fine without the dev tools.
Edge 10586.0.0

---

Chi Sung Row

Date: Fri, 18 Dec 2015 00:23:00 -0800
From: [email protected]
To: [email protected]
Subject: Re: [framework] Aurelia takes 7+ seconds to load on Moto E/Android/Chrome on miniscule bundled project (the yeoman aurelia skeleton) (#254)

After the last update the docs now open (almost instantly, nice!) in Edge without dev tools open.

I'm running 20.10240.16384.0, before the update the docs would only load with dev tools.

—
Reply to this email directly or view it on GitHub.

[genadis]

@EisenbergEffect following my previous post.
I've integrated Bluebird, it reduced the load time on Edge by half (~10 sec, on Chrome it's 2-3 seconds).
Still loading regardless of dev tools open or closed, even after clearing cache and data.

Tested the Aurelia docs as well, it loads on Edge in about 6 seconds, regardless of dev tools open or closed, even after clearing cache and data.
It did got frozen without dev tools open a few times but loads when refreshing the page, after first load it always loads.

[opcodewriter]

I confirm the erratic behavior in Edge. sometimes it works, sometimes it doesn't

[opcodewriter]

@ohjames how's the loading time these days on the mobile?

[insidewhy]

@mikefills still not good, currently spending my time defeating more pressing bugs involving repeat+animator.

[jdanyow]

@ohjames can this be closed? I think bundling, bluebird and the recent removal of core-js have fixed the perf issues.

[insidewhy]

@jdanyow The load times are much better in the latest release I'll close it. Now rather than the spinner spinning for 8+ seconds it spins for less than a second.

After this the browser freezes for about 1-2 seconds which is still pretty high and probably enough to turn people off :( I assume it's compiling all the bundled js files in one go. I think the only way to work around that would be via code splitting/lazy loaded chunks as webpack does (check out this article)

[opcodewriter]

@ohjames I am also interested about webpack. I don't know what's the aurelia-webpack status now.
If you have a conclusion, would you mind commenting back here please.

Here's some conversation from chat room about wepback, which you might find useful:

The1nternet
Mar 04 19:13
would webpack be replacing jspm? or aurelia-bundler? it seems like webpack more performs what aurelia-bundler does, rather than what jspm does.

EisenbergEffect
Mar 04 19:14
Nothing is replacing. We are just adding another option.

mikefills
Mar 04 19:15
will webpack code splitting work with Aurelia? e.g. require.ensure

sylvain-hamel
Mar 04 19:15
@EisenbergEffect @The1nternet but you'd use one or the other, not both together, right?

EisenbergEffect
Mar 04 19:16
correct

michaelprescott
Mar 04 19:16
@mikefills I played with webpack a while ago, but not enough to fully understand code splitting. How is it better than defining how to bundle parts of Aurelia using their bundle task?

EisenbergEffect
Mar 04 19:17
With webpack you use NPM to install aurelia. Then we have a webpack loader and bootstrapper that gets it all working with webpack.

mikefills
Mar 04 19:23
I was reading the Aurelia docs on bundling and I saw this:
"inject: If set to true, this will inject the bundle in config.js, so whenever the application needs a file within that bundle, the loader will load the entire bundle the first time. This is how we can achieve lazy bundle loading. For a large app with multiple sub sections, this will help us avoid loading everything upfront."
it's not clear to me how it compares to webpack's code splitting

EisenbergEffect
Mar 04 19:24
I think it's basically the same thing.
With system.js you can tell it that your es2015 modules are grouped into bundles.
Then, when any module is requested, it makes sure to load the bundle first (only once) before loading the module.

mikefills
Mar 04 19:25
but I need to define the bundles by config right?

EisenbergEffect
Mar 04 19:25
So, you can build your app with es2015 modules, not really worrying about how it will be bundled. Then, at a later time, you can configure the optimal set of bundles for deploy.
In the bundle config, you can set up the bundles.
That's what the bundle config does.
It defines how your modules are grouped into bundles.
You could have it all in one bundle, or split it into any number of bundles you want.

[EisenbergEffect]

Yes, you can do it today with our bundler. For example, the Aurelia docs are deployed as two bundles: one with the framework and all 3rd party libraries and one with the app code. You can do whatever you want. For example, common bundling strategies are based on bundling features or based on user role.

[opcodewriter]

Thank you Rob.
For less experienced people like me, a concrete example would very useful. Unfortunately source code for Aurelia docs app as far as I understand it's not available anymore.

[EisenbergEffect]

The very first example in our article on bundling shows how to deploy an app split into two bundles: http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.1.4/doc/article/bundling-your-app-for-deploy/3

Notice how the bundles section has two entries: "dist/app-build" and "dist/vendor-build" Globs are used to tell the bundler which modules go in which bundle. You can have as many bundles as you want.

[EisenbergEffect]

Although...I see that some of that config is out of date. It's referencing github for aurelia libs. That's not right. @ahmedshuhel We need to get the bundle docs updated ASAP. They have been showing the wrong thing since November...

[alvarezmario]

@mikefills one very nice thing about bundles is that they load on demand. If you set up your bundles correctly, you won't need to load the whole app on page load.
Imagine you have a big app, which contains frotnend and backend. If you set up things correctly, on page load you'll be able to load only the frontend bundle, then if you go somewhere backend code is used, that code is loaded on demand.. That's really cool.

[insidewhy]

I've used jspm bundles a lot but the way webpack handles bundles is superior as it calculates the optimal bundles by scanning the code for dynamic and static imports calculating the minimum number of chunked bundles necessary. To do this manually can be untenable for huge projects.

I'm not really a fan of webpack but this one feature is indispensable for large projects.

[EisenbergEffect]

It's not really hard with aurelia's bundler, you simply supply globs to tell it what should be in the different bundles. If you organize your app by features or by user scenarios, then that makes it even easier.

[insidewhy]

It isn't hard in simple apps but when you have many external dependencies per each of your code modules then calculating the optimal bundles becomes much less simple. In huge apps making a mega bundle of third party dependencies such as in the Aurelian skeleton app will lead to a very suboptimal user experience while they wait for that huge bundle to compile. With webpack these are non-issues.

[insidewhy]

@rosenfeld and me recently had a discussion where I was arguing that jspm's approach was good enough but he won me over with some very convincing arguments, he has some great blog articles on how to optimise page load times.

[rosenfeld]

I believe you are discussing different subjects. I employ both techniques in the application I maintain but they are not necessarily related to each other. The technique described by @EisenbergEffect is commonly referred to as creating separate bundles, like vendor and app, both of which must be loaded for the application to load. This is handled in webpack by the CommonsChunkPlugin.

Even though it's also explained in the code-splitting section of webpack documentation, the lazy code loading technique described by @ohjames is another feature related to code-splitting, but a completely different one from creating a vendor bundle. They can be combined (which I recommend) but this is not required.

Lazy code loading is the hardest part to implement transparently, like webpack does, but it allows you to load only the code you need for the initial rendering of the page and then download more code as you need. By doing so you can speed up the page loading by reducing the size of your initial JS.

Webpack is smart enough to understand which modules are already available in the initial load as it assumes both the commons chunk and the app chunk will be loaded upon initialization. So if some part of the code will call require(['lazy-module', 'another-one'], function(){...}) webpack understands that it should pack those modules and their dependencies and exclude any modules which are already part of the commons and app bundles. This is a very powerful and interesting feature I only found in webpack so far...

[EisenbergEffect]

The bundles created using system.builder or the aurelia bundler do not have to be loaded up front. They can be loaded on demand. SystemJS knows what modules reside in which bundles. As a result, it only downloads the bundle when a module that resides inside that bundle is needed. It does not download it otherwise. This is basically the same capability as you are describing with Webpack. What it doesn't do is automatically determine how to break your app up into these different downloadable bundles. For that, you have to tell it what modules should go in which bundle. You can use globs so it's easy to define. We could add something in the future to have the aurelia bundler try to automatically determine an optimal deploy...but in reality the developer usually knows best because they understand the actual usage patterns of the application.

[dpinart]

I haven't tried webpack yet, if it works as fine as @rosenfeld and @ohjames I'll have to consider its usage. I'm implementing lazy load via aurelia bundles, I do have a bundle that contains minimal stuff to show a login screen to the user. Meanwhile user is logging in I'm importing some module contained in the following bundle to load (inspecting the url I can know which view user is navigating to once he logs in) so I can start the bundle download. App has just 3 bundles, It took me a while configuring the bundles (via Globs and excludes) but it wasn't a nightmare.

[rosenfeld]

@EisenbergEffect I'd love to better understand how this works since I'm interested in webpack alternatives which would support persistent caching so that it could be useful for incremental builds to speed up the deploy process.

Suppose you want to generate 3 bundles, Vendor, App and OnDemand. Suppose both Vendor, App and OnDemand depend on jQuery. How does SystemJS know that Vendor and App should be considered to be loaded upon initialization so that it only includes jQuery in Vendor and not in App and OnDemand? Also, what if both App and OnDemand depend on Common module? How would SystemJS know that Common should be included only in the App module?

[EisenbergEffect]

Basically, you tell it what goes into each bundle. Then it generates a manifest of the bundle contents so it knows what is where. Whenever jQuery is request is simply ensures that the bundle that contains jQuery gets loaded.

[rosenfeld]

@EisenbergEffect, if I understood it correctly, you basically tell the build system that modules in the Vendor bundle shouldn't be included in the App bundle and that neither Vendor, App and their dependencies should be included in the Common bundle and the build system is able to manage this correctly to remove any duplicates, is that correct? For example, if all bundles require jQuery neither App nor Common bundles would include it because they were told not to include Vendor or any of their dependencies and jQuery is one of them.

What is the exact tool that manages this? SystemJS? jspm?

This is certainly manageable, although not as much transparent and convenient as the webpack approach... Anyway, if it supports incremental build persistent caching I'd certainly consider it as an alternative to my current build system. Does it support persistent caching for incremental builds?

Could you provide an example showing how Vendor, App and Common would be configured using your solution?

[rosenfeld]

Also, how do you manage the lazy load behavior? Does that system already provide you the required tools to ask for the module and run a callback once it's loaded? Or do you have to manage this part with your own custom code?

[dpinart]

For each bundle there's an entry in the config file that lists the modules contained. Whenever app imports a module SystemJS knows if it's included in a bundle, if so SystemJS first downloads the bundle before resolving the import, bundles are only download once. A bundle is not downloaded until threre's an import asking for a module contained in.

[rosenfeld]

@dpinart, I'll take your words to build a pseudo example.

"For each bundle there's an entry in the config file that lists the modules contained."

Here's the config:

var config = {
  entries: {
    Vendor: ['jquery', 'knockout'],
    App: ['./app.js'], // app.js requires jquery and ./common.js
    OnDemand: ['./on-demand.js'] // on-demand.js requires jquery and ./common.js
  }
}

How do you tell the config that all dependencies (and their dependencies) included in Vendor should not be part of the App bundle and that all dependencies from App (including the ones bundled in Vendor) should not be part of the OnDemand bundle? You haven't explained that part.

How does SystemJS downloads missing bundles? Is this implemented by SystemJS itself when generating the bundles, transparently?

Also, how does SystemJS know that both Vendor and App have been included in the head section? For example, suppose you include two async script tags in the head, one for App and another for Vendor and suppose Vendor is much bigger than App so that App would usually be downloaded first for the first access (no cache). Since App depends on Vendor, how would SystemJS know that Vendor is already being downloaded and wait for it to finish rather than requesting the vendor bundle again and then prevent it to be downloaded and executed twice?

[AshleyGrant]

The Aurelia bundler is built upon the SystemJS Builder. The Aurelia Bundler Documentation is currently here: http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.1.4/doc/article/bundling-your-app-for-deploy. It lays out the answers to all of your configuration questions.

When the SystemJS Builder builds up the bundles (based upon the configuration passed to it by the Aurelia Bundler tooling), it writes out, in the app's config.js file, a list of exactly what files are contained within each bundle. SystemJS reads this configuration information at runtime. Using this information, it would know, for example, that app.js is included in the App bundle.

how does SystemJS know that both Vendor and App have been included in the head section?

That's not how the bundler works. You do not include script tags for any of the bundles. You rely on the module loader to load the bundles on demand.

[dpinart]

@rosenfeld You have to be aware to avoid modules being duplicated. Aurelia bundler does not warrants this point. This task is a bit tedious and it requires some time. I ended watching in the debugger what modules were being downloaded in order to show the login view and I set up the "login" bundle with these modules. Then I built the "app" bundle excluding all the modules that were present in "login" bundle and finally I built the third bundle 'app-ext'... At least for me, it was a bit tedious and manually task, although it wasn't a nightmare.

The advantage I can see in webpack is that it automatically ensures a module is not present in more than a bundle. I don't know how you configure different bundles...

[rosenfeld]

Hi @dpinart, this is what I was trying to understand.

I've detailed how I use webpack to create two bundles (vendor and app) and load them async and how to load more code lazily in this article:

http://rosenfeld.herokuapp.com/en/articles/2016-02-29-getting-an-spa-to-load-the-fastest-possible-way-and-how-webpack-can-help-you

Webpack consider each chunk in an special way. Take a look at "Chunk types" in its documentation to understand them:

https://webpack.github.io/docs/code-splitting.html

There is the entry chunk, an initial chunk (non-entry) which is achieved using the CommonsChunkPlugin (like the vendor chunk) and normal chunks which are loaded on demand.

You only specify the entry chunks and you can use the CommonsChunkPlugin to create initial non-entry chunks. The normal chunks are created automatically by webpack by looking at the async requires and bundling together everything which is not included in the initial chunks (entry or not). You can optionally provide a name for this async require so that you would be able to include other modules as well in other places by giving the same name.

I'm not sure if that plugin would support more than one initial chunk besides the entry chunk. You can look at more details about the plugin here:

https://webpack.github.io/docs/list-of-plugins.html#commonschunkplugin

There's a downside though that webpack assumes you will ensure the commons chunks (Vendor) will be executed before the entry chunk (App). That means you can't load them asynchronously, so I had to add some custom logic to the chunks to be able to handle them async and I also had to create a small plugin to change the initial chunk a little bit, which is demonstrated in the referred article in case you are curious. It would be awesome if webpack allowed you to inform that those chunks will be loaded async so that it could handle that itself when generating the chunks...

Now, if you were asking about multiple entry points, then webpack supports that pretty well.

[MaximBalaganskiy]

@rosenfeld Could you please give more details on how to separate aurelia and app code into two bundles? I'm having an exception when try to do that, although one bundle app works fine. I managed to trace it to an undefined Element injection. I feel that it has something to do with in which bundle aurelia-pal-browser is located but couldn't get to the bottom of it.

[rosenfeld]

Hi @MaximBalaganskiy, I don't actually use Aurelia myself. I was brought to this discussion by someone while we were discussing some performance issues related to the build tool and just contributed to this specific subject. I can't give you details on how that applies to an aurelia application. In my application I bundle all libraries in a vendor JS and the application code in another JS. I also load some code on demand. But I don't know much of Aurelia to help you understanding how you can split your application and help you debugging any issues, sorry.

[insidewhy]

Using the latest Aurelia with a jspm configuration, the loading spinner is still shown for 3 seconds even on a Samsung Galaxy S6. It's too much :( Could switching to webpack help this?

Site is at http://kchomp.co and code is fully bundled. The only non-aurelia deps I'm using are lodash and blbuebird.

[EisenbergEffect]

Just try not using system.js for starters.

[insidewhy]

@EisenbergEffect I was under the impression that jspm needed system.js. I imagined that system.js' job just became much smaller for a bundled app. I'd have no idea how to remove system.js without also removing jspm. Do you think this slowdown is called by system.js then?

[EisenbergEffect]

Neither one really needs the other, it's just more convenient to use them together. You could use npm instead of jspm for packages and still use system.js or you could use npm with require.js or npm with webpack.

[insidewhy]

Thanks, I will assume this is an issue with system.js for now then and port to webpack. Will reopen if it doesn't help or open a bug against system.js if it does. I loved system.js as a concept but this much load time is obviously not good enough, I can only assume from your switch to webpack that you guys have also found systemjs to be inadequate.

[EisenbergEffect]

We are moving to provide multiple alternatives to system.js. We've also discovered that Babel generates code that creates runtime checks in class constructors. We're working on removing that, which should improve startup time as well (and reduce size a bit more). Performance is an ongoing project for us and we're always investigating different options. After our v1 release, we'll also begin work on server-render too.

[insidewhy]

Thanks, you're the man. Our team really appreciates all of the advice and help you've given and have had a great time building with Aurelia! We'll committing some more work back besides my animator fixes soon :)

[insidewhy]

A member of my team has determined that 75% of the time delay is due to system.js, so Aurelia is off the hook. <3 aurelia.

[dpinart]

We moved to webpack a couple of months ago and we could observe a significative startup time improvement. Anyway, on mobile devices (android 5.1 +) startup time is annoyingly long, about 15/20 seconds. Even deploying the app within an apache cordova application results in very long startup times. It seems the bottleneck is at aurelia plugins/feature initialization (main.js). Once app is launched performance is quite acceptable. There's no significative difference amongst webpack or systemjs on mobile devices

[gheoan]

@dpinart Is that for bundled applications?

[AshleyGrant]

I tested the Aurelia docs app today on my phone (Nexus 6p) It loads in 2-3 seconds.

[ACT1GMR]

Hi that's the case for me already
Im using aurelia enhance feature that helps me to extend my server side template engine and use aurelia just for interactive components that's great and appreciable.
check out my website here (language is Persian):
http://otex.ir
really it works like a monster on desktop browsers and take too long for startup on android + windows phone (about 5-10 sec) vice versa it's weird that on Iphone everything works fast and smoothly that's weird for me because safari is also contains a webkit engine what's the big deal between android and IOS?
have to mentioned that site is bundled and I'm using systemjs + jspm + js + aurelia and systemjs latest builds

[insidewhy]

My team member was wrong to lay the blame on system.js... this startup time is still such a big problem for us that we have to port to angular 2.

[insidewhy]

Ah it seems like this is a duplicate of #136.

[EisenbergEffect]

@ohjames I'm not sure that is going to solve any problem for you. In the videos I've seen, the ng2 startup time is actually longer than Aurelia. I'd love to help you with this but we haven't experienced any severe issues. There are usually many ways to handle these types of problems if you encounter them but it does depend on the details of your app.

[insidewhy]

I'd love to help you with this but we haven't experienced any severe issues.

If I reload the majority of the websites linked from http://builtwithaurelia.com then I get 3+ seconds of loading on every reload. I've switched phones recently (to a comparatively much more powerful Xiaomi Redmi Note 2) so it rules out my previous phone being the issue. Am stuck on Android 5.1 though, but using the latest Chrome.

There are a few examples linked that do load within a second after the first reload though, I'd really like to know what is different about those.

There's only about 10 or so links to go through on that website, it wouldn't take long to verify the long load. One notable example is the "North winds".

[Thanood]

Northwind takes like 6 seconds to load on my Galaxy S6 and around 5 seconds in my PC.
The longest "wait times" are loading something from the breeze controller, though. Especially "Metadata" which takes nearly a second.

There seems to by a relatively huge gap (around 1 second) between loading google analytics and index.js.

That being said, I think it uses SystemJS. That's kinda slow if not everything is bundled (at least materialize and views is not).

JavaScriptKicks loads instantly.

http://kchomp.co/ takes around 3.5 seconds with a 2 second gap between bluebird.js and app.js.

@ohjames

My team member was wrong to lay the blame on system.js...

Would you mind to share any details on this conclusion? As far as I know, SystemJS uses a promise-based approach which essentially means there's overhead (waiting for resolves). With a lot of files, this is a lot of overhead.

[insidewhy]

I suspect the issue is with systemjs being slow after doing some of my own analysis, although I doubt its use of promises are exclusively to blame.

I just upgraded to the latest aurelia-bundler and now kchomp.co takes a lot longer to load on mobile. Oh no ;)

[insidewhy]

SystemJS is just super slow even when bundled, I've hacked the loader a little and made it much faster. My approach isn't suitable for a PR though.

[MaximBalaganskiy]

SystemJS is just super slow even when bundled

well, this is not what we see in our environment. While the web site is definitely slower on a mobile, on the desktop it's almost instantaneous.

[insidewhy]

well, this is not what we see in our environment

Every single aurelia website deployed with systemjs, bundled or otherwise, spends at least 3 seconds bootstrapping on mobile. Bet you can't find a single example to the contrary.

[insidewhy]

on the desktop it's almost instantaneous.

That's true, but this issue is all about mobile performance which is terrible due to systemjs.

[insidewhy]

After several hours porting the build system to webpack I've brought mobile load times down to less than a second with pretty much the same code as before.

[AshleyGrant]

@ohjames, I'm glad to hear Aurelia isn't the problem.

[insidewhy]

Well it's opened up a whole other can of worms (https://github.com/aurelia/loader-webpack/issues/24 !?) but at least I managed to hack the build enough and peg dependencies _just so_ that my build stopped throwing unhelpful error messages enough to work. The lack of documentation and bugs were a _huge source of pain_ though.