Can't we avoid the bloat from introducing leptos_router? (csr) #1073

jsprog · 2023-05-21T20:30:12Z

jsprog
May 21, 2023

When building a size optimized sample app, I could confirm that leptos_router is bloating WASM output size from 59KB to 174KB (nightly), A compatible sycamore app (80KB with routing) is more efficient in size compared to leptos.

I suppose that the regex crate is optional and not used by default for csr.

Could you elaborate what's causing the code to inflate by a non trivial margin just by introducing routing to app.
Is there a room for improvement.

# Cargo.toml (release is optimized for size)

[package]
name = "leptos-router-bloat"
version = "0.1.0"
edition = "2021"

[dependencies]
leptos = { version = "0.3.0" }
leptos_router = { version = "0.3.0", features = ["csr"] }

[profile.release]
codegen-units = 1 # Reduce Parallel Code Generation Units.
lto = true        # Enable Link Time Optimization. ("fat").
opt-level = "z"   # Optimize for size (default is 3).
panic = "abort"   # Abort on Panic    (default is "unwind").

# [unstable]
# build-std = ["std", "panic_abort", "core", "alloc"]
# build-std-features = ["panic_immediate_abort"]

<!-- index.html (wasm-opt: optimized for size) -->

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Leptos Router Bloat</title>

    <link data-trunk rel="rust" data-wasm-opt="z">
</head>
<body>
    
</body>
</html>

// src/main.rs

use leptos::*;
use leptos_router::{Router, Routes, Route};

fn main() {
    mount_to_body(|cx| {
        view! { cx, <App /> }
    })
}

#[component]
fn App(cx: Scope) -> impl IntoView {
    view! { cx,
        <h3>"Leptos Router Bloat"</h3>

        <nav>
            <a href="/">"Home"</a>
            " | "
            <a href="/about">"About"</a>
        </nav>
        <br />

        <main>
            // un-comment the following lines and build again
            // <Router>
            //     <Routes>
            //         <Route path="/" view=|cx| view! { cx, <Home /> } />
            //         <Route path="/about" view=|cx| view! { cx, <About /> } />
            //         <Route path="/*any" view=|cx| view! { cx, <NotFount /> } />
            //     </Routes>
            // </Router>
        </main>
    }
}

#[component]
fn Home(cx: Scope) -> impl IntoView {
    view! { cx, "Home Page" }
}

#[component]
fn About(cx: Scope) -> impl IntoView {
    view! { cx, "About Page" }
}

#[component]
fn NotFount(cx: Scope) -> impl IntoView {
    view! { cx, "Not Found!"}
}

gbj · 2023-05-21T21:24:10Z

gbj
May 21, 2023
Maintainer

When building a size optimized sample app, I could confirm that leptos_router is bloating WASM output size from 59KB to 174KB (nightly),

Confirmed.

A compatible sycamore app (80KB with routing) is more efficient in size compared to leptos.

I don't think this is a very helpful comparison; the two routers are quite different and have very different feature sets.

I suppose that the regex crate is optional and not used by default for csr.

Not used even in the browser, to be more precise; regex is only used on the server, because the regex crate alone would add 500kb of WASM binary size.

1. Could you elaborate what's causing the code to inflate by a non trivial margin just by introducing routing to app.

To me, this is kind of the heart of the question: the idea that routing is a "just," i.e., that "just introducing routing" is sort of a matter of running a match statement against the current URL.

To be clear, it would definitely be possible to build a router that focuses more on minimizing binary size, or a custom-built router that adds practically nothing. See the todomvc example for a good example of a simple custom router. If you really just have three routes (two static routes with no params and one fallback), and are in a context where WASM binary size really really matters, this may even be a good idea.

leptos_router is a much more general purpose tool, and is much more powerful than what it's doing in your example. Sometimes when you're using a framework you end up paying for some costs of its runtime for features that you don't technically need. (Implementing your example in vanilla Rust/wasm-bindgen, for example, would probably be less than 50kb of WASM, smaller than Sycamore or Leptos).

I'm happy to go into the details more if you're really curious, but here are a few things you're adding to your app just by including routing at all

route branch matching logic that's general enough to handle anything you put in those path definitions; yours are relatively simple, but the branch matching logic doesn't grow if you add more routes or they become more complex
support for nested routing, in the Leptos/Ember/Solid/Remix/React Router 6 sense of nested routes as a layout tool to prevent rerenders when there are shared sections of the page; not something you're using, but essential to performance in anything more than a trivial app
global click listener to detect clicks on <a> elements, make sure they can be handled by the router, and navigate on the client side rather than reloading the page
access to reactive versions of the current URL (pathname, search query, and route params)
automatically suspending navigation until async resources have loaded on the next page

... etc.

2. Is there a room for improvement.

Sure, probably! It's certainly possible to improve a lot with a router that's written differently or with different features. It's probably possible to improve at the margins in certain parts of the router code.

I'll admit this is not a very high priority for me. In my experience using this and other Rust/WASM frameworks (including Sycamore) to build actual apps, I've found that the pursuit of shaving a few kb off WASM binary size at the framework level is not particularly useful. In reality, most of the weight of the WASM binary ends up being some combination of serde and your component code, not the framework.

In this example the "no routing" version gzips to 26kb. The "with routing" version gzips to 76kb. The Leptos website gzips to 218kb (and is a 100 on Lighthouse mobile performance last time I checked); i.e., even for a one-page site our application code totally swamps the framework or the router in size, but still has fantastic loading performance. If one is in a situation in which the 50kb (gzipped) difference here really matters, WASM is probably the wrong choice.

So I'd be very happy to see incremental improvements to the binary size! I just have a lot on my plate.

0 replies

jsprog · 2023-05-22T14:45:10Z

jsprog
May 22, 2023
Author

Thank you very much for the detailed information. I could even reduce the final binary size from 174KB to 143KB (uncompressed) just by adding this configuration in the right place (.cargo/config.toml instead of Cargo.toml)

[unstable]
build-std = ["std", "panic_abort", "core", "alloc"]
build-std-features = ["panic_immediate_abort"]

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Can't we avoid the bloat from introducing leptos_router? (csr) #1073

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Can't we avoid the bloat from introducing leptos_router? (csr) #1073

Uh oh!

Uh oh!

jsprog May 21, 2023

Replies: 2 comments

Uh oh!

gbj May 21, 2023 Maintainer

Uh oh!

jsprog May 22, 2023 Author

jsprog
May 21, 2023

gbj
May 21, 2023
Maintainer

jsprog
May 22, 2023
Author