I also struggled with the binary output size of Golang WASM, and that it was growing with each version. Someone recommended TinyGo, and although I haven't needed it for a couple years now, at the time the WASM binary output size was much better.
Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough for canvas 2D/3D or even DOM. It would be nice to ditch the JS bits, and I suspect the compositors all-the-way down are probably hitting my 2D performance.
I use a custom API on the JS side, and making the most of the shared memory for strings. For widget creation within DOM I have small API wrappers on the JS side to avoid too much bridge crossing with attribute sets/gets.
For 2D/3D moving the canvas animation loop to the JS side helped.
So far the html (inc custom JS API) comes in at 20KB, and my wasm around 80KB (SVG based UI with a small embedded font).
Not sure how the latest Zig compares, but I'd be quite happy stuck on this older version for this project because it seems very stable.
Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough for canvas 2D/3D or even DOM. It would be nice to ditch the JS bits, and I suspect the compositors all-the-way down are probably hitting my 2D performance.