A browser-side response path can sit outside the caches you have purged. Compare an existing visitor session with a genuinely fresh session.
Compare an affected and a fresh profile
Use the same public URL in the browser showing the problem and a separate clean test profile. Record the asset URLs and response details in both. If only the established profile stays old, investigate local storage and response handling before purging the CDN again. Also check browser extensions and ordinary HTTP cache; not every persistent problem involves a service worker.
Check for a controlling worker
Inspect the browser’s Application tools for registered service workers, their scope and status. Identify the plugin or custom code that registered them. A service worker can intercept requests and use its own cached responses. Keep its script URL and registration scope in the report. If none controls the affected page, pursue another cause rather than creating a service-worker explanation without evidence.
Use a bounded local diagnostic
In a test profile, use developer-tool bypass controls to compare the normal network response with the worker-controlled response. Document the effect. Removing site storage is a broader operation that can erase consent or other local preferences; use disposable test data. Do not instruct all customers to delete storage as a substitute for fixing an update strategy.
Review versioning and update behavior
Ask the PWA or worker owner how new HTML and assets become consistent, how cached entries are versioned, and how an active session receives an update. Test an existing open tab alongside a newly opened one. Avoid forcing immediate activation through a copied snippet without considering old pages that still expect old assets. The integration should define a coherent supported lifecycle.
Verify online, repeat and offline states
If offline use is part of the product, test it after the fix rather than disabling the feature permanently. Check new visits, returning sessions, reopened tabs and a controlled loss of connectivity. Restore the previous worker deployment if mixed asset versions break the interface. Record the browser states and worker version that were tested so the next release can reuse the checks.
Symptom-to-cause worksheet
| What you observe | What to investigate | Next check |
|---|---|---|
| Only established profile is stale | Browser-side state may differ | Compare worker scope and response path |
| Bypassing worker shows new asset | Worker cache strategy implicated | Inspect owning integration’s update policy |
| New tab fresh, old tab broken | Mixed lifecycle or asset versions | Test coordinated update behavior |
Worked investigation scenario
This is an illustrative case, not a measured Velonic result. Suppose a returning browser receives an old script while a clean profile gets the new one, and bypassing its controlling worker changes the result. Give the PWA owner the worker version, scope and exact asset pair. Test an existing open tab and a reopened session after its supported update fix. Removing one local registration explains the symptom but does not repair update behavior for returning visitors.
Put it into practice
- Verify that a worker actually controls the page.
- Use disposable sessions for storage diagnostics.
- Test returning and offline visitors after a fix.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.