does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.
I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...).
You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128
It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.