Service Workers в Next.js — руководство

Service workers позволяют улучшить производительность и офлайн-поведение Next.js-приложений через кэширование, перехват запросов и фоновые задачи. В статье показано, как зарегистрировать service worker, установить и активировать его, настроить кэширование и включить простые практики безопасности и тестирования.

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

Service workers — это скрипты, которые работают в фоне и дают современным веб-приложениям мощные возможности кэширования и другие функции, приближающие опыт использования к нативным приложениям. Это ключевой компонент при создании Progressive Web Apps (PWA).

Что такое service worker

Service worker — это разновидность web worker на JavaScript, который выполняется отдельно от основного потока JavaScript и не блокирует интерфейс. Проще: он действует как фоновый прокси между приложением и сетью и способен перехватывать сетевые запросы, отвечать кешированными ресурсами и выполнять фоновые задачи.

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

Важно понимать две ключевые фазы работы service worker: регистрация и активация. Сначала браузер регистрирует скрипт service worker, затем этот скрипт устанавливается и активируется — в процессе можно реализовать логику предзагрузки ресурсов, миграции кеша и очистки устаревших данных.

Главное, что умеют service workers

Кэширование ресурсов для ускорения загрузки и работы в офлайн-режиме.
Перехват и модификация запросов/ответов между приложением и сетью.
Фоновые задачи: синхронизация, push-уведомления, фоновая отправка данных.
Повышение устойчивости при медленном или нестабильном соединении.

Когда service worker особенно полезен

PWA и приложения, где важна скорость загрузки и офлайн-доступ.
Приложения с большим количеством статических ассетов (изображения, скрипты, шрифты).
Сценарии с частыми потерями соединения у пользователей.

Регистрация service worker: базовый пример

Ниже показан минимальный пример регистрации service worker в браузере. Этот код должен выполняться в клиентской части приложения (в окружении, где доступен navigator).

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

registerServiceWorker();

Код проверяет поддержку API service worker в браузере и регистрирует скрипт по указанному пути. После успешной регистрации браузер начнёт процесс установки и активации service worker.

Установка и активация service worker

Для обработки событий установки и активации слушатели добавляются прямо в файле service worker. Они позволяют выполнить предзагрузку ассетов, очистку старых кешов или миграцию данных.

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

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

Вы можете подключить эти обработчики после регистрации. Как правило, установка логики install/activate происходит внутри самого файла service worker (см. ниже раздел про public/service-worker.js).

Создание проекта Next.js и места для service worker

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

npx create-next-app next-project

Добавление service worker в Next.js обычно требует двух шагов:

Зарегистрировать service worker в глобальной части приложения (например, в src/pages/_app.js).
Положить файл service worker в публичную папку, чтобы браузер мог запросить его по относительному пути.

Регистрация service worker в Next.js

Один из подходов — регистрировать service worker в компоненте _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 ;
}

Пара заметок:

Опция scope: ‘/‘ даёт service worker контроль над всем сайтом. При необходимости указывайте более узкий scope, например ‘/products’.
Регистрация должна происходить в браузерном контексте, не на сервере. В Next.js проверяйте, что код выполняется на клиенте (useEffect обеспечивает это).

Пример файла service worker

Создайте public/service-worker.js и добавьте базовую логику установки и активации:

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

installEvent();

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

activateEvent();

Этот код логирует стадии установки и активации. На практике на событии install обычно предзакладывают важные ассеты в кеш, а на activate — очищают устаревшие кеши.

Тестирование в режиме разработки

Запустите dev-сервер и откройте приложение в браузере:

npm run dev

Откройте инструменты разработчика (например, Chrome DevTools) и перейдите на вкладку Приложение появится секция Service Workers. Там вы увидите зарегистрированный и активированный worker.

Вкладка Service Workers в инструментах разработчика Chrome, показывающая активный service worker

После успешной регистрации можно реализовать кэширование, фоновые синхронизации или push-уведомления.

Простейшее кэширование ресурсов

Кэширование помогает отдавать ресурсы из локального хранилища браузера и ускоряет повторные загрузки. В service-worker.js можно реализовать стратегию «cache falling back to network»:

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 в разделе Cache Storage можно просмотреть список сохранённых ассетов и симитировать офлайн, включив опцию Offline в блоке Service Workers.

Список кэшированных ассетов в Cache Storage Developer Tools

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

Cache First: отдавать из кеша, если есть; иначе сеть. Полезно для статических ассетов (шрифты, изображения).
Network First: сначала сеть, затем кеш. Хорошо для динамичных данных (ленты, API), когда нужна свежесть.
Stale-While-Revalidate: отдать кеш затем обновить в фоне и записать новый кеш. Баланс между скоростью и актуальностью.

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

Когда service worker — не лучший выбор

Для простых сайтов с минимальным количеством ассетов и низкой чувствительностью к офлайн-режиму — накладные расходы могут быть излишними.
Для очень динамичных данных без стратегии обновления кеша service worker может выдавать устаревшую информацию.
Если команда не готова к тестированию и поддержке — ошибки в логике кеша приводят к сложным багам у пользователей.

Альтернативы и их сочетание со service worker

CDN и правильные HTTP-заголовки Cache-Control: работают на уровне сети и важны независимо от service worker.
Server-side rendering (SSR) и edge-кеширование: уменьшают время до первого байта и дополняют client-side кэш.
Workbox: библиотека от Google, упрощающая создание более сложных стратегий кэширования и генерацию манифестов для предзагрузки.

Часто лучшие результаты даёт комбинация: CDN + строгие кеш-заголовки + service worker для офлайн и переработки отдельных маршрутов.

Ментальные модели и эвристики при проектировании

Разделяй по частоте изменения: статическое (изображения, шрифты) — в Cache First; динамическое (лента) — Network First.
«Fail gracefully»: если кеш повреждён или отсутствует сеть, приложение должно корректно показывать сообщение пользователю.
Минимизируй состояние в кешах: храните ненужные данные недолговечно и добавляйте политики инвалидации.

Пошаговый playbook для внедрения service worker в Next.js

Прототип: реализуйте минимальную регистрацию и логирование install/activate.
Добавьте простое кэширование статических ассетов (Cache First).
Протестируйте поведение в офлайн-режиме.
Добавьте стратегию для API (Network First или Stale-While-Revalidate).
Добавьте логи уведомлений об обновлении версии и миграции кеша.
Автоматизируйте тесты и добавьте мониторинг ошибок.

Дерево решений для выбора стратегии

flowchart TD
  A[Нужен офлайн?] -->|Да| B{Тип ресурса}
  A -->|Нет| C[Достаточен CDN и Cache-Control]
  B -->|Статический| D[Cache First]
  B -->|Динамический| E[Network First]
  D --> F[Рассмотреть предзагрузку при install]
  E --> G[Добавить таймаут и fallback к кешу]

Чек-листы по ролям

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

Проверить поддержку navigator.serviceWorker.
Разместить файл в public и корректно задать scope.
Реализовать стратегии кэширования для разных типов ресурсов.
Добавить обработчики обновления и миграции кеша.

QA:

Тесты офлайн/онлайн: включение Offline в DevTools.
Проверка обновления версий service worker.
Проверка сценариев с повреждённым кешем.

DevOps:

Проверить заголовки Cache-Control на CDN.
Обеспечить корректную доставку service-worker.js без динамической подстановки контента.

Product Manager:

Определить требования к офлайн-режиму и допустимой устаревшей информации.
Приоритизировать ресурсы для предзагрузки.

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

Service worker успешно регистрируется и активируется в поддерживаемых браузерах.
Статические ресурсы отдаются из кеша при повторных запросах.
В офлайн-режиме приложение остаётся функциональным для ключевых сценариев.
Обновления версии service worker корректно заменяют устаревшие кеши без потери функциональности.

Тестовые сценарии и приёмочные тесты

Регистрация: открыть приложение и убедиться в наличии service worker в DevTools.
Кэширование: первый заход — ресурсы кешируются; второй заход — ресурсы отдаются из кеша.
Офлайн: включить Offline и проверить основные пути (загрузка главной страницы, просмотр ранее кешированного контента).
Обновление: выложить новую версию service-worker.js с увеличенным cacheName, открыть страницу и убедиться, что старый кеш удалён.

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

Service worker работает в контексте происхождения (origin), поэтому файл должен обслуживаться по тому же домену и протоколу (HTTPS обязателен, кроме localhost).
Не храните в Cache Storage или IndexedDB чувствительные персональные данные без шифрования и уважения правил конфиденциальности.
Убедитесь в корректной политике CORS для запросов, которые будут перехватываться.

Миграция и совместимость

Всегда тестируйте на целевых браузерах. Поддержка service worker есть в современных браузерах, но поведение может отличаться в старых версиях мобильных браузеров.
Если нужна более простая поддержка старых окружений, реализуйте graceful fallback: приложение должно работать и без service worker.

Краткий глоссарий

Service worker: фоновый скрипт-прокси между приложением и сетью.
Cache Storage: API браузера для хранения ответов сети.
Scope: область URL, над которой контролирует service worker.
Install/Activate: жизненные события service worker для предзагрузки и очистки.

Заключение

Service workers дают мощные возможности по улучшению скорости загрузки и устойчивости Next.js-приложений, но требуют продуманного дизайна стратегий кэширования и внимательного тестирования. Начните с малого: зарегистрируйте базовый worker, добавьте кэширование статических ассетов и постепенно расширяйте функциональность, следя за безопасностью и пользовательским опытом.

Важно: тщательно продумывайте стратегии обновления кешей и инструменты обратной связи для пользователей при релизе новых версий.

Полезные варианты для дальнейшего развития: подключение Workbox для снижения сложности, интеграция с push-сервисами и автоматизация тестов для различных сценарием сетевой доступности.