Boost the Performance of Your WebGL Unity Games!

Hey, everyone, my name is Florin, and I'll talk today about boosting the performance of your WebGL Unity games. So a little bit about me. I'm a product engineer at Crazy Games, I'm also a game developer. You can see a couple of the games I created here. I mostly work with Unity, but I also do have some simple vanilla JS games.

At Crazy Games we're one of the biggest gaming platforms, we have more than 5000 games, we work with more than 700 developers and we also have 20 million of unique players. So yeah, let's start with the Unity web issues that you may encounter when building for the web. So there is the bundle size, it affects how fast your game loads, the memory usage, the RAM that basically your game uses when it runs, and the runtime performance. And why it's important to keep runtime memory usage low? Well, in the browser, Unity uses a memory heap to store the game data. And let's say you load a new scene, new textures need to be loaded, the browser may have to increase the heap size. And if a browser fails to allocate more memory to increase the heap size, you'll get this ugly popup that just crashes your game.

About the code performance, I won't talk about it here, so Oz already gave an excellent presentation about it, it's called Detect and Avoid Common Performance and Memory Issues in Unity WebGL and I encourage everyone to check it. About Brotli and jZip, these two are two different compression formats for the build in Unity. First of all, they don't ever launch uncompressed builds because they take around 11MB, the jZip, the default one, takes a little bit more space than the Brotli, so that's why we usually recommend the developers to pick the Brotli one, because you can see the difference, it may be quite small in an empty project, but when your game gets bigger, this difference will only get bigger. So yeah, usually stick with the Brotli one, although it takes a little bit more time to compress, but that's worth it.

About the exception support, so when you build a game for the web, you can pick the non-exception support, this is more performant, but you can't use try-catch anymore in your code. If you know that you have to use try-catch somewhere, pick the explicitly thrown exceptions only, which I think is also the default. And usually, you should avoid the full ones, except if you are debugging the game, because it will negatively affect the bundle size and performance of your game. I'd also like to talk about the texture compression format, which you can pick. Dext is the default one and this one is better for the desktop browsers. There is also ASTC that's better for mobile browsers and some Chromebooks. And if you pick the proper compression format, the textures don't have to be decompressed in memory and the game will use less runtime memory. You can see here in this small memory snapshot, we have a build with six textures, all of them quite big, and if they are decompressed in memory, they'll take around 75 megabytes. If they stay compressed, they take around 10 megabytes. So basically you managed to save around 65 megabytes of runtime memory, that's quite a lot on a mobile device. We tried to experiment this also with a couple of our games. Sadly, we only got some negligible load rate and load time improvements. And how we did it, we have two separate builds, and we either load the DXT one on all platforms or we smartly load this one to test on the necessary platform. And as we said, we didn't get any considerable improvements, but still, if you have, for example, a game that you launch only for mobile devices, consider to use this one, for example. Or you can check on Unity documentation how to load two separate builds, how we did with this experiment.

About the texture options. So pay attention at max size here, because you should keep this as low as possible on WebGL to reduce the final build size. If you reduce it, this will also reduce the texture size in the final build. You can also consider using crunch compression, it will help decrease also the bundle size, but it works only for these two texture compression formats, DXT and ATCM. It may take a little bit more time to build the game because the compression time will be increased, but the decompression is pretty fast when you start the game.

About the models, just in case you enabled this one, keep in mind that now the model needs to be kept in the runtime memory usage, so it's better to keep it disabled, I think by default it's also disabled. And also check if you can increase the mesh compression to high, for example, because you may have, let's say, a mountain in the distance that doesn't need to be high quality.

About the audio, if you pick compressed memory, that's usually good for background audio. It reduces the runtime memory usage, and background audios are usually some music loops that take quite a lot of memory. But this may reduce a little bit the latency and cause some imprecise audio play. Decompress and load, it's better for audio effects because you can keep them decompressed in memory. They usually don't take so much space, but they need to be precise when they're played. Also consider lowering the quality for background audio, because this may considerably reduce the audio size in the final build. Our optimization tool that you can grab on GitHub, or Unity Asset Store, and it also comes in our SDK, offers you all these tabs, they'll help you optimize your assets. It also offers build logs analyzers. For those who don't know, Unity usually generates a build log when you build a project, and it's an ugly, text-y file, log file, but this tool will beautify it a little bit and show you in a more readable way all the assets. And you can have a final look at all the assets that ended up in your final build. About Asset bundles and other symbols, consider using them because they help decrease the initial load size. How they work, they basically extract the textures, for example audio, some objects in a separate file that gets loaded only when it's needed. And you can do it with Asset Bundles which is low-level, you just fetch the file and extract the assets from it, but Unity now has an Addressables package that builds on top of Asset Bundles and it's much easier to use. You can see here an example of a game that uses Addressables and the initial build size for the build folder is around 17 megabytes. The StreamingAssets folder will be loaded later when needed, it's around 16 megabytes. So the developer managed to save around 16 megabytes from the initial game load.

I can't finish this presentation without talking a little bit about the integrated Profiler tool, which I think everyone should use to spot the performance issues and the memory issues. But for memory issues, if you want a little more detailed overview, there is a new package from Unity called Memory Profiler tool. It will help you capture snapshots of your running game, it can also connect directly to WebGL, and then it helps you analyze the textures for example of audio in the runtime memory.

That was all from my side, thank you for listening to it, and don't hesitate to check our documentation where we have more tips for Unity. And you can also contact us at developerrelations at crazygames.com. And we're looking forward to seeing your games on crazygames.com.