Why your HTML5 game still shows the old version

In brief

A successful upload does not necessarily mean that an already-open browser tab is running the latest game. If your HTML5 game uses a service worker, check both the deployed files and the worker's lifecycle before blaming the export.

• Identify the build the server is serving.
• Compare a fresh browser session with an existing game tab.
• Check whether an updated worker is installed but waiting.
• Protect saved progress before experimenting with reload behaviour.

First, separate the server from the browser

Our suggested diagnostic starting point is a visible build identifier in a test version of the game. Record the expected identifier when you deploy, then compare it in a fresh browser session and in the tab that appears outdated. This turns a vague visual complaint into a repeatable observation.

Do not assume a service worker is involved. Confirm that the application actually registers one. If it does not, investigate the deployment and ordinary caching path instead. Keep the old and new build records together so you can explain exactly what was tested.

Understand the waiting state

MDN's service-worker guide explains that a newer worker can be installed while an older worker still controls open pages. Installed and active are therefore different states.

web.dev's lifecycle explanation notes that clients can overlap during a refresh. A simple refresh may therefore leave the existing worker in control. Its recommended lifecycle is designed to avoid different versions interfering with one another, not merely to obstruct a deployment.

For a controlled test, finish the test session, close all tabs using that game and reopen it. Compare the build identifier again. Do this with a test profile, not by telling all players to delete their browser data.

Choose a safe update experience

MDN documents skipWaiting as a way to request immediate activation before open pages close. That capability is not a reason to apply it blindly.

Slotgen's recommendation is to treat an update as a product decision: tell the player an update is available, choose a safe stopping point, and make the expected effect of reloading clear. A game with unsaved local progress needs a different decision from a stateless demonstration.

A compact release check

Before the next rollout, record four outcomes: a clean first visit, a return visit, an already-open session and an offline visit if offline support is part of the product. Note the browser, build identifier and result for each.

This is a diagnostic plan, not proof that caching is the cause of every stale game. If the results disagree, keep the observations and investigate the particular delivery path rather than repeatedly replacing files without a hypothesis.