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.

[PeteX]

One option is to serve all your static content with no-cache and without cache busts, but install a service worker. Workbox works well with Leptos if you can accept some Javascript along with your Rust... You need to install workbox-cli since of course you are not using a build tool like Vite which would integrate with Workbox directly.

By default, service workers don't update when the page is reloaded. The update is triggered by a new visit where the user ends up at the site by clicking a link, for example. This probably isn't what you want. To change the behaviour, include the following options in workbox-config.js:

skipWaiting: true,
clientsClaim: true,

You then need to add a Javascript snippet to the HTML page. I have this, but you may well want slightly different behaviour on your own site:

if ("serviceWorker" in navigator) {
  let installed = !!navigator.serviceWorker.controller;
  const sw = await navigator.serviceWorker.register("./sw.js");
  navigator.serviceWorker.addEventListener("controllerchange", () => {
    if (installed)
      window.location.reload()
    installed = true;
  });

  window.addEventListener("visibilitychange", () => {
    if (document.visibilityState === "visible") {
      console.log("Service worker update due to visibility change.");
      sw.update();
    }
  });

  setInterval(() => {
    console.log("Service worker update due to timer.");
    sw.update();
  }, 30 * 60 * 1000);
}

This causes an update when the browser tab becomes visible, and also every half hour. This avoids the problem where a deactivated tab can stay around for a long time, with the user then returning to it and using outdated code which no longer works with the server API.

The downside is that the user could be halfway through filling in a form, only to be surprised when the site refreshes. In an ideal world, you avoid this by keeping the old server API available for a while after an update; if you're going to do this, you should also switch off the refresh behaviour.