Optimizing Wasm and JS module size and load time.

Recently I’ve thought of a static search for this blog without the need to run a backend.

So I started to build the following ‘search engine’:

I don’t know until now if I will deploy this anytime, but it’s a good project to make use of a little bit functional programming, Rust and Wasm.

However, one problem I faced was the size of the Wasm module and JS overhead for the search.

You can see in the figure that there are at least 2 JS components and 1 Wasm module. The index is stored in a simple JSON file. The whole index of the current blog has a size of 2MB which leads to a loading time of ~50 seconds on “Slow 3G”!

A long loading time is crashing the idea of static sites IMHO. Furthermore it is not so good to let visitors load the whole index even if they don’t use the search. Eating up their bandwidth is not my goal.

That’s why I started to explore how much load time and size I can save via optimization.

1. Optimizing .wasm size

One step towards a better load time, is the optimization of the size of the Wasm module. See also: Shrinking .wasm code size. This document presents some parameters which can be changed to shrink the size, as Wasm is usually optimized for speed rather than size!

Here are the three changed parameters and their outcome.

All load times are measured with a disabled cache and the ‘slow 3G’ param in Chrome DevTools.

1.1. Link Time Optimizations (LTO):

Setting the following in Cargo.toml:

[profile.release]
lto = true

Had a huge effect on size change!

1.2. Optimize for Size (instead speed):

In addition to the parameters in 1.1. the opt-level can be set to s:

[profile.release]
opt-level = 's'

There’s also the z paramter. But the documentation says that it is not always shrinking the size in comparison to s and a measurement is needed. Which was true in this case:

[profile.release]
opt-level = 'z'

1.3. Using the wasm-opt tool

The wasm-opt tool is also able to change the size:

Unfortunately not so much.

Saved overall

Overall the decrease is pretty noticeable. Optimizing the module size is worth the small amount of work.

Module size: -31.54%
Load time: -17.6%

2. Optimizing loading of index

The even bigger part of the search is the index, which will also grow with the content. With 2MB and ~42 seconds of load time, it is eating the bandwidth.

Here are some actions and ideas to shrink the size and load time.

2.1. Split the index

The first step is obvious: Split the index and load only the parts that are needed.

In the case of my index it was easy: Every letter is stored in its own file. When the use starts typing, the indices get loaded lazily.

This has a huge effect: One of the biggest indices is the one for the letter c. This will be taken for the comparison.

The disadvantage is that the user will wait a small amount of time every time he starts to type in a new, not yet loaded, letter.

You can see the effect here:

2.2. Load only once

With the right techniques and caching it will help a lot to load the index only once. So that it is reusable even for a revisit of the page. But this will lead to some other challenges.

2.3. Serializing the index

Another technique to shrink the size of a document is to serialize it.

Using the avro schema led to an incredible decrease of -23.52% without losing any data!

But the problem is, that the deserialization logic and package, either in Rust or JS was ~500KB in size. I didn’t do the math, but I think this doesn’t pay off for such small indices. I abandoned the idea.

3. Smaller js files

There are two JS files for the search: The interface to the Wasm module (search.js) and the glue code between the input field and the search interface (glue.js).

This can also be optimized:

search.js:

glue.js:

Notice the huge change of module size, but the small change of the load time.

4. Some other ideas

Beside of this low hanging fruits and the usage of parameters to change the size, there are some other possibilities to change the size and load time:

• Smaller HTML files (will need an optimization for the whole blog).
• Enabling brotli compression (which is not supported by my hosting services).
• Using another data structure for the index like a Trie.

Conclusion

There are some easy ways to optimize the load times and size of Wasm and JS modules. Sometimes you just need to set some parameters to get a better user experience. Here I explored some of them and I could feel the change in the User Experience.