Why are the Levels (editor log) from build size so big 60.6% ?

Disable static batching as it combines static (not moving) GameObjects into big Meshes, and renders them in a faster way, and reduce draw calls drastically but increased build size. go to player settings and disable static batching ...

This question is old, but the answer might be relevant for people that have the same problem as I find it to persist in 2020.3. It applies to games where you have scenes where you build your levels with prefabs.

First of all: @umairh_91 is completely right. Static batching does indeed bloat level sizes and if you want to keep your build size under 100mb, you will need to write a solution that batches at runtime, which is what I did with very acceptable results. Now since this has a mildly complex workaround (you can static batch at runtime via script), it is not as bad of an issue.

When I had this problem and fixed it, at thirst I thought that everything was fine. Later, I found that the problem persists. The levelsizes were still (and at the time of writing for me still are) much much bigger than you'd expect and in fact ruining the 100mb target completely on their own.

After digging and digging and digging I found that counterintuitively, prefabs are a PURE editor feature, meaning that all prefabs are unpacked completely during build. So if for example, you have a complex menu in every scene (pause menu for example), the whole thing is DUBLICATED in every single scene that has it. You'd expect that the scene only saves the reference to a shared asset that it then loads but no, it actually holds a copy of the whole thing. This finding is mentioned here: https://www.youtube.com/watch?v=4JLpJHIdx7E&t=3s Mind that a prefab that you reference that might have subprefabs is also unpacked at buildtime (I tested this). So, if you have many levels and make heavy use of prefabs and if your scene-sizes on disc compared to levels in build differs a lot, then this is probably the issue that you are running into.

The "solutions"/workarounds won't be perfekt and vary from case to case. The easiest thing would be if unity allowed for a different behavior of the player via a build option. But having in mind that this issue wasn't even adressed for 5 years while a complete rebuilding of the prefab functionality occured within that time, workarounds might be necessary... The workarounds 1 and 2 will make editing your scenes more difficult since you won't see a visual representation of your prefab anymore, but they work in a lossless way.

1. Prefabs that have not been modified can be loaded at runtime. This forces the prefab to be referenced instead of dublicated (I tested this and can confirm a reduced build size if applied).

2. If the prefab was modified in any way, you'll need a script that loads the unmodified prefab from disc and then applies the changes. Not exacly a low hanging fruit.

3. For objects where you can't or don't want to apply workaround 2, you might want to remove all attached components and children that you can do without with or expand via a custom script, so effectively slimming the size of the prefab itself.

4. Use scripts to expand/create your gameObjects and components at runtime where possible. Make use of the EditorOnly tag where applicable and delete all garbage from your scenes where possible.