Intermittent Full-Page Cache Serving Stale JavaScript Files on My Real-Time Morse Code Website Hosted on Kinsta

Kinsta API API Questions
1

I recently migrated my Morse Code website to Kinsta because I wanted better performance, improved reliability, and built-in caching features. The website is a JavaScript-based Morse Code translator that converts text into Morse code and decodes Morse messages instantly as users type. Since the migration, the overall page load speed has improved significantly. However, I have encountered one recurring issue involving cached JavaScript assets after deploying new versions of the website. This problem only appears after production deployments and affects some visitors but not others.

The website relies on a single JavaScript bundle that contains the translation logic, audio playback functionality, and user interface interactions. Whenever I deploy an update, the latest JavaScript file is available on the server, but some users continue receiving an older cached version. As a result, they experience outdated functionality or interface inconsistencies until their browser cache eventually refreshes. The HTML appears to update correctly, but the JavaScript served to some users does not always match the latest deployment.

To investigate the issue, I verified that my deployment process completes successfully and that all updated files exist on the server immediately after publishing. I also tested cache clearing through the hosting dashboard and confirmed that browser caching headers appear reasonable. Despite these checks, the issue still occurs intermittently, making it difficult to reproduce consistently. Since the translator depends entirely on the latest JavaScript logic, even a small version mismatch causes noticeable problems for users.

I have considered implementing filename versioning or asset fingerprinting to force browsers to request updated JavaScript files after each deployment. Before restructuring the project’s asset pipeline, however, I wanted to understand whether there are hosting-specific recommendations for handling frontend asset caching on Kinsta. My goal is to preserve the performance benefits of caching while ensuring that visitors always receive the latest application code immediately after a deployment.

Because the website is an interactive tool rather than a traditional content site, JavaScript consistency is critical for every visitor. A stale cached script can prevent new translation features from working correctly or introduce compatibility issues with recently updated HTML and CSS. I would prefer to solve this through a recommended deployment strategy instead of asking users to manually clear their browser cache whenever a new version is released.

Has anyone hosting JavaScript-heavy applications on Kinsta experienced similar cache behavior after deployments? I would appreciate recommendations on the best approach for cache invalidation, asset versioning, or deployment workflows that ensure updated JavaScript files are delivered consistently without sacrificing the performance advantages provided by Kinsta’s caching infrastructure. Sorry for long post!

2

Is there anyone who can help me?

3

Howdy @Joe :waving_hand: ,

Thank you kindly for your patience friend, and the detailed write-up — that level of detail made this easy to diagnose.

What you’re seeing is a known caching pattern, not a deployment or Kinsta platform issue, and the fix you’re already considering (filename versioning/fingerprinting) is the correct solution.

Why it happens

Your HTML updates immediately after each deploy because it’s served with short cache lifetimes (or purged automatically). Your JavaScript bundle, however, is likely being served with a long Cache-Control max-age, which is normally desirable for performance — except that when the filename stays the same across deployments (e.g., main.js), there’s no signal to browsers or intermediate caches that the content has changed. Some visitors get a fresh copy simply because their local cache entry happened to expire around deploy time; others don’t, because their browser (or a proxy in between) is still holding a valid, unexpired copy of that exact file. That’s exactly the “some visitors, not others” pattern you described.

Clearing cache from the hosting dashboard only clears the server-side/edge cache — it has no effect on individual visitors’ browser caches or any proxies between them and the site. That’s why your dashboard-side checks came back clean while the issue persisted for real visitors.

Why fingerprinting is the right fix

Fingerprinting (e.g., main.a1b2c3d.js instead of main.js) changes the cache key itself, not just the cache duration. Once the filename changes with every deploy:

  • Old cached files simply become irrelevant, since the new HTML references a new filename
  • The JS file can then safely use a very long cache lifetime, since a given fingerprinted file’s contents never change
  • Only the small HTML file needs to stay fresh, which is cheap and fast to serve

This is the default behavior in modern build tools (Vite, Webpack, Parcel, esbuild) specifically because it solves this exact problem — so this isn’t a Kinsta-specific workaround; it’s filling a gap in the current build process.

Recommended next steps

  1. Enable content-hash fingerprinting in your build process for the JS bundle (most bundlers support this with a config flag).
  2. Once fingerprinted, we can set a long-lived Cache-Control header for the JS asset(s) — this preserves (and improves) your performance gains.
  3. Keep the HTML on short cache lifetimes so it always points to the current file.
  4. As an interim fix while you set up fingerprinting, a cache-busting query string tied to your deploy version (main.js?v=abc123) will help, though it’s less reliable than true fingerprinting since some proxies ignore query strings for caching purposes.

Once fingerprinting is in place, Kinsta’s edge cache will work with you rather than against you — it caches by URL, so a new fingerprinted filename is automatically treated as new content with no manual purge needed for the JS itself.

If you DM me a link to the MyKinsta page for this site, I’d be happy to take a look.

Again, thanks for your patience while we reviewed this.

Hope this helps.

kindly,

Shawn C.