There are two separate issues here - even with responding with a 304 code when data hasn't been modified, the browser will still respect 'Cache-Control' headers and not even send requests until the cache timeout has expired. By default, sites on Firebase Hosting send a Cache-Control header of 'max-age=3600', which means a browser won't try to request updated resources for 1 hour after it received the first response (unless you hard refresh the page). You can modify the headers in your firebase.json file (see
https://www.firebase.com/docs/hosting/guide/url-redirects-rewrites.html#section-headers for more details) but you're trading off for bandwidth to your site and network traffic you're forcing on your users. If you expect a lot of changes to the static content of your site (non-database traffic), or not a lot of repeat visits, then a low max-age might be applicable, but otherwise a maximum delay of 1 hour from a `firebase deploy` to all your users seeing the new site is usually acceptable, if a little short.
We have a task to add Etag headers to responses that would allow our CDN to serve 304 responses when the content hasn't been modified, but that only reduces traffic for repeat visits outside the Cache-Control time. I'm afraid I don't have a timeline on when we might implement that.