Service workers в Next.js: регистрация и кэширование

Коротко: сервисные работники (Service Workers) — это фоновые скрипты, которые работают отдельно от основного потока JavaScript и позволяют реализовать кэширование, офлайн‑режим и синхронизацию данных в прогрессивных веб‑приложениях. В статье показаны базовая регистрация и активация в Next.js, пример простого кэша, а также рекомендации по стратегиям кэширования, безопасности и приемке.

Текстовый редактор с блоками JavaScript-кода

Сервисные работники — это скрипты, которые выполняются в фоновом режиме и дают мощные возможности для кэширования и других функций современных веб‑приложений.

Эти функции приближают опыт работы в браузере к нативным приложениям: быстрый запуск, офлайн‑доступ и уведомления. Сервисные работники — ключевой компонент при создании прогрессивных веб‑приложений (PWA).

Что такое сервисный работник

Сервисный работник — это тип веб‑воркера на JavaScript, который работает в фоне, отдельно от основного потока JavaScript, и поэтому не блокирует интерфейс. Это значит, что он не вызывает задержек во взаимодействии пользователя с приложением.

Экран ноутбука с кодом и подставкой для ручек рядом

Сервисные работники функционируют как прокси между веб‑приложением и сетью. Они перехватывают запросы и ответы, кэшируют ресурсы и обеспечивают офлайн‑поддержку. Это помогает сделать поведение приложений более плавным и предсказуемым даже при нестабильном подключении.

Короткое определение: сервисный работник — фоновый JavaScript, который перехватывает сетевые запросы и управляет кэшем.

Основные случаи использования сервисных работников

PWAs: регистрация service worker даёт доступ к push‑уведомлениям, офлайн‑режиму и более быстрому первоначальному отображению (fast loading).
Кэширование: хранение статических активов (изображения, JS, CSS) в Cache Storage для ускоренного доступа и снижения загрузки сервера.
Фоновая синхронизация: возможность отложить запросы (например, отправку формы) до восстановления сети.

Интеграция сервисных работников в Next.js

Перед тем как писать код, полезно понять две ключевые фазы работы сервисного работника: регистрация и активация.

Регистрация: браузер регистрирует файл сервисного работника (например, /service-worker.js) и связывает его со scope.
Активация: после установки новые обработчики начинают перехватывать запросы, а устаревшие версии удаляются.

Пример простой регистрации в браузере:

const registerServiceWorker = async () => {  
  if ("serviceWorker" in navigator) {  
    registration = await navigator.serviceWorker.register("/sw.js");  
  }  
};  
  
registerServiceWorker();

Код сначала проверяет, поддерживает ли браузер service workers. Если да — регистрирует скрипт по пути /sw.js.

Активация и установка слушаются через события install и activate:

registration.addEventListener("install", () => {  
    console.log("Service worker installed");  
});  
  
registration.addEventListener("activate", () => {  
    console.log("Service worker activated");  
});

Вы можете добавить этот код после регистрации, чтобы логировать фазы жизненного цикла.

Ссылка на код проекта доступна в репозитории проекта (если он у вас есть).

Создание проекта Next.js

Чтобы быстро создать каркас проекта Next.js локально, выполните:

npx create-next-app next-project

Добавление сервисного работника в Next.js обычно включает два шага:

Зарегистрировать сервисного работника в глобальной области (когда приложение загружается).
Положить файл сервисного работника в папку public (например, public/service-worker.js).

Добавление сервисного работника в _app.js

Пример регистрации в файле src/pages/_app.js. Размещение здесь гарантирует попытку регистрации при загрузке приложения и доступ ко всем ресурсам.

import { useEffect } from 'react';  
  
export default function App({ Component, pageProps }) {  
  useEffect(() => {  
    if ('serviceWorker' in navigator) {  
      navigator.serviceWorker  
        .register('/service-worker.js', { scope: '/' })  
        .then((registration) => {  
          console.log(  
            'Service worker registered successfully. Scope:',  
            registration.scope  
          );  
        })  
        .catch((error) => {  
          console.error('Service worker registration failed:', error);  
        });  
    }  
  }, []);  
  
  return ;  
}

Хук useEffect запускается при маунте компонента. В примере указывается scope: ‘/‘, то есть сервисный работник контролирует все ресурсы внутри корня. При необходимости можно сузить scope (например, ‘/products’).

Установка и активация в public/service-worker.js

Добавьте файл public/service-worker.js с простыми слушателями install и activate:

const installEvent = () => {  
  self.addEventListener('install', () => {  
    console.log('service worker installed!!!!');  
  });  
};  
  
installEvent();  
   
const activateEvent = () => {  
  self.addEventListener('activate', () => {  
    console.log('service worker activated!!!');  
  });  
};  
  
activateEvent();

Чтобы проверить регистрацию, запустите dev сервер:

npm run dev

Откройте DevTools в Chrome и перейдите во вкладку “Application”, затем в раздел “Service Workers” — там вы увидите зарегистрированный сервисный работник.

Вкладка Service Workers в инструментах разработчика Chrome: установленный и активный сервис-воркер

После успешной регистрации можно добавлять функции: кэширование, background sync, push.

Кэширование ресурсов с помощью сервисного работника

Кэширование активов улучшает производительность: ресурсы загружаются быстрее и приложение лучше работает при плохом соединении.

Пример простого runtime‑кэширования (вставьте в service-worker.js):

const cacheName = 'test-cache';  
  
self.addEventListener('fetch', (event) => {  
  event.respondWith(  
    caches.match(event.request).then((cachedResponse) => {  
      return cachedResponse || fetch(event.request).then((response) => {  
        return caches.open(cacheName).then((cache) => {  
          cache.put(event.request, response.clone());  
          return response;  
        });  
      });  
    })  
  );  
});

Логика: если есть совпадение в кэше — вернуть его; иначе — получить по сети, ответить клиенту и сохранить копию в кэше.

Откройте DevTools → вкладка “Application” → секция “Cache Storage” чтобы увидеть сохранённые ресурсы. Отметьте “Offline” в разделе Service Workers и перезагрузите страницу, чтобы симулировать офлайн‑режим.

Хранилище кеша в инструментах разработчика Chrome с перечнем кэшированных ресурсов.

Стратегии кэширования и когда их использовать

Общие стратегии кэширования:

Cache First (кэш в приоритете). Хорошо для статических ресурсов (изображения, шрифты). Быстро, но может отдавать устаревшие данные.
Network First (сеть в приоритете). Подходит для динамического контента (API) — сначала пробуем сеть, если не удалось — возвращаем кэш.
Stale‑While‑Revalidate. Отдаём кэш мгновенно, параллельно обновляем кэш из сети и при следующем запросе возвращаем свежую версию.
Cache Only / Network Only. Узкоспециализированные случаи.

Выбор стратегии зависит от характера ресурса и требований к актуальности данных.

Important: для приложений с личными данными избегайте бездумного кэширования ответов API, содержащих PII.

Когда сервисные работники не подходят

Большинство серверных SSR‑страниц (которые всегда должны быть актуальны) не выигрывают от агрессивного кэширования HTML.
Системы с высокими требованиями к консистентности данных (финансы, трейдинг) — кэширование может навредить.
Если команда не готова к поддержке жизненного цикла версий SW — возникают проблемы с обновлениями и баги у пользователей.

Альтернативы и дополнения

Workbox: библиотека, автоматизирующая создание и управление правилами кэширования (преднастройки для разных стратегий).
Server‑Side Rendering (SSR) и CDN: ускоряют доставку контента без сложной логики SW.
App Shell + ISR (Incremental Static Regeneration) в Next.js — гибридный подход для быстрой загрузки UI.

Безопасность и приватность

HTTPS: сервисные работники работают только по защищённому протоколу (или на localhost). Это обязательное требование.
Ограничьте scope: не давайте SW доступ к путям, которые им не нужны.
CSP и Subresource Integrity: применяйте Content Security Policy и SRI для внешних скриптов.
Не кэшируйте PII и данные без явного согласия пользователя. Добавляйте логику управления сроками хранения и удалением.

Мини‑методология внедрения (шаги)

Анализ: определите, какие ресурсы выигрывают от кэша (статические vs динамические).
Настройка: добавьте базовую регистрацию SW в _app.js и положите service-worker.js в public.
Стратегия: реализуйте для каждой группы ресурсов подходящую стратегию кэширования.
Тестирование: эмулируйте офлайн, проверяйте обновления версии, тестируйте регрессию.
Мониторинг: отслеживайте ошибки SW, метрики загрузки и поведение (через логирование или APM).
Обратная связь: собирайте фидбэк от пользователей (проблемы с обновлением/кэшем).

Ролевые чек‑листы

Разработчик:

Добавить регистрацию SW в глобальный файл.
Реализовать логику кэширования.
Обеспечить корректную обработку обновлений версии.

DevOps:

Убедиться, что сайт обслуживается по HTTPS.
Настроить CI/CD так, чтобы public/service-worker.js деплоился корректно.

QA:

Проверить установку, активацию и обновление SW.
Смоделировать офлайн, медленную сеть, конфликтные версии кэша.

Product/PO:

Утвердить список данных, которые можно кэшировать.
Определить требования к офлайн‑поведению и времени жизни кэша.

SOP для деплоя сервисного работника

Подготовьте новую версию service-worker.js с изменённым именем кэша (включите версию в имя как маркер).
Закоммитьте изменения в репозиторий и прогоните тесты.
Деплойте на staging, проверьте регистрацию и кэширование.
Переключите на production в час низкой нагрузки.
Мониторьте логи и обратную связь.
В случае проблем — откатить файл service-worker.js к предыдущей версии и увеличить версию кэша.

Критерии приёмки

SW регистрируется в 100% тестовых окружений (localhost/staging/production).
Записи кэша видны в DevTools → Application → Cache Storage.
При эмуляции офлайн приложение корректно отображает заранее закэшированные ресурсы.
Нет утечек персональных данных в Cache Storage.

Тест‑кейсы и сценарии проверки

Установка: открыть страницу, убедиться, что в DevTools появился SW и событие install логируется.
Активация: обновление SW — проверить событие activate и удаление старых кэшей.
Offline: отметить “Offline” в DevTools и проверить, что базовый интерфейс работает.
Обновление: развернуть новую версию SW с новой меткой кэша; проверить, что новая версия применяется корректно и старые записи удаляются.

Матрица совместимости и миграционные советы

Поддерживается в современных браузерах (Chrome, Firefox, Edge, Safari с ограничениями). Для Safari есть особенности в реализации background sync и push.
Тестируйте в целевых браузерах и мобильных WebView, так как поведение может отличаться.
Для сложных сценариев используйте Workbox или библиотеку с проверенной кросс‑браузерной реализацией.

Ментальные модели и зрелость

Модель «Proxy»: думайте о SW как о прокси между клиентом и сетью — он может отвечать, кэшировать или делегировать запрос.
Уровни зрелости:
- Начальный: регистрация + простое runtime кэширование статики.
- Средний: продуманная стратегия кэширования для API/ресурсов, управление версиями кэша.
- Продвинутый: background sync, push, аналитика поведения офлайн‑пользователей.

Факт‑бокс: ключевые моменты

SW выполняется в фоне и не блокирует UI.
SW защищён: требует HTTPS (кроме localhost).
Scope определяет, какие URL контролирует SW.

Практические советы и подводные камни

Всегда тестируйте поведение обновления (новая версия SW не всегда сразу активируется у пользователей).
Используйте семантику версий в имени кэша для упрощённого отката и очистки: e.g. ‘app-cache-v2’.
Не храните в Cache Storage чувствительные данные.
Обрабатывайте ошибки при fetch (включая 4xx/5xx) и не кэшируйте ошибочные ответы.

Короткое объявление (для команды или сайта)

Добавлен базовый сервисный работник для Next.js: теперь приложение регистрирует SW при загрузке, реализовано рантайм‑кэширование статических ресурсов и базовые хуки жизненного цикла (install/activate). Проверьте работу в DevTools → Application → Service Workers.

Резюме

Сервисные работники дают большой выигрыш в производительности и устойчивости приложения, но требуют внимания к жизненному циклу, версиям кэша и безопасности. Для Next.js наиболее безопасный путь — начать с простой регистрации и постепенного добавления стратегий кэширования, сопровождать изменения тестами и мониторингом.

Notes