Жизненный цикл service worker и стратегии кеширования

Вы деплоите новый service worker, перезагружаете страницу — и видите старое поведение. Никакой ошибки: новый воркер установился нормально. Он просто ждёт, пока вы закроете все вкладки.

Регистрация и область видимости

navigator.serviceWorker.register('sw.js') запускает жизненный цикл. Scope по умолчанию — директория sw.js: воркер по пути /app/sw.js контролирует все страницы под /app/. Можно сузить: register('sw.js', { scope: '/app/checkout/' }).

У service worker нет DOM и нет постоянного глобального состояния — браузер убивает и перезапускает его свободно ради экономии памяти. Всё постоянное состояние живёт в Cache API или IndexedDB. Он работает на собственном потоке, независимо от любой страницы — он может получать push-уведомления и запускать background sync даже когда нет ни одной открытой вкладки.

Жизненный цикл

register → install → [waiting] → activate → idle ↔ running

install — срабатывает, когда браузер впервые парсит новый воркер. Здесь выполняется pre-cache app shell:

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('v1').then(cache => cache.addAll(['/app.js', '/index.html']))
  );
});

event.waitUntil(promise) говорит браузеру: не переходить дальше по жизненному циклу, пока промис не завершится. Забудьте его — браузер может убить воркер на полпути к заполнению кеша.

waiting — свежеустановленный воркер не берёт под контроль уже открытые страницы по умолчанию. Он ждёт, пока каждая вкладка со старым воркером закроется. Это предотвращает ситуацию, когда страница запускает старый HTML с новыми кешированными ресурсами.

activate — срабатывает после ожидания. Здесь удаляются старые кеши:

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.filter(k => k !== 'v1').map(k => caches.delete(k)))
    )
  );
});

fetch — перехватывает каждый сетевой запрос в области видимости. event.respondWith(response) определяет, что получит страница.

Практика: Cache-Control: no-cache для sw.js

Браузер кеширует файл sw.js по HTTP-кешированию — по умолчанию до 24 часов. Это означает: вы задеплоили новый воркер, но браузер подаёт пользователям старый файл в течение суток, и обновление до них не доходит.

Правильная настройка — отдавать sw.js с заголовком Cache-Control: no-cache (или max-age=0, must-revalidate). Тогда браузер каждый раз на навигации перепроверяет файл у сервера и видит обновление немедленно.

skipWaiting + clients.claim()

Чтобы активироваться немедленно, не дожидаясь закрытия вкладок:

// install-обработчик
self.skipWaiting();

// activate-обработчик
self.addEventListener('activate', event => {
  event.waitUntil(clients.claim());
});

skipWaiting() — новый воркер активируется немедленно, даже при открытых страницах. clients.claim() — новый воркер берёт под контроль все открытые страницы в своей области.

Используйте осознанно. Без content-hashed имён файлов ресурсов skipWaiting — это способ задеплоить version-mismatch failure mode.

Стратегии кеширования

Внутри fetch-обработчика выбирается стратегия в зависимости от типа запроса:

Cache-first — смотреть в кеш, при промахе идти в сеть. Подходит для immutable content-hashed статики (app.4f3a1c.js):

event.respondWith(caches.match(event.request).then(r => r || fetch(event.request)));

Network-first — сначала сеть, при сбое — кеш. Подходит для API-ответов, которые должны быть свежими, но должны деградировать gracefully офлайн.

Stale-while-revalidate — отдать кешированную копию немедленно, в фоне запросить свежую и обновить кеш. Подходит для контента, который может быть слегка устаревшим (аватары, ленты).

Network-only и cache-only — вырожденные края.

Библиотека Workbox даёт эти стратегии декларативно с сопоставлением маршрутов, но сами стратегии — это десять строк кода fetch-обработчика.