Browser tests that pass locally and fail after deployment are often blamed on timing, selectors, or an unstable CI environment. Sometimes that is true. But when the failures cluster around newly deployed PWAs, asset versioning changes, or cache policy updates, the root cause is frequently the same: the browser is not running the version of the app you think it is.

A service worker can serve stale HTML, stale JavaScript bundles, or a hybrid page where some resources came from the network and others from an older cache entry. That is exactly the kind of state that produces confusing test failures. A test may click a button that exists in the latest build but not in the cached bundle, or it may wait for a network request that never happens because the service worker fulfilled it from cache.

If your team has seen browser tests break after service worker changes, the key is not just knowing that caching exists. The important part is understanding how service worker update logic, offline caches, and asset fingerprinting interact with the browser automation model.

The failure pattern in one sentence

The app deployed to production is not always the app the test runner loads.

That sounds obvious, but the mismatch can happen in several ways:

  • The service worker returns an older HTML shell.
  • A cached JavaScript bundle references routes or selectors that no longer exist.
  • A test expects a fetch request, but the service worker intercepts it.
  • Asset versioning changed, but a stale cache entry still points to old chunks.
  • The service worker installed correctly, but activation was delayed until the next navigation.

In practice, these failures are rarely pure test problems. They are usually integration problems between app delivery, browser storage state, and the test environment.

What a service worker changes in the browser

A service worker sits between your page and the network. It can intercept requests, cache responses, and decide whether to serve from cache, from network, or from a custom fallback. The Service Worker API is designed to make web apps faster and more resilient, but it also introduces a second delivery path for every resource that matters to a test.

That second delivery path affects automation in a few specific ways:

1. A page load no longer guarantees fresh content

With a traditional app, reloading the page tends to fetch the current HTML and bootstrap scripts from the server or CDN. With service workers, the page can be a cached response from a prior session. That means a locator or route that matches the deployed code may not match what the browser actually loaded.

2. Requests may disappear from your network assertions

Many browser tests assert that a specific API call happened. But a service worker can fulfill the response from the Cache Storage API, which means the request may never hit the network stack in a way the test expects. This is especially visible in Playwright request routing or Cypress network assertions.

3. Multiple app versions can coexist in the same browser profile

A test suite that reuses context, browser profile, or user data can accumulate old caches, old IndexedDB entries, and an older service worker registration. The first test after deployment can behave differently from later tests because activation and cache cleanup are not deterministic across all browsers and test runners.

4. The app can change beneath the page without a full reload

A new service worker can download in the background. Depending on the update strategy, the app may continue serving the old version until the old page closes, or it may switch caches on the next navigation. That creates race conditions that look like flaky selectors but are actually versioning transitions.

Why these failures appear after deployment

The phrase “after deployment” matters because deployment is where version boundaries become visible. Before deployment, local development usually has one active version at a time. After deployment, users and test environments can span multiple versions.

There are several common transition failures.

Stale asset browser tests

A bundle or chunk filename may change when the build changes. If the HTML shell or manifest is cached too aggressively, the browser may request an old chunk name that no longer exists on the server. Depending on the app, that leads to a hard load failure, a partially rendered page, or an invisible JavaScript error.

This is often the first place teams notice the problem because the UI loads but behaves incorrectly. A test might fail at a click step with “element not found” when the root cause is a console error from a missing module.

Service worker update bugs

Service worker updates are intentionally conservative. The browser downloads a new worker, installs it, and usually waits before activating it. If the app expects a new worker to take effect immediately, test results can differ across runs and browsers.

A common mistake is assuming that calling skipWaiting() is enough. It is not enough by itself, because activation, clients, and navigation behavior still determine when the new version actually controls the page. The official service worker lifecycle behavior is documented by browser vendors and framework guides, and it is stricter than many teams expect.

Cache invalidation testing failures

Cache invalidation testing is difficult because invalidation is not one event. There may be separate caches for HTML, API responses, static assets, opaque CDN responses, and browser storage. A test can pass on a clean profile, fail on a reused profile, and pass again when storage is manually cleared. That pattern usually means the app is functionally correct but the test environment is not isolating browser state.

Why different test tools fail in different ways

The exact symptom depends on the browser automation tool, how it manages context, and how much network control it exposes.

Playwright

Playwright tends to make these issues easier to inspect because it provides strong browser context isolation and request interception. It can also record console messages, network events, and storage state in a controlled way. For example, to diagnose a suspected service worker issue, you can start by blocking cached state through a fresh context and observing whether the failure disappears.

import { test, expect } from '@playwright/test';

test('loads a fresh app version', async ({ browser }) => {
  const context = await browser.newContext();
  const page = await context.newPage();

page.on(‘console’, msg => { if (msg.type() === ‘error’) console.log(‘console error:’, msg.text()); });

await page.goto(‘https://app.example.com’, { waitUntil: ‘networkidle’ }); await expect(page.getByRole(‘button’, { name: ‘Save’ })).toBeVisible(); });

This does not “fix” caching, but it gives you a clean baseline. If the failure only appears when using a persistent context, the browser state is part of the problem.

Selenium

Selenium can also diagnose these failures, but it usually requires more manual setup. Browser profiles, storage state, and service worker interactions depend heavily on the driver and browser version. In a long-lived session, stale cache state can leak between tests unless the team explicitly resets it.

from selenium import webdriver

options = webdriver.ChromeOptions() options.add_argument(‘–user-data-dir=/tmp/clean-profile’)

driver = webdriver.Chrome(options=options) driver.get(‘https://app.example.com’) print(driver.title) driver.quit()

Selenium is perfectly capable here, but the burden of environment hygiene is higher. Teams that use Selenium for cached apps usually need stronger conventions around profile cleanup, storage reset, and per-test browser isolation.

Cypress

Cypress runs in a browser-like control loop and often benefits from short feedback cycles, but it can still be affected by service worker behavior because the app is still a browser app. A test can see an apparently loaded page while the underlying cache state is inconsistent with the current release.

The practical takeaway is that tool choice changes the debugging surface, not the underlying problem. The root cause remains browser storage and versioning.

The most common root causes

1. The service worker did not activate when the test expected

The app may deploy a new worker, but the old worker remains in control until the next navigation or until all old tabs close. If a test assumes a new route or asset is active immediately after deployment, it may fail only in environments where the previous version is still present.

2. A cache-first strategy served an old response

Cache-first strategies are useful for speed, but they are risky for resources that change frequently or are tightly coupled to route logic. If an HTML shell or critical JavaScript bundle is cached too aggressively, the app can run code that no longer matches the server-side route structure.

3. Asset versioning is incomplete

Fingerprinting static assets works only when every layer respects the new versions. If the HTML references hashed bundles but the service worker or CDN still serves an older manifest, tests may load mixed versions. This is especially likely when a deployment updates only part of the asset pipeline.

4. Browser storage was reused across test runs

Persistent profiles are convenient for local reproduction, but they are dangerous when the suite is meant to validate release behavior. Old Cache Storage entries, localStorage flags, IndexedDB rows, and service worker registrations can survive long enough to produce false failures.

5. The test waits for the wrong signal

A test may wait for load, a network idle state, or a specific request. But if the resource comes from cache, the expected signal never happens or happens too early. This is not always a bug in the test. It is often a mismatch between the app’s delivery model and the test’s synchronization model.

How to debug a suspected cache or service worker failure

A useful debug sequence needs to answer one question first, before any test code is rewritten: is the failure tied to browser state or to the app itself?

Step 1: Reproduce with a clean browser context

Start with a new profile or incognito-style context. If the app works there, the failure is likely tied to persistent browser storage rather than the deployed build.

Step 2: Inspect service worker registration and caches

In a manual browser session, check navigator.serviceWorker.getRegistrations() and Cache Storage entries. In automation, you can evaluate the same APIs in page context.

typescript

const registrations = await page.evaluate(async () => {
  const regs = await navigator.serviceWorker.getRegistrations();
  return regs.map(r => ({ scope: r.scope, state: r.active?.state }));
});

console.log(registrations);

If multiple registrations exist, or if the active worker is not the one you expect, the test environment is carrying state forward.

Step 3: Compare network and cache behavior

Look for resources that are served from disk cache or service worker rather than the origin. In Chrome DevTools, the Network panel shows the source of a response. In automated tooling, request events and console logs can reveal whether the app fetched a resource or restored it from cache.

Step 4: Check for version drift between HTML and bundles

A common failure mode is an HTML shell generated from build A that loads chunks from build B. This happens when deployment, CDN propagation, and cache headers are not aligned. The browser may tolerate that state until it hits a route or component that no longer exists.

Step 5: Validate cache-busting assumptions

Make sure the versioning strategy is consistent across all layers:

  • HTML should not be cached as aggressively as hashed assets.
  • Critical app code should use fingerprinted filenames.
  • Service worker update logic should not pin users indefinitely to old assets.
  • CDN rules should align with build output conventions.

What to change in the app

Fixing the test suite without fixing the app often only hides the problem.

Use a clear caching policy by asset type

Do not give every resource the same treatment. A pragmatic split is:

  • HTML, very short cache lifetime or validation-based caching
  • JavaScript and CSS bundles, fingerprinted filenames with long cache lifetimes
  • API responses, explicit cache strategy based on freshness requirements
  • Images and fonts, cacheable if versioned or immutable

This is a general pattern, not a universal rule. The real decision depends on whether stale content is acceptable and how often the resource changes.

Make service worker updates observable

If your app has a forced update path, expose it clearly. Tests and developers should be able to tell when a new worker is waiting, when it has activated, and when the page has reloaded into the new version.

Avoid caching the application shell indefinitely

Apps that cache the shell too aggressively often create the worst browser test failures because the shell controls routing, script bootstrapping, and component loading. An old shell can make the entire app look broken even when the backend is healthy.

Reset on deploy when correctness matters more than continuity

Some apps need aggressive continuity for offline use. Others need a clean switch to the new version. If the app is primarily tested as a release artifact rather than an offline-first product, reducing state carryover can simplify both production behavior and test reliability.

What to change in the test suite

Prefer isolated browser contexts for release validation

For release checks, a clean context is often more valuable than a reused one. Persistent profiles are useful for testing warm-cache behavior, but they should be used intentionally, not by accident.

Add a dedicated cached-state test

Do not rely on your main smoke test to catch cache issues. Write a separate test that verifies upgrade behavior, especially if the app uses a service worker or an offline-first architecture.

typescript

test('updates cleanly after cached assets change', async ({ browser }) => {
  const context = await browser.newContext();
  const page = await context.newPage();

await page.goto(‘https://app.example.com’); await page.reload();

await expect(page.locator(‘[data-testid=”app-shell”]’)).toBeVisible(); });

The exact assertions will vary. The point is to test the transition path, not just the happy path.

Clear storage when the test is not about warm state

If a scenario is meant to validate a first-run flow, clear service workers, Cache Storage, localStorage, and IndexedDB as part of setup. Otherwise, the test may silently inherit prior state.

Assert on app version or build ID

A lightweight build ID in the DOM or response headers can make debugging much easier. When a test fails, it should be possible to tell whether the browser is seeing build 1042 or build 1041.

CI considerations that often get missed

Continuous integration environments amplify cache issues because they are designed to reuse infrastructure while pretending the browser is fresh. That tension can hide state leakage.

The most useful CI checks for this class of bug are not exotic. They are disciplined:

  • Run the suite in a clean browser profile by default.
  • Separate “cold cache” and “warm cache” scenarios.
  • Reproduce with the same browser version used in CI.
  • Record console logs and network traces for failing builds.
  • Fail fast when a service worker registration or bundle version is unexpected.

Continuous integration is supposed to surface release risks early. If your pipeline only exercises the app in a single browser state, it may be hiding the exact failure mode that appears after deployment.

A practical decision guide

If the app breaks only when storage is reused, focus on browser state hygiene.

If the app breaks only after deployment, focus on version drift between HTML, worker, and assets.

If the app breaks in a way that changes across browsers, inspect service worker lifecycle and cache source behavior.

If the app breaks after a worker update but not after a hard refresh, inspect the update flow and the activation path.

If the app breaks under automation but not manually, compare the test runner’s profile handling, startup flags, and navigation timing against the manual browser path.

A good rule is to treat service worker failures as release engineering problems first and test problems second.

When to disable or limit service workers in test environments

There are valid cases for bypassing service workers in automated tests, especially for suite layers that validate UI logic rather than offline behavior. Doing so can reduce noise and isolate regressions more quickly.

That said, disabling service workers everywhere is not a complete solution. If your production app relies on them, you still need at least one dedicated test path that exercises the real caching model. Otherwise, you can ship a release that passes tests but fails in the field.

A balanced approach is often best:

  • Unit and component tests, ignore service workers.
  • Critical end-to-end smoke tests, run with clean state.
  • Upgrade and offline scenarios, run with service worker and cache behavior enabled.
  • Deployment validation, assert the expected build version and asset set.

The real lesson

Browser tests do not break because service workers are magical or because cache invalidation is hard in the abstract. They break because the test suite assumes a single source of truth, while the browser now has several:

  • the current deployment,
  • the service worker,
  • the cache store,
  • the CDN edge,
  • and the browser profile itself.

Once those layers can disagree, a passing test means only that the specific combination you ran was stable. It does not guarantee that the next deploy will be stable, especially if the app changed cache strategy or asset versioning at the same time.

For frontend engineers, QA leads, and DevOps teams, the practical goal is not to eliminate caching. It is to make version boundaries visible, testable, and predictable. That usually means cleaner asset fingerprinting, explicit cache policies, isolated browser contexts, and separate tests for cold starts, warm starts, and upgrades.

When those pieces line up, browser tests stop failing for mysterious reasons after deployment. More importantly, the failures that remain become meaningful, because they point to real regressions instead of stale browser state.

Further reading