Why your browser will always have the latest Arka

When we ship a fix, every Arka user should see it within minutes. That is not how the web works by default.

Web caches are aggressive. Service workers, in particular, will happily serve a year-old copy of your site to a returning user, no matter how many times you deploy. Solving this properly took us a week of careful plumbing.

The four moving parts of the cache pipeline

• Auto-bumped cache name. Our build script regex-replaces the service worker's CACHE_VERSION on every build. A new build name means the SW's activate handler evicts every old cache.
• Network-first HTML. Navigation requests skip the cache. Even if the SW is running, the HTML shell is always fetched fresh, which means the versioned CSS/JS URLs inside are always fresh too.
• Tight update probe. The browser checks for a new SW every 24 hours by default. We probe every 5 minutes, plus an extra check whenever the user comes back to the tab.
• One-time auto-reload. When a new SW activates and takes control of the page, a controllerchange event fires. We listen for it and force a single location.reload(). The next thing the user sees is the new build.

End-to-end deploy flow

You hit deploy. The new files go live. Within five minutes, every active user's browser notices a new SW. The new SW installs in the background, skip-waits, takes control. Their tab reloads exactly once. They see the fix.

No hard-refresh prompt. No “clear your cache” emails. No support tickets that start with “I am still seeing the old version.” The pipeline does it for them. The same pipeline that delivered our mobile chat box fix to every user within an hour of deploy.