Sadly, there isn't much you can do about it.
- gzip the JS output when delivering over the network
- if you have JS dependencies you could extract those into a separate bundle which would improve caching. See ScalaJSBundler's various bundling modes.
Any real world Scala.JS app has a ~200KB tax from using various features from the Scala's standard library(collections, futures, etc.), that's pretty much unavoidable in practice.
This might improve with Scala 2.13 where the collection library (big part of the bundle size) is more modular, although I've read that it is turning out not as modular as originally desired.
There are a few open issues in the ScalaJS project to add support for code splitting and such, but those improvements will not reduce the raw output size, just cut it up into smaller pieces that can be loaded on demand.
Everything I've read about this issue says "this is a high level design tradeoff, and there is little opportunity for significant optimizations above the many optimizations that are already in place".
Now, disregarding the stdlib tax, you can do some things to make your own Scala code result in less generated JS code. That kind of optimization would be relevant for bigger applications. I don't know much about this, but I suspect even things like defining Scala native classes vs classes extending js.Object could affect the outcome at scale, although I'm not sure in which direction. I wish there was a comprehensive Scala.js performance guide... There are a few videos on youtube from a couple years ago where Sebastian showcases and explains Scala.js performance and optimizations on specific benchmarks though.
If anyone has a more educated view on any of this I'm all ears.