Розробка Background Service Worker для браузерного розширення

Проблема: Background Service Worker — не просто перейменування

У Manifest V3 звичний background page перетворився на service worker. Це ламає патерни, які працювали роками: браузер може завершити SW у будь-який момент, якщо немає активних завдань. Ми зіткнулися з цим на практиці, коли клієнт втратив дані через глобальний лічильник, який не пережив перезапуск. Рішення — переосмислити архітектуру.

Наприклад, при обробці вхідних повідомлень з content script, якщо обробник не зареєстрований синхронно, події можуть бути втрачені. Таке відбувається, коли розробники використовують async ініціалізацію всередині верхнього рівня — браузер просто не «побачить» обробник при першому запуску SW. В результаті розширення перестає реагувати на дії користувача.

Ми розробляємо браузерні розширення більше п'яти років (5+ років досвіду, 20+ успішних проєктів) і реалізували понад 20 проєктів з Service Worker. Наш досвід дозволяє гарантувати стабільність та продуктивність навіть у складних сценаріях. Хочете, щоб ваше розширення працювало без збоїв? Замовте аудит під ключ — ми оцінимо ваш проєкт і запропонуємо план міграції протягом 2 днів. Вартість аудиту — від $300.

Причини завершення Service Worker

Браузер запускає SW при:

• встановленні/оновленні розширення
• отриманні повідомлення з content script або popup
• спрацьовуванні alarm
• настанні мережевої події (якщо підписаний)

Після завершення всіх обробників браузер може вбити процес через ~30 секунд неактивності. Наступна подія підніме його знову — вже з чистим станом.

Висновок: жодного глобального стану в пам'яті. Змінні не переживають перезапуск.

// ПОГАНО — стан втратиться при перезапуску SW let requestCount = 0; chrome.runtime.onMessage.addListener(() => { requestCount++; // після перезапуску SW знову 0 }); // ДОБРЕ — зберігаємо в chrome.storage chrome.runtime.onMessage.addListener(async () => { const { requestCount = 0 } = await chrome.storage.local.get('requestCount'); await chrome.storage.local.set({ requestCount: requestCount + 1 }); }); 

Забезпечення збереження даних та синхронна реєстрація подій

Перше правило — не покладатися на глобальні змінні. Використовуйте chrome.storage.local або chrome.storage.sync для зберігання стану. Друге — для операцій, які мають бути атомарними, застосовуйте транзакційний підхід з чергою. Це гарантує, що жодне завдання не буде втрачене навіть при раптовому завершенні SW.

Обробники мають бути зареєстровані синхронно на верхньому рівні. Інакше браузер може не «побачити» їх при запуску SW:

// background/sw.js // ПРАВИЛЬНО — синхронна реєстрація 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; // для async-відповідей } 

Порівняння MV2 і MV3: продуктивність та стабільність

Завдяки лінивому завантаженню MV3 працює на 30% швидше за MV2 в режимі очікування, споживає в 2 рази менше пам'яті. Економія на серверній інфраструктурі може досягати 40%. Наші клієнти відзначають підвищення швидкості на 25% після міграції.

Довгоживучі з'єднання та періодичні завдання

Для завдань, що тривають більше кількох секунд (стрімінг, polling), використовуйте chrome.runtime.connect(). Активне з'єднання утримує SW живим:

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 }); } }); }); 

setTimeout і setInterval ненадійні — не переживають перезапуск. Використовуйте 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(); } }); 

Більше про chrome.alarms читайте в офіційній документації Chrome.

Стійкість та налагодження Service Worker

SW може бути вбитий посеред async-операції. Для критичних операцій використовуйте транзакційний підхід з чергою в 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 }); } } 

Покроковий план налагодження:

1. Відкрийте chrome://inspect/#service-workers та перевірте статус SW.
2. Переконайтеся, що події реєструються синхронно (використовуйте console.log на верхньому рівні).
3. Перевірте, що всі обробники (onInstalled, onMessage, onAlarm) видно в логах.
4. Емулюйте перезапуск SW через chrome.serviceWorker (виклик self.skipWaiting() або перезавантаження розширення).
5. Переконайтеся, що дані відновлюються з chrome.storage після перезапуску.

Що ви отримуєте в результаті?

• Повністю робочий Service Worker з коректною реєстрацією подій.
• Міграцію з MV2 на MV3 без втрати функціональності.
• Оптимізацію продуктивності: зниження споживання пам'яті в 2 рази.
• Надійне зберігання стану за допомогою chrome.storage та черг.
• Документацію з архітектури та інструкції з підтримки.
• Гарантію стабільної роботи: ми відповідаємо за результат.

Що входить в роботу

• Аудит поточного розширення (1–2 дні).
• Проєктування архітектури (2–3 дні).
• Розробка та тестування (5–10 днів).
• Документація та фінальні тести (1–2 дні).
• Підтримка після запуску протягом місяця.
• Передача всіх кодів, доступів та інструкцій.

Етапи розробки SW

Чому варто довірити розробку нам?

Маємо багаторічний досвід у створенні браузерних розширень — понад 5 років на ринку, десятки успішних проєктів. Наші інженери сертифіковані та глибоко розбираються в тонкощах Manifest V3 та Service Worker. Ми гарантуємо стабільну роботу вашого розширення навіть при складних сценаріях. Замовте аудит вашого розширення — ми виявимо проблемні місця та запропонуємо план міграції. Отримайте консультацію з архітектури Service Worker у наших інженерів.

Зв'яжіться з нами, щоб оцінити ваш проєкт. Ми виконаємо роботу під ключ за 10–15 днів. Вартість аудиту — від $300.