This version of the documentation is outdated, and features documented here may work differently now. You can see the latest stable version of the docs here.
Optimizing Code Size
If you're used to working with Rust, you're probably used to two things: performance is everything, and Rust produces big binaries. With Wasm, these actually become problems because of the way the web works. If you think about it, your Wasm files (big because Rust optimizes for speed instead of size by default) need to be sent to browsers. So, the larger they are, the slower your site will be (because it'll take longer to load). Fortunately, Perseus only makes this relevant when a user first navigates to your site with its subsequent loads system. However, it's still worth optimizing code size in places.
Before we go any further though, it's worth addressing a common misconception about Wasm. The size of the final Wasm binary for the Perseus basic example is usually around 200-300kB (this of course changes over time), which would be utterly unacceptable with JavaScript, but this would be considered about normal for an image. It's common to compare Wasm file sizes to JS file sizes, but Wasm is actually much similar to an image, because, unlike with JS, the browser can instantiate it much more quickly because it's already been compiled. This is a complex topic, but the general idea is that Wasm file sizes are better compared to image file sizes than to JS file sizes. You can read more about this here.
Now onto the optimizations. If you've worked with Rust and Wasm before, you may be familiar with wasm-opt, which performs a ton of optimizations for you. Perseus does this automatically with wasm-pack. But we can do better.
The easiest way to apply size optimizations for Perseus is the perseus-size-opt plugin, which prevents the need for ejecting to apply optimizations in .perseus/, and requires only a single line of code to use. Check it out here for more details! It's recommended that all Perseus apps use this plugin before they deploy to production, because it can result in size decreases of upwards of 100kb, which translates into real increases in loading time for your users.
Note: every size optimization has a trade-off with either speed or compile-time, and you should test the performance of your app after applying these optimizations to make sure you're happy with the results, because the balance between speed and size will be different for every app. That said, using even all these optimizations usually has a negligible performance impact.
Usually, this will be enough for most apps, though, if you really want to cut down a few kilobytes, you can use default-features = false on the perseus dependency in your Cargo.toml to deactivate live reloading and HSR. These don't do anything in production, though they do have a very slight code footprint, which can be eliminated by entirely disabling their features (live-reloading and hsr, which are enabled by default). Note that you'll probably only want to do this in production, as using this setting will disable these features in development as well. Note though that this will usually only remove fewer than 5kB from your final bundle (sometimes less).