How to safely benefit from CDN caching on Firebase Hosting when your app's server is hosted on a different Cloud service

Question

I'm already long-term cache my static assets like: css, images, js files etc. Since those files all get content-hash ids in my build process, this is how I treat them cache-wise:

// STATIC FILES LIKE IMAGES, FONTS, CSS AND JS

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

This way I get both client and CDN cache up to a year, which is great. It's working fine.

But my web app is a Single Page React App, so whenever I update it, the only index.html file my users got from my app becomes automatically stale and useless, because it points to the old static JS files, which have all been updated now.

So basically I cannot let them get a stale index.html no matter what.

I'd also like to get the benefits from the CDN cache for that file. And here is when it might get tricky.

Right now, to be on the safe side, here is what I'm doing:

// For index.html

Cache-Control: "no-cache, no-store, must-revalidate"

I was thinking of changing it to:

// FOR index.html

Cache-Control: "max-age=0, s-maxage=86400, must-revalidate"

This way I would get a CDN cache of 1 day, which would be nice. But I still don't wanna take the risk of serving a stale index.html.

Here is what Firebase Hosting says about it:

Any requested static content is automatically cached on the CDN. If you redeploy your site's content, Firebase Hosting automatically clears all your cached static content across the CDN until the next request.

But the problem is my server is hosted on Cloud Run. And Firebase Hosting basically rewrites every request to it. Something like:

firebase.json

"rewrites": [
  {
    "source": "**",
    "run": {
      "serviceId": "server",
      "region": "uscentral-1"
    }
  }
]

So, whenever I update my app, I re-deploy it to Cloud Run, but I do not run a new firebase deploy --only hosting command. Because nothing in my firebase.json file changes in-between new deployments of the Cloud Run code.

---

QUESTION

Is it safe to add the s-maxage=86400 header in this situation?

Assuming a new deploy on Cloud Run will not trigger the purge of the CDN cache. Is there something I can do to trigger that? Like some firebase deploy --only hosting:clear-cdn command?

Because even if I run firebase deploy --only hosting again, I'm not really sure the cached files will be purged, because my Firebase Hosting /public folder is always an empty folder. So Firebase Hosting might "feel" that nothing has changed.

Answer 1

After a day of testing, here are the results:

If you set Cache-Control headers that will allow for shared (CDN) caching, like public or no-cache, your responses will be caches both on client browser and on CDN caching.

• When you re-deploy to Cloud Run, will it clear your CDN cache automatically?

No. When you update and re-deploy your app files to Cloud Run, those cached files on CDN will be stale and will not be automatically cleared from the CDN. So even if nothing has changed as far as Firebase Hosting is concerned, you need to run firebase deploy --only hosting again. This will make the CDN clear all of your cached files and new requests will start getting fresh data right away.

• I'm not really sure the cached files will be purged, because my Firebase Hosting /public folder is always an empty folder. So Firebase Hosting might "feel" that nothing has changed.

Even if nothing in your Firebase Hosting public folder has changed (in my case it's an empty folder) and nothing in your firebase.json has changed, it will still create a new Firebase Hosting release and it will clear your cached files from the CDN, like the doc says:

Any requested static content is automatically cached on the CDN. If you redeploy your site's content, Firebase Hosting automatically clears all your cached static content across the CDN until the next request.

Attention for dynamic content

If you have dynamic content that you'll edit through an admin UI, for example. Be aware that the CDN cache will keep stale cache of that content until it expires.

For example: CDN caches /blog/some-post with s-maxage of 1 day. Even if you change the content of your post dynamically, the CDN will keep the CDN for 1 full day, until it expires and it gets requested again.