Yesterday, engineers from Google, Microsoft and Mozilla (makers of Chrome, Edge and Firefox) announced that they are working on a new cross-browser technology called WebAssembly. This is very exciting news, as this will greatly help improve the Unity WebGL experience.

Although it is technically defined as a new, independent standard, from our perspective, WebAssembly is essentially a bytecode format for the asm.js JavaScript subset (asm.js is used to deploy Unity code to WebGL). Compared to the currently used text-based representation, the bytecode format is significantly reducing the size footprint of code compiled to asm.js. This leads to faster downloads of code, and, more importantly, to being able to parse and compile the code much faster and using much less memory. This will improve the startup times of large compiled JavaScript codebases, and reduce their memory requirements — both of which are currently some of the more common issues developers face when targeting the WebGL platform.

We plan to switch Unity WebGL to output WebAssembly bytecode once the feature becomes available in browser releases. On browsers which don’t natively support the feature, the bytecode can very efficiently be translated to text-based asm.js code using JavaScript – which in most cases still results in faster content load times due to the download time improvements.

Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x. Actual results may change based on the project used, but we expect to see very relevant improvements to anyone caring about WebGL deployment in Unity.

For more information on WebAssembly, see the FAQ here.

In light of this announcement, we would like to give further updates on the current status of our WebGL efforts, and on ecosystem changes we expect to happen over the next year — and on things we plan to be working on, which includes further build size improvements, SIMD.js, Shared Array Buffers (which bring threading support to JavaScript) and WebGL 2.0. So, I’d like to invite you to check out and discuss our WebGL Roadmap forum post, which has a lot of additional information.

If you are at Unite Europe in Amsterdam next week, check out my WebGL talk on Wednesday, or visit me at the hands-on labs to ask questions.