Chrome / Firefox HTML elements unresponsive while loading and initializing.

Hello.

I've been trying to replace existing Three.js content and port it to Unity.
The main problem I ran into however is that while loading and initializing the gameInstance, the elements on the page get unresponsive. For instance if there is a slider, there are 2 major lags where you can not interact with the UI for 1-3 seconds, which feels kind of bad as a user because you don't know whats going on. Even gifs stop playing during that time.

One option would be to put a button on the page that triggers it all so you have a "reason" for the unresponsiveness (click->load), but since this content should be loaded with the page I'd like to avoid that at all cost.

I tried using "noInitialRun": true and trigger callMain from a button like suggested here on the forum to smooth load before executing, but it turned out there is one lag while loading and another one right after gameInstance.Module['callMain'](); is called. With Chrome it is 10x more noticeable than Firefox even when using Canary.

WASM is doing slightly better than ASM on loading times but its no real difference in responsiveness. Gzip compression is enabled and working.

Is there any way around this unresponsiveness?

Thanks in advance,
Gwendolin

 

Welcome to my world

This has been our ongoing struggle with Unity WebGL since it's release.

We have found recently that WASM compilation times (which Chrome still can't truly handle without causing major page stall) vary for our project anywhere from 5 to 60s depending on the player's machine. Even if download times - due to our optimizations to reduce build file sizes - are a fraction of that.

There is no effective way to show progress if the progress indicator halts for >10s because the project is compiling.

 

We just fake it. So for us our binary is just code and the art assets are split across 100 or so asset bundles. The first half of the loading bar is completely fake. We increase the loading bar based on time (and the longer it's been the smaller the interval we increase the loading bar by). When the binary is finally fully loaded we "jump" to the midpoint and then increase the bar by the number of asset bundles you've finished downloaded divided by the number of total asset bundles.

Not perfect obviously, but works well in practice.

 

We fake it as well but since the actual page rendering halts, the fake "progress" halts as well. As do animated GIFs and buffered videos. We've tried just about everything to indicate progress while the page 'halts'.

This is *just* the binary build; our assetbundles are loaded separately once the unity engine is instantiated (another slight halt).

 

I'm not sure what the "web people" do exactly or if the stall for us is so small that it's not noticeable, but doesn't seem to be a problem. How big your binary? Ours is 3.3mb (gzip'ed).

 

Hi guys, thanks for the replies.

I ran some additional tests too. I tried with a minimal build that has about 3.10mb gzipped and got the following stall seconds overall:
Firefox 1-2 sec
Canary 3-4 sec
Chrome 4-5 sec

What I noticed is that Firefox does not seem to have pre-initializing ui stalling when using noInitialRun while Chrome and Chrome Canary have a significant stall before and after. To me the Firefox stall time seems ok, but the Chrome loadup feels like begging for users to leave the site, its a very noticeable time of non interaction.

I guess it highly depends on what kind of content it is used for. If the WebGL content is the hero object of the site I think I could live even with the Chrome times if nessecary, but as a side attraction on a page its hard to justify causing 4-5 seconds of stalling to the rest of the page.
And that is on decent hardware, the 60 seconds reported by sirrus on lower end devices fighten me a little to be honest.

Unfortunately my web-/emscriptenfu is not too strong. But I'd really love to know what exactly is blocking it, and if it would be theoretically possible to split the loading up into smaller chunks, and if that could even help in eliminating it. It feels odd to me that it would stall that much on such a small amount of data.

 

The swath of compilation times shocked us. @GwendolinFrost, your 'stall' times match up with ours on local, decent machines so we were dismayed to see such longer times in production. With that said, in our case I'm hoping the actual stall is still a fraction of the overall compilation time but we are still confirming that. But anything over 5s is a major bail point.

Our code binary is about 3.5MB (the data adds another 1.6MB). WASM, brotli compressed.

 

Ours is 2.5mb with brotli compression, a decent amount less to parse and load. Is there anything you can strip (physics)? That'll give you the biggest reduction with respect to stalling.

 

The largest components of our build are a loading screen texture, scripts and 1 or 2 plugins (that are still extremely small and necessary). We aren't using physics and have stripped out pretty much everything else.

 

I suspect it's the plugins that are sinking you. 1MB of highly compressed code for plug-ins is...a lot.

 

Marco, we use the Unity Build Report and another Build Report tool from the Asset Store. Both have slightly strange results.

We are using colliders and terrain so there are actually some physics modules being used. It also says we are using IMGUI but we're not using OnGUI anywhere in our code base.

Our other build report tool shows this:


Any idea why the Timeline DLL is included? We're not using it anywhere.

The SharpZipLib DLL is about 150kb but the other external plugins are very small and shouldnt be contributing much to build size.

 

Colliders = physx (all of physics) <---This is huge and your big bottleneck. Not saying you can work around this dependency, but if you can it will be a HUGE win.

IMGUI = using input (event system). I complained again at Unite about this (false) dependency. Unity said sooner rather than later. We'll see.

Also use the link that Marco provided, it's extremely useful and IMO essential for WebGL (and will show you just how big physics is...).

 

Yeah, I misspoke when I said "no physics" and the Unity tool shows a good breakdown of the modules that are used; none of which are feasible for us to remove at this point

Didnt mean to hijack this thread... hopefully some of this helps the OP as well.

 

I don't see it anywhere. Perhaps that's a bug in this other Build Report tool?