WebGL Browser Loading Time

When we attempt to load the game on our server using the default template we get:

Step 1 : Unresponsive black screen 3.5 minutes.

Step 2 : Unity logo and progress bar appear, quickly load, then disappear. 10 seconds.

Step 3: Unresponsive grey screen: 2 minutes.

Step 4: Error pop-up saying a script has become unresponsive, can either wait or abort , continue?

Step 5: pressing continue makes the game load instantly.

Total load time 5.10 minutes.


We've tested this on multiple devices and the total loading time seems to be proportional to cpu power, one of our faster machines manages the entire thing in 20 seconds, but slower laptops a few years old can take several minutes, in one test it took a full 9 minutes to complete. Our game is built with a view to include these slightly older specced machines which otherwise run it fine.

We're not talking about fossils either, Windows 7, 2.Ghz intel, 2gb RAM = 5 minute load.

We have all the recommended settings:
game is gZipped to < 3mb,
not dev build,
stripping byte code,
asking for minimum necessarily RAM (96mb)
Fastest(Slow build times) optimization.
using latest firefox and chrome.

Does anyone have any ideas what could be causing this and do our findings seem typical or exaggerated? We've heard about the long time it takes to parse all the java in the browser, which I've understood to be responsible for the second unresponsive freeze after the loading bar, but perhaps we have something else here contributing to the first unresponsive black screen that lasts even longer.

Thanks

 

I would watch the memory usage while you load the game. If windows starts paging, then that explains your slow loading time.

 

same issues here.
imo, the question most of us are asking is: are these loading time gonna improve over the next few updates of unity, or is this some limitation of the engine, and there's not much to do about it.
many thanks

 

WebGL loading time definitely is something that could use improvement.

 

I don't care about the long loading time as much as these irresponsive screens when you can't see anything going on, the progress bar has not showed up yet or has already disappeared. The progress bar itself should be made more reliable and indicate the real progress since the start of downloading the page.

 

Agreed, it would be nice if the browser could save a smidgen of resources for maintaining a progress bar or simple dynamic html changes rather than freezing up completely, users will rightly presume it has crashed. Whether or not that's even possible without knowing the capacity of the users machine I don't know, guessing it's not.

 

If anyone has already proven any of the following please share:

Are any of the following likely to improve JS parsing times?

1. Using compiler derivatives to remove unneeded platform specific code (or will stripping manage this)
2. Compressing textures
3. Compressing audio clips
4. Reducing model poly-count
5. instantiating elements of scenes at run-time rather than baking them into the scene in the editor
6. using c# over javascript
7. using many small methods/procedures rather than fewer long ones as suggested in another post.

many thanks

 

From my experience, the current WebGL builds are unusable. Too buggy and unstable for any kind of production project.

 

Thanks for the reply Jonas. Unfortunately if we ask for more than 128mb memory in the player settings, a significant portion of our users get "out of memory" crashes. It's interesting that you suggest raising this figure would improve parse times, this is the first time I heard that thanks - would be good to document it somewhere.

It's not all gloom on the "unresponsive" side of things for those of you interested - it's just the canvas (and anything in it like a loading bar) that freezes, we've got animated loading .gifs to play on top in html while it's frozen which are sufficient to keep the player from thinking it has crashed while we plead for his patience.

For anyone who's not considered it already there are probably ways to reduce your code size further:

protect any unneeded platform specific code with #if !UNITY_WEBGL, and delete unneeded .dll's from the plugins directory like prime31 app store libraries etc otherwise they get included even if they are not referenced. use .net subset and think about chopping up your code - any similar functions written explicitly more than once can be consolidated and called with varied input.

all these things clearly make a difference as an empty project loads in 20 seconds, while a code heavy one takes up to 5 minutes. I've still not been able to verify if compressing textures and other things makes much difference.

 

@cheesemaster I am coming from the other side...have only experimented with textures and file size. Yes, does make a difference on load time. I also noticed turning off Pre-Load shaders seemed to help, but that could be a coincidence. Really need to learn how to overlay the animated .gifs...that is a great solution for the meantime. Or a slideshow for instructions etc (our use is a design app for small tradeshow booths). I hope I master these bugs soon as I have a proposal on the line to use WebGL....or another non-plugin web solution.

 

Here is a question. Are there any plugins or alternate solutions for exporting web content from Unity? As in, is there an alternative to EmScripten? Grasping at straws, I know, but looking for any light at the end of the tunnel for using Unity to build stable cross browser web apps.