I deployed successfully my application (assets + dummy wasm) on two IC canisters. I can access it with Safari and Firefox but, face an endless loop with Chromium based browsers aka “it does now work in Chrome, I cannot load my app”.
A so called /api/v2/status request is performed multiple times and seems to never resolve.
Any clue what’s the issue?
P.S.: Seems the error also consumes cycles
P.P.S: if loading succeed it takes ages to boot, aware of this, next issue to tackle
Can you show the console log? Perhaps we can figure out the error from there. I’ve had a similar issue where I forgot to define the interface in the .did file, and the js agent would complain that whateverCall was not a registered interface, or something along those lines.
Sure. There is one really brief error when accessing.
But when it redirects, no error in the console.
Same with Firefox for example is alright (like I said, takes ages but, it’s alright).
I got it to load in both firefox and chromium, on my box (ubuntu 20.04). It took 2.8 minutes in total, for 974 requests to complete. On firefox it loaded in 17.9 seconds, after 92 requests.
What I could see from the network panel is that some of the requests for p4324324324…entry.js hang sometimes (showing a pending state). My guess is that there’s something in the way chromium loads assets vs. firefox that causes this.
Seeing how the requests eventually go through I’d say it’s not inherently an IC problem. It could be a proxy problem (the ic0.app proxy), but I don’t think it’s a protocol problem. Can you try grouping the js files into a single one and see if that works? Or have fewer includes?
Thank you for the analysis and detailed answer!
It seems that the “next issue I want to tackle” is actually the root cause of the first issue 
.
I am actually not sure I can “group the files”. I use StencilJS which bundles the app using Rollup under the hood. It tries per default to bundle the smallest modules together resulting in multiple JS chunks (around 290 in my current case).
I’ll try to find an option to supercharge the grouping or see if the custom output bundles would also work in case of an app and not only for components.
As you noticed 974 requests on Chrome, I can also think there is an issue with preloading modules. To test the app on the simulated local network I had to find a workaround to force the preload of all modules (thread). This might not have a bad side effect in production with Chrome, which would to some extension make sense as I rather like not to force to preload everything.
Generally speaking, I also noticed that uploading many chunks to a canister is slow and costly. It seems to me, with my noob eyes, that the network except assets canisters to host only one or two (gigantic) JS files, which is kind of a bad practice to me. Small lazy loading modules’ chunk are more performant for modern browsers.
Summarized:
I’ll update the thread accordingly.
I did some tests, deployed some new versions and can conclude following:
preloading was not the root cause of the issue. in addition the workaround I had for the local network is not necessary for the ic prod
indeed reducing drastically the amount of chunks solve the issue. app can now boot in chrome within a couple of seconds.
I did not bundle everything in a single file, even though it would be possible, because for an app like mine with such an amount of features it would mean shipping a 5mb loading blocking JS, what makes absolutely no sense.
Therefore, for a quick test, I removed (npm rm ....) the design system (Ionic) and all my custom Web Components (around 30 libs) from the bundle and modified the app to fetch these from CDN (unpkg and jsdelivr) at runtime.
This indeed solve the issue but I am not fan of it, notably because doing so I loose all the advantages of the type safety provided by these libs and have to use external CDN instead of the assets hosting.
I will probably try to reimport the lib and then after build split the deployment of the JS files. I’ll try to deploy the main.js to the IC and all other bundles to a non blockchain static CDN, let’s see.
Being said, I don’t know if it is a proxy issue, as you said above, or a design issue but, it is really surprising to me that the IC does not handle, in terms of cost and performance, outcome of modern bundler which outputs multiple chunks such as Rollup.
I would be curious to know if it’s a issue, a feature, on the agenda or not on the agenda.
