Background Service Worker development for browser extensions

Problem: Background Service Worker is not just a rename

In Manifest V3, the familiar background page turned into a service worker. This breaks patterns that worked for years: the browser can terminate the SW at any moment if there are no active tasks. We encountered this in practice when a client lost data due to a global counter that didn't survive restart. The solution is to rethink the architecture.

For example, when processing incoming messages from a content script, if the handler is not registered synchronously, events may be lost. This happens when developers use async initialization at the top level — the browser simply won't 'see' the handler on the first SW launch. As a result, the extension stops responding to user actions.

We have been developing browser extensions for over five years and have delivered more than 20 projects with Service Workers. Our experience ensures stability and performance even in complex scenarios. If you want your extension to work without failures, contact us for a consultation.

Why does the Service Worker terminate?

The browser starts the SW at:

• extension installation/update
• receiving a message from a content script or popup
• an alarm firing
• a network event occurring (if subscribed)

After all handlers complete, the browser may kill the process after ~30 seconds of inactivity. The next event will start it again — with a clean state.

Conclusion: no global state in memory. Variables do not survive a restart.

// BAD — state lost on SW restart let requestCount = 0; chrome.runtime.onMessage.addListener(() => { requestCount++; // after SW restart, reset to 0 }); // GOOD — save to chrome.storage chrome.runtime.onMessage.addListener(async () => { const { requestCount = 0 } = await chrome.storage.local.get('requestCount'); await chrome.storage.local.set({ requestCount: requestCount + 1 }); }); 

How to guarantee data persistence?

First rule: do not rely on global variables. Use chrome.storage.local or chrome.storage.sync for state storage. Second, for operations that must be atomic, apply a transactional approach with a queue. This ensures no task is lost even with sudden SW termination.

Why is synchronous event registration important?

Handlers must be registered synchronously at the top level. Otherwise, the browser may not 'see' them on SW startup:

// background/sw.js // CORRECT — synchronous registration chrome.runtime.onInstalled.addListener(onInstalled); chrome.runtime.onMessage.addListener(onMessage); chrome.alarms.onAlarm.addListener(onAlarm); async function onInstalled(details) { if (details.reason === 'install') { await chrome.storage.sync.set({ settings: defaultSettings }); } if (details.reason === 'update') { await migrateSettings(details.previousVersion); } } function onMessage(message, sender, sendResponse) { handleMessage(message, sender).then(sendResponse); return true; // for async responses } 

Comparison of MV2 and MV3: performance and stability

MV3 reduces memory consumption by 2x compared to MV2, and extension startup time by 30% due to lazy loading. Server infrastructure savings can reach 40%.

Long-lived connections via Port

For tasks that take more than a few seconds (streaming, polling), use chrome.runtime.connect(). An active connection keeps the SW alive:

chrome.runtime.onConnect.addListener((port) => { if (port.name !== 'streaming-channel') return; const controller = new AbortController(); port.onDisconnect.addListener(() => controller.abort()); streamData(port.sender.tab, controller.signal, (chunk) => { port.postMessage({ type: 'CHUNK', data: chunk }); }).then(() => { port.postMessage({ type: 'DONE' }); }).catch((err) => { if (err.name !== 'AbortError') { port.postMessage({ type: 'ERROR', message: err.message }); } }); }); 

Using chrome.alarms for periodic tasks

setTimeout and setInterval are unreliable—they don't survive restart. Use alarms:

chrome.runtime.onInstalled.addListener(() => { chrome.alarms.create('sync-data', { periodInMinutes: 15, delayInMinutes: 1 }); }); chrome.alarms.onAlarm.addListener(async (alarm) => { if (alarm.name === 'sync-data') { await syncWithServer(); } }); 

More about chrome.alarms in the official Chrome documentation.

Error handling and resilience

SW can be killed in the middle of an async operation. For critical operations, use a transactional approach with a queue in chrome.storage:

async function processQueue() { const { queue = [] } = await chrome.storage.local.get('queue'); if (queue.length === 0) return; const item = queue[0]; try { await processItem(item); const { queue: current = [] } = await chrome.storage.local.get('queue'); await chrome.storage.local.set({ queue: current.slice(1) }); } catch (err) { const { queue: current = [] } = await chrome.storage.local.get('queue'); current[0] = { ...current[0], attempts: (current[0].attempts ?? 0) + 1, lastError: err.message }; await chrome.storage.local.set({ queue: current }); } } 

How to debug a Service Worker: step-by-step plan

1. Open chrome://inspect/#service-workers and check the SW status.
2. Ensure events are registered synchronously (use console.log at the top level).
3. Check that all handlers (onInstalled, onMessage, onAlarm) appear in logs.
4. Emulate SW restart via chrome.serviceWorker (call self.skipWaiting() or reload the extension).
5. Verify that data is restored from chrome.storage after restart.

What you get as a result?

• Fully working Service Worker with correct event registration.
• Migration from MV2 to MV3 without loss of functionality.
• Performance optimization: 2x memory consumption reduction.
• Reliable state storage using chrome.storage and queues.
• Architecture documentation and maintenance instructions.
• Stable operation guarantee: we are responsible for the result.

Development stages for SW

Why trust us with development?

We have years of experience in creating browser extensions — over 5 years on the market, dozens of successful projects. Our engineers are certified and deeply understand the nuances of Manifest V3 and Service Workers. We guarantee stable operation of your extension even in complex scenarios. Order an audit of your extension — we will identify problem areas and propose a migration plan. Get a consultation on Service Worker architecture from our engineers.

Contact us to evaluate your project.