Iced Web File Sizes

[victorstewart]

i was exploring the idea of writing a simple one pager website with a dynamic table on it in Iced. but when i compiled the web example I saw the wasm file is over 4MB.

curious what contributes to that size, is it 90+% the Iced library itself? is there any hope of vastly reducing the size of this file in the future?

probably untenable for me to pursue Iced for this web project if the file sizes will always be multi megabyte.

[victorstewart]

for reference, facebook.com is 324KB

[Kaiden42]

Is the 4MB the size of the debug or the release build of your application?

[victorstewart]

i followed the instructions on the web README..

cargo build --package tour --target wasm32-unknown-unknown
wasm-bindgen ../target/wasm32-unknown-unknown/debug/tour.wasm --out-dir tour --web

and got these files..

1.5K Jul 13 21:51 tour.d.ts
15K Jul 13 21:51 tour.js
4.3M Jul 13 21:51 tour_bg.wasm
1.1K Jul 13 21:51 tour_bg.wasm.d.ts

maybe the 4.3M is the debug one you refer to, and the 1.1K is the "real" one?

built these on my MacOS laptop, if the platform was something to do with it as well.

[Kaiden42]

i followed the instructions on the web README..

Yes, that is the debug build. The debug build contains everything you need to debug the binary and therefore is not optimized by the compiler. The release build will always be smaller than the debug build as it is an optimized binary.

To run the release build just add --release to the cargo command cargo build --release --package tour --target wasm32-unknown-unknown

Edit: and of course change the path to the release build at binding :wink: wasm-bindgen ../target/wasm32-unknown-unknown/release/tour.wasm --out-dir tour --web

maybe the 4.3M is the debug one you refer to, and the 1.1K is the "real" one?

No, the tour_bg.wasm.d.ts file contains the type definitions of the public functions to be available in TypeScript.

[victorstewart]

okay great. using release i got..

868K Jul 13 23:40 tour_bg.wasm

and post processing with wasm-opt -Oz -o tour_bg_small.wasm tour_bg.wasm i got the size down to 670K.

what percentage of this size is the overhead of the library itself? wondering if this size will scale linearly with the size of the application.

[13r0ck]

I'm not sure about the exact overhead, but maybe you can compile the tour example for the web, and then see how that file size compares to your compiled project, then compare the length of your project's code with the length of the tour example's code. Then you should be able to get a pretty good estimate.

[cryptoquick]

You can also use a tool like cargo bloat to see which crates use the most space, and you can perhaps disable some crate features you're not using.

I'm not 100% sure if all these techniques carry over, but you can also look into the techniques described in min-sized rust.

[Lyamc]

Just because I recently went through this, I thought I'd share what I did.

If you're using trunk like I am, you can just add the following to your index.html as per this page to run wasm-opt as part of the build process:

<link data-trunk rel="rust" data-wasm-opt="s" />

And add the following to your Cargo.toml file as per min-sized-rust

[profile.release]
opt-level = 's'          # Optimization level.
lto = true              # Sets link-time optimization.
panic = 'abort'         # The panic strategy.

Then you just have to run trunk to build the wasm:

trunk build --release

And I configure my server to point at ./dist/index.html

Before: 13767800
After:   1707855

I wish it was a little better than 1.7MB but it's still quite the improvement! The main improvements come from the adjustments to Cargo.toml, I only gained about 0.3MB from wasm-opt.