Optimizing asynchronous execution flows in modern custom web extensions

A pattern that has worked well for me is treating the background process as disposable and restartable rather than assuming it will remain alive indefinitely.

For long-running tasks:

Register extension API listeners once at the top level, not inside repeated callbacks.

Remove tab, port, DOM, and message listeners when their owner is destroyed.

Use AbortController to cancel abandoned fetches or async operations.

Keep queues, maps, and caches bounded with TTL or LRU eviction rather than allowing them to grow indefinitely.

Batch incoming work and apply backpressure instead of processing every event immediately.

Use chrome.alarms for periodic work rather than relying on a continuously running timer.

For local state:

Use chrome.storage.session for temporary state that should survive service-worker suspension but not a browser restart.

Use chrome.storage.local for durable settings and lightweight checkpoints.

Use IndexedDB for larger structured datasets or higher-volume records.

Keep only a small hot cache in memory, hydrate it lazily, and treat it as replaceable.

Debounce or batch storage writes, version the stored schema, and remove expired records during reads or scheduled maintenance.

The main design goal is that every event handler is idempotent and can recover its required state after the background worker restarts. That generally prevents both lifecycle-related failures and unbounded memory growth.