emscripten-compiled code already has a very aggressive dead-code elimination, so this wouldn't help I guess. It is most likely the cross-compiled Mono runtime plus required Unity modules which produce the code bloat on top of the actual game play code.

The emscripten dead code elimination uses static analysis which is limited only to the code totally impossible to be reached during execution even in theory. But POCL leaves only code which is actually invoked at run time (keeping all other code on server in the "load at first invocation" form). The difference may be very significant.

Google products (google docs for example) use Closure Compiler for dead code elimination, but anyway, after clicking almost every menu item in document editor, only around 45% of code was invoked.

If that 26mb web site was available online, I would be interested to measure it's code usage ratio.

Hmm that's very interesting, a bit risky, but worth experimenting with... thanks for the pointer!

What risks do you see?

BTW, the idea is not radically new. Java loads classes only when they are accessed first time.

Operating systems load native applications by mapping executable file into virtual memory. The pages are loaded into physical memory only when CPU tries to access them.

Ok yes, if there's a mechanism that dynamically loads the missing parts then it could work (actually emscripten supports dynamically loading scripts similar to DLLs). But 'naively' deleting functions from an asm.js blob would result in some 'unknown function' exception if the analysis was wrong and a removed function is still called somewhere.