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

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

В Manifest V3 привычный background page превратился в service worker. Это ломает паттерны, которые работали годами: браузер может завершить SW в любой момент, если нет активных задач. Мы столкнулись с этим на практике, когда клиент потерял данные из-за глобального счётчика, который не пережил перезапуск. Решение — переосмыслить архитектуру.

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

Мы разрабатываем браузерные расширения более пяти лет и реализовали более 20 проектов с Service Worker. Наш опыт позволяет гарантировать стабильность и производительность даже в сложных сценариях. Хотите, чтобы ваше расширение работало без сбоев? Свяжитесь с нами для консультации.

Почему 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 снижает потребление памяти в 2 раза по сравнению с MV2, а время старта расширения — на 30% за счёт ленивой загрузки. При этом экономия на серверной инфраструктуре может достигать 40%.

Долгоживущие соединения через Port

Для задач, занимающих больше нескольких секунд (стриминг, 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 });
    }
  });
});

Работа с chrome.alarms для периодики

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.

Обработка ошибок и устойчивость

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

Как отладить Service Worker: пошаговый план

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 и очередей.
• Документацию по архитектуре и инструкции по поддержке.
• Гарантию стабильной работы: мы отвечаем за результат.

Этапы разработки SW

Почему стоит доверить разработку нам?

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

Свяжитесь с нами, чтобы оценить ваш проект.

Фронтенд-разработка React: от аудита до production

Бандл вырос до 3.1 MB gzip — это реальная цифра из проекта, который пришёл к нам на аудит. Причина: moment.js (72 KB) тянул локали для всех 160 языков, lodash импортировался целиком вместо tree-shake, три компонентные библиотеки подключены одновременно. TTFB отличный, но TTI (Time to Interactive) на мобильном — 14 секунд. Пользователи уходили, конверсия упала на 40%. Мы переписали фронтенд: убрали дублирование библиотек, внедрили динамические импорты и SSR. Результат — бандл уменьшился до 850 KB gzip, TTI — 2.1 секунды, LCP — 1.8 с.

Frontend — это не «нарисовать красиво». Это производительность, типизация, рендеринг-стратегия, bundle management и поддерживаемость на годы.

Почему Next.js — стандартный выбор для SEO?

React — наш основной UI-фреймворк для сложных интерфейсов. Next.js — стандартный выбор для проектов с SEO-требованиями или SSR. App Router (с версии 13) принёс React Server Components, streaming и fetch с built-in кешированием. Это реальные преимущества: страница каталога с тысячами товаров рендерится на сервере без отправки логики фильтрации на клиент, JS-бандл меньше на 30%.

Но App Router — другой способ мышления. "use client" нужно ставить осознанно. Реальная ошибка: разработчик помечает весь layout как "use client" из-за одного состояния навигации — и теряет все преимущества RSC. Правило: держать Server Components как можно выше в дереве, "use client" — только для интерактивных листовых компонентов. ISR (Incremental Static Regeneration) — мощный инструмент для контентных сайтов. На каталоге из 50 000 страниц с ISR и CDN — TTFB < 50 ms для любой страницы.

Как TypeScript предотвращает баги в продакшене?

TypeScript обязателен на любом проекте, который планируется поддерживать дольше 3 месяцев или в команде больше одного разработчика. Аргумент «пишем быстро без типов» работает только первые 2 недели. После — баги, связанные с неопределёнными значениями, возникают каждую неделю.

Конкретная польза: рефакторинг API-ответа — изменил тип в одном месте, TypeScript показывает все места, где нужно адаптировать код. Без типов — баг в продакшене через неделю. strict: true в tsconfig.json — обязательно. noImplicitAny, strictNullChecks, strictFunctionTypes. Боль от Type 'undefined' is not assignable в разработке стоит меньше, чем Cannot read properties of undefined в продакшене. tRPC — end-to-end типизация от бэкенда до фронтенда без отдельной схемы — изменяя тип процедуры, вы сразу видите места на фронтенде, требующие правки.

Vue 3 + Nuxt 3 — альтернативный стек для SSR

Vue 3 с Composition API — другой стиль разработки, ближе к React Hooks. <script setup> и composables делают код более переиспользуемым. Nuxt 3 — фреймворк для Vue с SSR/SSG, аналогичный Next.js. useAsyncData и useFetch — встроенные composables с дедупликацией запросов и hydration. Auto-imports удобны, но могут запутывать при debug. Nuxt Content — модуль для Markdown/MDX-файлов, идеален для документации.

Hydration mismatch — специфическая боль SSR на Vue и React. Решение: <ClientOnly> компонент для браузерного контента, suppressHydrationWarning для dynamic timestamps.

Производительность: метрики и инструменты

Bundle analysis — стартовая точка. @next/bundle-analyzer или rollup-plugin-visualizer — запускаем перед каждым мажорным деплоем. Цель: ни одна страница не должна требовать > 200 KB JS gzip для first paint.

Динамические импорты для тяжёлых компонентов:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типичные кандидаты на dynamic import. Без этого они попадают в основной бандл. React DevTools Profiler — для поиска лишних ре-рендеров. React.memo, useMemo, useCallback — точечные инструменты. Преждевременная мемоизация всего подряд добавляет overhead без пользы. Профилируйте сначала, оптимизируйте потом.

Виртуализация длинных списков: @tanstack/virtual или react-window рендерят только видимые элементы. Таблица с 50 000 строк: с виртуализацией — 60fps, без — браузер зависает при скролле.

State management: без оверинжиниринга

Для большинства приложений достаточно:

• React Query / TanStack Query — для серверного состояния (данные из API, кеширование, инвалидация)
• Zustand — для глобального клиентского состояния (легковесный, без бойлерплейта Redux)
• React Hook Form — для форм

Redux Toolkit оправдан для очень сложного глобального состояния с большим количеством взаимодействий. Для большинства задач — это overkill. Recoil, Jotai — атомарные подходы для независимых кусков состояния.

CSS и дизайн-система

Tailwind CSS последней версии — наш стандартный выбор для новых проектов. Utility-first, отличная интеграция с компонентными библиотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива когда нужна более явная изоляция стилей. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненты с полным контролем над стилями. Нет dependency lock-in: компоненты копируются в проект и полностью кастомизируются. Storybook — для документирования компонентной библиотеки. React DevTools Profiler — официальный инструмент от команды React.

Тестирование

E2E тесты через Playwright — для checkout, авторизации, критичных форм. Не для всего подряд: поддержка большой e2e-сюиты дорогая, поэтому выбираем 3-5 ключевых сценариев.

Ориентиры по срокам и состав работ

Стоимость рассчитывается после декомпозиции на компоненты, экраны и интеграции с API. Мы используем N+1 оценку: прибавляем 20% на риски.

Что входит в работу: исходный код в Git, документация по архитектуре и компонентам, доступ к CI/CD, обучение вашей команды (2-3 встречи), гарантия 3 месяца на выявленные баги. Дополнительно — покрытие юнит-тестами ключевых модулей.

У нас 5 лет опыта в фронтенд-разработке, более 50 выполненных проектов, команда из 10 инженеров, владеющих React, Vue, Angular. Работаем с технологиями, описанными в документации React и TypeScript. Дополнительные сведения можно найти в Wikipedia: React и Wikipedia: TypeScript.

Какой стек выбрать для фронтенд-разработки React?

Мы сравниваем инструменты по реальным метрикам. Next.js быстрее Nuxt в сборке SSR на 20–30% при одинаковом размере страницы. TypeScript снижает количество production-багов на 60–70% по сравнению с JavaScript. Экономия на поддержке такого проекта — до 500 000 рублей в год за счёт сокращения времени на отладку. Если вам нужен лёгкий SPA с минимальной стоимостью — достаточно React + Vite. Для контентного сайта с SEO — Next.js с ISR даёт TTFB ниже 50 мс даже при 50 000 страниц.

Получите консультацию по вашему проекту: оценим текущий код и предложим план оптимизации. Закажите аудит — найдём узкие места и покажем, как сократить бюджет без потери качества.