Dev Server: Cache Modules Unconditionally + HMR Cache Invalidation

[hediet]

Description

For very large applications (such as the monaco editor), caching with Cache-Control: no-cache + Etag is good, but it could be even better.
This is the network profile reloading the monaco editor from the vite dev server:

Every request is a 304 Not Modified, but it still takes 1.4 seconds. This is because the browser still does 860 requests to check if the cache is valid. (However, when the dev tools are closed, it is much faster, though I don't know how to measure that - also, usually, while developing a site, the dev tools are opened)

Suggested solution

If the vite dev server would

• add a ?t=${devServerStartupTime} to every module link
• send Cache-Control: max-age=3600 (or bigger value) for modules it serves
• use HMR to make the website do a fetch(changedModuleUrl, {cache: "reload"}) for every changed module to force-refresh the cache

then, reloading after a change gets down to less than 400ms (with dev tools open):

If nothing changes, the browser doesn't have to fetch anything from the vite dev server.
If something changes, only the cache of the modified modules are invalidated.
If the server restarts and the HMR websocket connection closes, the ?t=... parameter makes sure the browser does a full reload.

Btw. nice work on this tool!

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[ArnaudBarre]

This is an interesting idea but we need a way to cleanup the cache when the server sends a full reload event because things changed that requires a reload and the expected behaviour is that the browser will ask for the new version of the changed file that could not be hot replaced.

It would also requires using some local-storage timestamp to differentiate between manual reload and "close the tab and re-open one minute later".

I've personally experimenting with content based caching that persists accros dev server restart, pinging @patak-dev that was once asking for real world timing of the difference between 304 and cached 200.

[patak-dev]

I think content based caching is still an interesting idea to explore. I'm not going to be able to do it for a while as the current focus shifted after the perf optimizations we got in 5.1. Maybe something to look back again once the Environment API work lands.

@hediet do you have extensions installed? Would you check the time diff using an incognito window in that case?
Last time I checked, with an incognito window, the diff between having the dev tools open or not was not that big (https://x.com/patak_dev/status/1745427467480039580, https://x.com/patak_dev/status/1745681046681563153).

I agree it would be better to find a way to avoid the 304s though. If someone wants to explore in a PR, we could discuss the tradeoffs there.

[hediet]

This is an interesting idea but we need a way to cleanup the cache when the server sends a full reload event

In that case, the server could change the url of all the resources (e.g. ?t=${t++}) and just ask the browser to reload the html file (which will never be cached).

[ArnaudBarre]

Yes but in that case you trade off good reload on manual reload against bad reload on dev server reload. That's something to be discussed but for me the real solution is content based caching 👀

[hediet]

Yes but in that case you trade off good reload on manual reload against bad reload on dev server reload.

Ah yes, I didn't think of that.

I'm not very aware of all the possible http caching strategies, can you clarify what you mean with content based caching?