skipWaiting vs waiting state for zero-downtime PWA updates in Chrome

Deploying a small PWA update without forcing users to close every open tab requires deciding whether a new Service Worker should activate immediately or remain in a waiting state until existing clients close. Chrome's documented lifecycle holds a newly installed worker by default, preserving the active version across open tabs. Calling skipWaiting bypasses this hold, allowing the new worker to control pages sooner but introducing the possibility of a mismatch between the running page and newly cached assets.

The constraint becomes more complex when Cache Storage manages versioned assets. A waiting worker keeps active tabs stable, yet users may continue receiving stale content until all instances close. Immediate activation accelerates the rollout, but an uncoordinated controllerchange event can leave open tabs referencing a different cache version than the page expects.

Which strategy better balances zero-downtime deployment with state consistency for open tabs in current stable Chrome? Is there a documented coordination pattern between skipWaiting and controllerchange that avoids version mismatch without requiring a full tab close? How should Cache Storage versioning be structured to support either activation path during a small application migration?