Build size questions

[Leander1P]

Hello;

We’re trying to keep ahead of WebGL build sizes on our project, both to address load times and to hopefully keep browser memory usage lower (outside WebGLMemorySize – we seem to be doing pretty well there so far). We have some fairly low-end devices and internet connections in our target market.

The build-report tool has been exceptionally useful: we’ve managed to evict Terrain (a single stray tree brought it in somehow) and CloudWebServices/UnityConnect (“Disable HW Statistics”). We’re also setting up AssetBundles, which is helping with the .data.unityweb sizes.

We’ve enabled compression and set up Content-Encoding – starting with gzip for native support in older browsers.

We also upgraded to 5.6.2f1 from 5.6.1f1, and while that shifted a few megabytes from the uncompressed+unminified development build .code.unityweb and into the .data.unityweb, it didn’t have much impact (about 100K larger) on the minified+gzipped .code and (about 10K larger) on the .data.

We have some questions, though, as we investigate:

• The initial “WebGL Roadmap” post ( WebGL Roadmap - Unity Engine - Unity Discussions ) mentions a “distribution size of 1.2 MB” via code stripping, compile settings, and removal: any details on how this was achieved? This is perhaps our single biggest question. =) Presumably emscriptenArgs might be useful here; we’re just beginning to investigate and try to understand the build process and steps. Currently we’re seeing empty projects from 5.6.2f1 at about 1.95MB of .code.unityweb (stripped and gzipped).
• How would we go about breaking down what’s causing “IL2CPP Generated” in build-report? We started to poke around the Temp folder and acquaint ourselves with intermediates/response-files, which looks promising, and there’s some hope of dumping a list of symbols from the unminified+uncompressed js, but any hints here would be helpful. Looks like even the empty project has 3MB reported here, we’re at 5MB.
• The “Practical WebGL Advice from the Field” video (
  https://www.youtube.com/watch?v=6-S-P7ekdBc
  ) and several forum posts mention evicting Physics by moving to custom raycast solution and dropping Colliders and similar. We’ve a pretty good idea how to go about this in our codebase, but before we dive in: can anyone point to some existing examples? Might help with implementation time to see what others have done.
• Anyone played with re-compressing the .unityweb files with Zopfli to get a few extra percent?
• Any other “recommended reading” or resources we may have missed? We’ve been digging around this forum, the docs (“Reducing the file size of your build” etc), and blogs (search “webgl”).

There are a few things rattling around our skulls that may be a little further into the future, as well:

• We’d love to understand a little more about js-side decompression versus browser-side. RewriteRule etc seem like they’d make it possible to serve either gzip or brotli (and indeed we had that up and running pre-.unityweb, if I recall correctly) based on browser Accept-Encoding, but it also seems like there’s a possible case where sending brotli even to browsers that don’t support it and having that decompressed in js might be a worthwhile trade-off (e.g. with a beefier CPU/memory, but worse net connection). There’s also clearly some interaction with CachedXMLHttpRequest and IndexedDB size. Anyone have any measurements here or made any interesting choices in this space?
• Relatedly, I wonder about separate WebAssembly versions for new enough browsers for an extra little kick; presumably this could be done in index.html per the Embedding API post ( New Unity WebGL Embedding API White Paper - Unity Engine - Unity Discussions ), somehow? We probably won’t go this route due to added QA burden, but it’s an interesting thought…

Thanks in advance for any feedback! We’ll make sure to come back to this thread with anything we find.

[Leander1P]

As an update, we’ve:

• Tried ZopFli. Only approximately a 40K impact on a ~3.4MiB gzip, so probably not worth the extra build complexity, but we’re not ruling it out.
• Evicted Physics. We’re using very basic ray vs sphere and sphere vs sphere to replace it, mostly. For our simple uses, it’s working relatively well.
• Done a few things to pull down RAM usage and CPU time in UnityLoader. Will possibly summarize these and ask some questions about them in a later separate post, but they’re very specific to our deployment case and not really relevant to this thread.

We’re still very much interested in bringing the build size down, still have more than a few open questions:

• To quote a colleague, “1.2MB… HOW!!!” – we’d still be greatly interested in any details on what was done to achieve “a distribution size of 1.2 MB” per WebGL Roadmap - Unity Engine - Unity Discussions . We’re continuing to investigate the general categories mentioned in the post, but anything folks at Unity can provide might help expedite that.
• Still trying to figure out how to break down what goes into IL2CPP Generated, and figure out if we have any control over that.
• As before, would love any recommended reading / RTFM suggestions =)

If anyone has time to drop any general build size breadcrumbs in here, it’d be greatly appreciated! It’s evidently possible to burn quite a bit of time heading down blind alleys and such, iterating on this with an incomplete understanding of the implementation.

[Marco-Trivellato]

@Leander1P

• To quote a colleague, “1.2MB… HOW!!!” – we’d still be greatly interested in any details on what was done to achieve “a distribution size of 1.2 MB” per https://forum.unity3d.com/threads/webgl-roadmap.334408/ . We’re continuing to investigate the general categories mentioned in the post, but anything folks at Unity can provide might help expedite that.

that post also says “this value is somewhat theoretical” Hackweek is usually one week long and to be able to prove an idea/solution, it’s quite common to take shortcuts. Then, if it makes sense, we take what we learned and work on a proper solution that we are going to ship in the end-product.
As of today, the smallest build size is about 2.5mb if I remember correctly. Having said that, as we continue to modularize the engine we might be able to improve that further.

[Marco-Trivellato]

Still trying to figure out how to break down what goes into IL2CPP Generated, and figure out if we have any control over that.

We are actually working on improving the build report to show a breakdown of il2cpp generated code sizes

You will be able to try that in a future Beta.

[chris1P]

@Marco-Trivellato

that post also says “this value is somewhat theoretical” Hackweek is usually one week long and to be able to prove an idea/solution, it’s quite common to take shortcuts. Then, if it makes sense, we take what we learned and work on a proper solution that we are going to ship in the end-product.
As of today, the smallest build size is about 2.5mb if I remember correctly. Having said that, as we continue to modularize the engine we might be able to improve that further.

Since the Javascript is highly compressible the difference between a 1.2MB and 2.5MB build is still very significant (maybe about 5MB of uncompressed Javascript?). We understand that the Hackweek work is theoretical. What we want to know is if we can take any of the same shortcuts, even in theory.

[Marco-Trivellato]

@chris1P

Since the Javascript is highly compressible the difference between a 1.2MB and 2.5MB build is still very significant (maybe about 5MB of uncompressed Javascript?). We understand that the Hackweek work is theoretical. What we want to know is if we can take any of the same shortcuts, even in theory.

2.5MB is already compressed.