| HN Mirror

Unity has basically said that they will not be able to make a good WebGL export until something like web assembly exists. It's just not possible. The entire Unity game engine + your game code compiled to javascript is too much for browsers to load in any reasonable time frame if you have to use plain javascript.

https://forum.unity3d.com/threads/webgl-roadmap.334408/

Memory issues

One of the biggest issues we see people run into with Unity WebGL right now is browsers (especially Chrome) running out of memory on trying to run Unity WebGL content. There are separate issues here:

The need to allocate a continuous block of XXX MB of space for the WebGL content. This is the memory Unity will operate on. The size of this can be configured in the WebGL Player settings. This needs to be large enough to fit all the objects and assets Unity will have loaded at a specific point in time. You can use the Memory Profiler in Unity to debug how this space is being used. This needs to be a continuous block of memory in the browser’s heap. If the browser is low on memory, or it’s heap is fragmented, it may fail allocating such a block of memory. Browsers needing too much memory to parse the JavaScript. The JavaScript code emitted by Unity for a WebGL player build is several orders of magnitude larger than other common uses of JavaScript, and JavaScript VMs may require a lot of memory to parse all this code. In particular, Chrome’s V8 sometimes runs into issues with this, causing it to crash, because it cannot allocate enough memory to parse the code. In Firefox, this is not as much of an issue, as Firefox uses asm.js to AOT compile the JavaScript, which has a smaller memory overhead.

For a lot of use cases, this is currently the biggest show-stopping issue on WebGL, and it is not an easy one to fix. Right now, the best we can do on our side is to emit less code. We have been experimenting with this at our last HackWeek, where we had a project to see how far we can reduce the output size of our WebGL export. At the end of the week, we were able to build a simple Unity project to WebGL with a distribution size of 1.2 MB, by improving code stripping, improving compiler settings, and removing things we don’t need among other things. While this value is somewhat theoretical, as some of these improvements were made given assumptions we cannot make in general, we did learn a lot from this week, and I expect to see a lot of changes which benefit build output size to be rolled back into Unity starting with version 5.2. Also, we have build tools to visualize which code modules got included in the build, how much code was generated for those, and what caused them to be included. We plan to make these tools available in a future Unity release (5.3 at earliest), which should greatly help users to analyze and optimize their build output sizes. Reducing code output size also helps a lot with startup times, as it reduces the delay needed to parse the code.

But, ultimately, we expect that these memory issues will be helped much more by advances in browser technology. All browsers are moving towards 64-bit builds, which lets them use larger address spaces. And, more importantly, Mozillla, Google and Microsoft are working on a new technology called WebAssembly which packages asm.js code into a bytecode format, which can then be very efficiently be compiled into native code. We are pretty excited about this, as this will greatly reduce load times, memory overhead and distribution size of WebGL content.