You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
Encode a content hash to resource file names to make them unique (instead of web_bg.wasm use web_bg_12398718923.wasm)
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.
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.
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
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.

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 responses304 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:
web_bg.wasm
useweb_bg_12398718923.wasm
)Third thing is to bundle up all the JS files into a single JS file as suggested in #3277
Example header
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/
The text was updated successfully, but these errors were encountered: