is there a difference in loading times/sizes between js and wasm js? Im loading the same app side u...

# compose-web

[Alex Styl]

is there a difference in loading times/sizes between js and wasm js?

Im loading the same app side using js and wasm side by side and it seems that the target doesnt matter.

No real benchmarking here just testing on browser

https://composeexamples.com/js-vs-wasm

[Jacob Ras]

Interesting 🙂 Here on Firefox 130.0.1 @ Windows 11 the JS version loads 0.25 - 0.5 seconds (estimation) faster. A bit longer on the first load. Makes me wonder if that's because JS is on the left side of the screen. An option to switch them could be interesting 😬

[Alex Styl]

hmm i think it doesnt matter. let me double check how iframes work

[Alex Styl]

doesnt seem to matter (they load async), but here is the reversed:

https://composeexamples.com/wasm-vs-js

[Alex Styl]

it seems more or less the same/random to me 🤷 sometimes wasm loads faster, othertimes the js one

[Jacob Ras]

Cool! With the reversed one still JS (now on the right side) loads noticeably faster for me.

[Robert Jaros]

In my opinions the apps are not equivalent. The JS version loads two JS files directly with <script> tags (which probably is somehow optimized/parallelized by the browser), while in the Wasm version only the main landingpage.js file is loaded with a <script> tag and two large wasm files required to run the app are loaded indirectly from that script.

[Robert Jaros]

Also turning gzip compression on the server will definitely make things better for both apps.

[Jacob Ras]

But when refreshing those things should come from cache, right? Then still the JS one loads considerably faster for me.

[Robert Jaros]

Yes, it does. Can't be different because in the wasm version the whole skiko.wasm is loaded before the app itself can start to load. In the JS version the app is ready even before skiko starts to load. Just check the timelines in the devtools network window. The skiko library is just one great performance killer, especially noticeable in the wasm version.

[Alex Styl]

In my opinions the apps are not equivalent.

@Robert Jaros im confused. are you describing how the distributable between wasm and js compose app works or something specific on the link i shared?

[Robert Jaros]

I'm referring to how compose apps work. Nothing we can do about this, at least for now.

[Alex Styl]

enabling gzip definatelly made it faster

but it broke the wasm app so i guess js it is 😅

[Oleksandr Karpovich [JB]]

Perhaps rel=preload might help a bit with k/wasm loading https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload

[Jakub Kostka]

@Oleksandr Karpovich [JB] do you have an example of the implementation? I've tried implementing the preload before and console was shouting at me (The resource at “https://URL/composeApp.wasm” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly.), that the composeApp.wasm was not used even though preloaded.

[Oleksandr Karpovich [JB]]

no dedicated example.
Perhaps this can be useful: https://github.com/JetBrains/compose-multiplatform/issues/4968#issuecomment-2222539435