Cache busting due to new deploymentId

[Fonger]

hi

I'm experimenting with deploymentId setup to protect basic version skew.

It's important for server component/actions.

However, I see all of static assets are also suffixed such deployment id with ?dpl=DEPLOYMENT_ID.

IMO it's not good because all static files ( /_next/static/...) in production come with hash in filename.
If we do this, users can't share the cache even if the files are not changed (same hash filename) for the new deployment.

For example

• /_next/static/chunks/webpack-60f36a8a7ebc3016.js?dpl=DeployA
• /_next/static/chunks/webpack-60f36a8a7ebc3016.js?dpl=DeployB

These 2 files are the same, but users must re-download the JS because of a new deployment.

[alex-statsig]

Noticed the same thing when looking into this new deploymentId feature today. One potential improvement could be setting the No-Vary-Search header for static assets so the "dpl" parameter doesn't affect caching, but it doesn't seem very supported yet.

I haven't tried this out yet, but I suspect providing a CDN asset prefix might omit the dpl parameter and fix this too, but isn't ideal.

[moltar]

If using CloudFront, it is possible to omit query strings from cache key.

[alex-statsig]

The browser has its own cache though that gets busted, ideally the user doesn't have to hit CDN even

[Fonger]

I agree @alex-statsig 's point.

We use Cloudflare and we have learned how to omit the unrelated query string in CDN cache with Cache Rule.

However, browsers won't know this and still re-download the same file.

Our website is a famous social media web application and people keep revisiting our web again and again. It's crucial to keep the local cache for maximum user experience too.

[moltar]

Good points!