Skip to content

Web app resources are not cached #3278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ochrons opened this issue Dec 3, 2024 · 2 comments · May be fixed by #3928
Open

Web app resources are not cached #3278

ochrons opened this issue Dec 3, 2024 · 2 comments · May be fixed by #3928
Assignees
Labels
cli Related to the dioxus-cli program fullstack related to the fullstack crate performance

Comments

@ochrons
Copy link

ochrons commented Dec 3, 2024

Problem

When Dioxus fullstack serves resources like the app.wasm and web.js files, these are not properly cached by the browser or any intermediate CDNs like CloudFlare.

Expected behavior

All immutable resources should be served with proper cache control headers and with unique hashed names to enable most efficient caching.

How to improve

Here's a network snapshot of a second load of a Dioxus web app.
image

Even though none of the resources are actually downloaded (beyond the initial index.html), it still takes over 500ms for the page to properly load. This is due to browser issuing requests for all resources with if-modified-since: Tue, 03 Dec 2024 17:49:30 GMT header, to which the server promptly responses 304 Not Modified. But due to network latency, this takes 136ms.

Having an intermediate cache like CloudFlare would not help, since it would also need to check with the origin server if the resource has changed.

Solution involves two things:

  1. Encode a content hash to resource file names to make them unique (instead of web_bg.wasm use web_bg_12398718923.wasm)
  2. Provide proper cache control headers indicating immutability and a very long max age

Third thing is to bundle up all the JS files into a single JS file as suggested in #3277

Example header

Cache-Control: public,max-age=31536000,immutable

This same strategy should also be extended to all public application assets coming through Manganis. But not to any (user) private assets, but these would probably not be managed with Manganis in the first place.

See also https://engineering.fb.com/2017/01/26/web/this-browser-tweak-saved-60-of-requests-to-facebook/

@ealmloff ealmloff added cli Related to the dioxus-cli program performance fullstack related to the fullstack crate labels Dec 3, 2024
@ealmloff ealmloff self-assigned this Jan 9, 2025
@jkelleyrtp
Copy link
Member

jkelleyrtp commented Jan 22, 2025

In 3531 we tried to add this but then realized that assets that weren't handled via manganis (ie had permanent names) need to be handled differently than hashed assets.

This would require building a manifest/list of assets that the devserver reads when booting up to populate the asset cache which became out-of-scope for that PR.

@ochrons
Copy link
Author

ochrons commented Jan 22, 2025

Instead of a manifest file, the same could be achieved by a clever naming scheme for cacheable assets. This would also allow developers to control caching of non-manganis assets by applying the same naming scheme. Something like

image-71fe028312371ad7(cache-immutable).jpg
styles(cache-3600).css

@ealmloff ealmloff linked a pull request Mar 29, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Related to the dioxus-cli program fullstack related to the fullstack crate performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants