Initial download size on the web is very important and Unity is, at least in its basic form, by nature not the perfect choice for building small, efficient WebGL applications.
But there are a lot of dials and buttons to press, allowing us to tune the size even without having to resort to Project Tiny.
I set out to see how small I could get a WebGL build. As reference I took the default Unity Universal Render Pipeline template and went through all the optimization options.
|Render Pipeline||Publish Compression||Texture Compression||Shader Stripping||Code Stripping||Size on Disk|
|Universal||Brotli||Crunched 50%||Auto||Low||11.7 MB|
|Universal||Brotli||Crunched 50%||Auto||High||11.4 MB|
|Universal||Brotli||Crunched 50%||Import||High||11.4 MB|
|Standard||Brotli||Crunched 50%||Import||High||7.35 MB|
Obviously changing the overall compression of the published package brought a large saving, but setting all the textures to use crunched compression also saved a lot of space.
Code and shader stripping only brings further savings if there's a lot of custom code, or calls to Unity components. Unitys' URP template is not that heavy on code so savings aren't big here.
Code stripping is currently only available in "low" settings for .NET 3.5 and not at all for anything newer, so it's safer to go for .NET 2.0, if you want to use code stripping.
For shader stripping I switched to "Import" and then chose "Import From Current Scene", which should usually be safe enough.
One thing that isn't listed here is, if you switch to the standard render pipeline, since the universal render pipeline has some custom overhead and uses some textures for post processing which I haven't been able to remove, even if I didn't use any post effects.
Good news is that, despite there being a lot of unnecessary packages in the standard template, most pre-installed packages don't contribute much to the overall build size.
The biggest surprise here was, that switching from the universal render pipeline to the standard render pipeline saves a ton of space. One thing I noticed was, that the URP was using a built in version of the post processing stack, which is quite large and can't be disabled. But in general URP still seems to be tagged onto the standard engine, making it an extra bulk to carry around.
Granted, I just took the URP project and threw out the URP package and the result didn'T look exactly the same as before, but still both are of a comparable quality and if you can you should do this optimisation, since the URP just uses up a lot of space and HDRP isn't even recommended for WebGL export.
Microsoft's libraries can add a lot of bloat to the project. The good thing is that Unity only includes libraries that you reference in your scripts. So it's best to be very concious of what .NET features you use and in best case not use any System functions at all.