Image Caching and Cache Busting with Leptos

[NCura]

Hello everyone,

I'm excited to share that I've successfully deployed my first client project using Leptos, leveraging SSR + Axum and hosted on fly.io (link if you'd like to take a look). As I continue optimizing the site, I noticed an opportunity for improvement: implementing a cache policy.

After analyzing the website's performance with PageSpeed Insights, I found that my images are set to "none" Cache TTL. While reviewing previous discussions and issues on this GitHub repository, I came across the Cache Busting issue from last year.

I have a few questions:

• How can I configure caching for my images?
• Do WASM and JS assets get cached automatically by Leptos or cargo-leptos?
• In light of the cache busting issue mentioned above, are there any necessary steps I need to take to handle cache busting in my project, or is it done automatically by Leptos or cargo-leptos nowadays, since it was closed as completed?

Any guidance on this would be greatly appreciated!

Thanks in advance for your help.

[gbj]

It is important to note that Leptos does not manage the process of serving static files. Static file serving is included in the starter templates, but note that this is just boilerplate that exists in user code, and uses actix_files (for Actix) or tower_http (for Axum).

So in your case, using Axum:

How can I configure caching for my images?

However you'd like, using tower_http. In the current template, static file serving is handled in fileserv.rs.

Do WASM and JS assets get cached automatically by Leptos or cargo-leptos?

No.

In light of the cache busting issue mentioned above, are there any necessary steps I need to take to handle cache busting in my project, or is it done automatically by Leptos or cargo-leptos nowadays, since it was closed as completed?

The linked issue specifically enables the ability to add hashes to the JS/WASM files built by cargo-leptos, which can be useful for cache busting because it allows you to add long-term cache headers for the JS/WASM you serve, knowing that a new filename will be generated (so those cache settings won't apply) when the app is updated, i.e., users will always receive the most recent content.

So, neither leptos nor cargo-leptos does anything w.r.t. caching of static assets (images, JS, WASM). You have the ability to cache them however you'd like; cargo-leptos provides some tools for hashing filenames on the things it generates (JS/WASM) to support this.

[purung]

Just wanted to mention that there is a nice example of a useful pattern in hackernews_islands_axum, but it might not be obvious to look there. The assets produced by cargo-leptos are embedded in the binary and served directly with the cache settings you specify in code. You can combine this with the hash cache busting strategy to point to fresh assets on every build.

Edit: how you want to serve and cache-bust images might be a different story. You can opt in and out of folders and file types through the rust_embed macros. You can match on the mime type and do custom cache logic for images. It might not be efficient to embed them into the binary, of course. For a few assets that you might like to iterate on for design purposes it could still be feasible, though. If I am serving a folder of pictures I like to keep the cache logic separate from code and use ServeDir on folders.