Skip to content

Fix: Cache busting for production frontend assets#1471

Merged
aliasaria merged 3 commits intomainfrom
fix/cache-busting-contenthash
Mar 6, 2026
Merged

Fix: Cache busting for production frontend assets#1471
aliasaria merged 3 commits intomainfrom
fix/cache-busting-contenthash

Conversation

@aliasaria
Copy link
Copy Markdown
Member

Problem

Users sometimes get cached (stale) versions of the app after a new build because JS/CSS filenames don't change between deploys, and index.html has no cache-control headers.

Solution

1. Content-hashed filenames (webpack)

  • Changed production output filenames from [name].js[name].[contenthash:8].js
  • Changed CSS output from style.cssstyle.[contenthash:8].css
  • HtmlWebpackPlugin automatically injects the new hashed filenames into index.html

2. Cache-control headers (FastAPI)

  • Added middleware to set no-cache, no-store, must-revalidate on index.html so browsers always re-fetch it
  • Hashed JS/CSS assets get Cache-Control: public, max-age=31536000, immutable for aggressive long-term caching

Unchanged vendor chunks keep their hash and stay cached, so only modified bundles are re-downloaded.

Set no-cache on index.html so users always get the latest version.
Set immutable 1-year cache on content-hashed JS/CSS files.
@sentry
Copy link
Copy Markdown

sentry bot commented Mar 6, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@aliasaria aliasaria merged commit 0502b64 into main Mar 6, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants