Обновление воркера: старая версия держит вкладки

Установленный воркер не ходит на сервер за новостями по таймеру. Проверку запускают события, и их три. Главное — навигация: всякий раз, когда человек открывает или перезагружает страницу из области действия, браузер заново скачивает sw.js и сравнивает его с установленным. Второй повод — всё, что будит воркер без навигации: push, sync и даже обычные запросы страницы за данными и картинками. Таких событий бывает очень много, поэтому по ним проверка идёт, только если с прошлой прошло больше суток, — так записано в спецификации. Третий повод — явный вызов registration.update() из кода страницы.

Что считать новой версией, браузер решает без вашей помощи: номер в константе и дата файла ему безразличны, он сравнивает байты. Предскажите пять строк, прежде чем запускать.

function checksForUpdate(reason, hoursSinceLastCheck) {
  if (reason === "навигация" || reason === "update()") return true;
  return hoursSinceLastCheck > 24;
}

// браузер сравнивает байты; у строк это то же, что сравнить их целиком
function isNewVersion(installed, downloaded) {
  return installed !== downloaded;
}

console.log("навигация, прошла минута:", checksForUpdate("навигация", 0.02));
console.log("push, прошло 3 часа:", checksForUpdate("push", 3));
console.log("push, прошло 30 часов:", checksForUpdate("push", 30));

const installed = "const VERSION = 'board-v3'; // собрано 12.09.2026 в 18:40";
const sameFile = "const VERSION = 'board-v3'; // собрано 12.09.2026 в 18:40";
const rebuilt = "const VERSION = 'board-v3'; // собрано 13.09.2026 в 09:15";

console.log("выложили тот же файл, новая версия?", isNewVersion(installed, sameFile));
console.log("пересобрали без единой правки, новая версия?", isNewVersion(installed, rebuilt));

Последняя строка — ловушка из жизни. Если сборка вписывает в sw.js дату или номер сборки, новой версией становится каждая сборка, даже когда в коде не поменялось ни символа, и пользователи будут получать «Доступна новая версия» после каждой выкладки. Обратное тоже бывает: код, который воркер подключает через importScripts, поменялся, а сам sw.js — нет. Такое отличие проверка тоже замечает, но с оговоркой про HTTP-кеш; её разберём в последнем разделе.

На настоящей доске проверку видно в журнале сервера. Воркер уже установлен; доску перезагружают в первой вкладке, а потом открывают во второй:

$ node serve.mjs s1 3387

На каждую навигацию — свой GET /sw.js, причём не одновременно со страницей, а на пару секунд позже: так Chrome 152 ставит эту проверку. Кода и стилей в журнале нет, их отдал кеш воркера. А sw.js идёт мимо кеша воркера всегда, иначе старый воркер сам отвечал бы на вопрос о своей замене. Мимо HTTP-кеша браузера он тоже идёт: при настройках регистрации по умолчанию браузер, проверяя обновление, обязательно спрашивает сервер, какими бы заголовками файл ни отдавался. Это тоже проверим в последнем разделе.

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

Допустим, браузер нашёл отличие. Новый воркер скачан и идёт по знакомой лестнице: installing, installed. Дальше он останавливается. Пока у старой версии есть хоть одна страница, новая ждёт в состоянии installed, а в API лежит в registration.waiting. Причина та же, по которой воркер не забирает страницу посреди её жизни: открытая доска загружалась со старым кешем и по старым правилам, и подменить их у неё под ногами значит получить страницу, собранную из двух версий.

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

function createSite(active) {
  let waiting = null;
  let pages = 0;

  function tryActivate() {
    if (!waiting || pages > 0) return;
    active.to("redundant");
    waiting.to("activating");
    waiting.to("activated");
    active = waiting;
    waiting = null;
  }

  function arrive(text) {
    pages += 1;
    console.log(text + ", обслуживает " + active.name);
  }

  function leave(text) {
    pages -= 1;
    console.log(text);
    tryActivate();
  }

  return {
    open: (tab) => arrive(tab + " открыта"),
    close: (tab) => leave(tab + " закрыта"),
    reload(tab) {
      arrive(tab + ": новая страница после перезагрузки");
      leave(tab + ": старая страница выгружена");
    },
    install(fresh) {
      fresh.to("installed");
      waiting = fresh;
      tryActivate();
    }
  };
}

const v3 = createRegistration("v3");
v3.to("installed");
v3.to("activating");
v3.to("activated");

const site = createSite(v3);
site.open("вкладка 1");
site.open("вкладка 2");

site.install(createRegistration("v4"));

site.reload("вкладка 1");
site.close("вкладка 2");
site.reload("вкладка 1");
site.close("вкладка 1");
site.open("вкладка 1");

Всё решает порядок внутри reload. Перезагрузка — это навигация, и запрос новой страницы уходит, пока старая ещё открыта: новый документ получает воркера раньше, чем выгружается прежний. Страниц у старой версии на миг становится две, а не ноль, и новая остаётся ждать. Выпускает её только момент, когда не осталось ни одной: вкладку закрыли или увели на другой сайт.

Проверим на настоящей доске. app.js в этом опыте короткий: страница сообщает о найденной новой версии и спрашивает у служебного адреса /sw-version, кто обслуживает её запросы. На этот адрес отвечает сам воркер: в его обработчик fetch для опыта добавлена ветка if (path === "/sw-version") event.respondWith(new Response(VERSION)), а без воркера сервер отдаёт 404. Остальное — проверка, которую я вставлял в консоль DevTools. Между шагами на сервер выкладывается sw.js, в котором поменялась одна строка — VERSION стала board-v4.

navigator.serviceWorker.register("/sw.js").then((registration) => {
  registration.addEventListener("updatefound", () => {
    const fresh = registration.installing;
    console.log("updatefound: браузер нашёл новый sw.js");
    fresh.addEventListener("statechange", () => console.log("новый воркер:", fresh.state));
  });
});

async function show() {
  const answer = await fetch("/sw-version");
  console.log("запросы страницы обслуживает:", answer.ok ? await answer.text() : "никто, воркера нет");
}

show();

// в консоли DevTools:
const registration = await navigator.serviceWorker.getRegistration();
console.log("active:", registration.active && registration.active.state, "| waiting:", registration.waiting && registration.waiting.state);
console.log("кеши:", (await caches.keys()).join(", "));
await registration.update();

Читаем по шагам. При первом открытии updatefound тоже пришёл: для браузера первая установка — такая же «новая версия», запомним это до задач. После update() новый воркер нашли обе вкладки: updatefound приходит во все открытые страницы сайта. Его установка уже прошла, в хранилище лежат оба кеша, board-v3 и board-v4, но activate новой версии не запускался, и запросы по-прежнему обслуживает старая.

Перезагрузка при двух вкладках ничего не меняет — это ожидаемо. Но и после того как вторую вкладку закрыли, перезагрузка единственной оставшейся тоже ничего не меняет: ровно то перекрытие, которое мы собрали в миниатюре. Сработал только уход на другой сайт: вернувшись, доска получила board-v4, а старый кеш исчез — его убрал activate новой версии.

Перезагрузка не выпускает новую версию. Она включается, когда закрыты или уведены с сайта все вкладки: у одного человека через минуту, а у того, кто держит доску открытой неделями, через неделю.

У ожидания есть лекарство в одну строку — self.skipWaiting() в обработчике install. Новая версия перестаёт ждать и сразу проходит в activating, а открытые страницы переходят под её управление прямо на ходу. clients.claim() для этого не нужен: страницы и так принадлежат этой регистрации, у неё просто сменился активный воркер.

Чем это грозит, видно на доске, у которой есть ленивая часть. Пусть в этом варианте у неё появился график, и грузится он через import() — динамический импорт из части I: код графика лежит отдельным файлом chart.1a2b3c4d.js, в SHELL версии board-v3 он стоит рядом с app.3f9a1c2b.js, но страница просит его только по нажатию. Выходит board-v4. Сборщик дал файлам новые имена, старые при выкладке удалены, а воркер написан наспех:

const VERSION = "board-v4";
const OFFLINE = "/offline.html";
const SHELL = ["/", OFFLINE, "/assets/app.7e4d2f90.js", "/assets/chart.9f8e7d6c.js", "/assets/board.5c7d0a11.css"];

self.addEventListener("install", (event) => {
  // «чтобы никто не ждал»: новая версия включается сразу после установки
  self.skipWaiting();
  event.waitUntil(caches.open(VERSION).then((cache) => cache.addAll(SHELL)));
});

// activate, как и раньше, удаляет все кеши, кроме своего

Прежде чем смотреть на живой браузер, соберём это миниатюрой. Маршрутизатор со всеми ветками из прошлых статей лежит на странице примера. Старая страница, которой управлял board-v3, просит график, а меняются два условия: вызван ли skipWaiting и остались ли старые файлы на сервере. Предскажите три строки.

const BASE = "https://board.example";
const V3_FILES = ["/assets/app.3f9a1c2b.js", "/assets/chart.1a2b3c4d.js"];
const V4_FILES = ["/assets/app.7e4d2f90.js", "/assets/chart.9f8e7d6c.js"];

// настоящий fetch на 404 не отклоняется, но import() по такому ответу падает — в модели это сразу отказ
function createServer(network, paths) {
  return {
    fetch(url) {
      const path = new URL(url).pathname;
      return paths.includes(path) ? network.fetch(url) : Promise.reject(new Error("404 " + path));
    }
  };
}

async function fillCache(paths, server) {
  const cache = createCache();
  for (const path of paths) cache.put({ method: "GET", url: BASE + path }, await server.fetch(BASE + path));
  return cache;
}

async function oldPageOpensChart(label, { skipWaiting, keepOldFiles }) {
  const network = createNetwork();
  const versions = new Map();
  versions.set("board-v3", await fillCache(V3_FILES, createServer(network, V3_FILES)));

  const server = createServer(network, keepOldFiles ? [...V3_FILES, ...V4_FILES] : V4_FILES);
  versions.set("board-v4", await fillCache(V4_FILES, server));

  let controller = "board-v3";
  if (skipWaiting) {
    // так делает activate новой версии: прошлые кеши больше не нужны
    versions.delete("board-v3");
    controller = "board-v4";
  }

  const chart = { method: "GET", url: BASE + "/assets/chart.1a2b3c4d.js", mode: "cors" };
  try {
    const answer = await handleFetch(chart, versions.get(controller), server);
    console.log(label + ":", answer.body, "|", answer.from, "|", controller);
  } catch (error) {
    console.log(label + ": импорт упал,", error.message, "|", controller);
  }
}

async function main() {
  await oldPageOpensChart("ждёт очереди", { skipWaiting: false, keepOldFiles: false });
  await oldPageOpensChart("skipWaiting, старое удалено", { skipWaiting: true, keepOldFiles: false });
  await oldPageOpensChart("skipWaiting, старое оставлено", { skipWaiting: true, keepOldFiles: true });
}

main();

Первая строка — то, ради чего новая версия ждала: старая страница живёт под старым воркером, и всё, что может ей понадобиться, лежит в его кеше. Во второй платим за skipWaiting: activate новой версии уже убрал board-v3, в board-v4 файла со старым хешем нет и быть не может, а на сервере его удалили. Третья строка уточняет диагноз: ломает не сам skipWaiting, а его сочетание с удалёнными файлами. Если старые файлы какое-то время полежат на сервере, страница дотянется до них сетью — правда, только пока сеть есть.

Теперь то же на живом браузере, три прогона с чистым профилем. В каждом доску открывают дважды, на сервер выкладывают board-v4, в консоли зовут update(), печатают список кешей и нажимают «График». Код страницы — старый, из board-v3:

navigator.serviceWorker.register("/sw.js");

navigator.serviceWorker.addEventListener("controllerchange", () => {
  console.log("controllerchange: у страницы сменился воркер");
});

document.querySelector("#chart").addEventListener("click", async () => {
  try {
    const chart = await import("/assets/chart.1a2b3c4d.js");
    chart.draw();
  } catch (error) {
    console.log("график не загрузился:", error.name + ":", error.message);
  }
});

// в консоли DevTools:
await (await navigator.serviceWorker.getRegistration()).update();
console.log("кеши:", (await caches.keys()).join(", "));
// и нажали «График»

Первый прогон — без skipWaiting: график нарисовался, хотя на сервере его файла уже нет, — его отдал кеш старой версии. Во втором страница получила controllerchange и тут же лишилась своего кеша, а в журнале сервера на нажатие осталась одна строка:

$ node serve.mjs s4 3387

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

skipWaiting не ускоряет обновление, а меняет договор: страница, собранная для одной версии, дальше работает с кешем и правилами другой. Безопасен он, только если страница об этом узнаёт и сразу перезагружается.

Правильная схема берёт у skipWaiting скорость, но убирает переключение под ногами. Воркер не включает себя сам, а ждёт команды. Страница, узнав, что новая версия ждёт, показывает «Доступна новая версия». Человек нажимает — страница посылает ждущему воркеру сообщение, и тот вызывает skipWaiting. Когда страница перейдёт к новому воркеру, придёт событие controllerchange, и страница перезагрузится уже целиком новой версией. В sw.js для этого нужен один обработчик:

self.addEventListener("message", (event) => {
  if (event.data === "SKIP_WAITING") self.skipWaiting();
});

Имя сообщения — не часть API, а договорённость воркера со своей же страницей; SKIP_WAITING — просто привычное имя.

Остаются соседние вкладки. controllerchange придёт во все, но уже после переключения, когда соседняя страница оказалась под новым воркером с той самой бедой из прошлого раздела. Предупредить их можно раньше, через BroadcastChannel — он уже встречался в статье про хранилище как способ переговариваться вкладкам одного сайта. Между вкладками в песочнице его не показать: у каждого примера своё непрозрачное происхождение, и два таких кадра друг друга не слышат. Поэтому соберём маленькую шину в памяти и сверим её с настоящим каналом там, где он работает, — внутри одного документа.

function createBus() {
  const ends = [];
  return {
    channel() {
      const end = { onmessage: null };
      end.postMessage = (data) => {
        for (const other of ends) {
          if (other === end) continue;
          setTimeout(() => other.onmessage && other.onmessage({ data }), 0);
        }
      };
      end.close = () => ends.splice(ends.indexOf(end), 1);
      ends.push(end);
      return end;
    }
  };
}

const sleep = (ms) => new Promise((done) => setTimeout(done, ms));

async function talk(label, first, second) {
  first.onmessage = (event) => console.log(label, "первая получила:", event.data);
  second.onmessage = (event) => console.log(label, "вторая получила:", event.data);
  first.postMessage("updating");
  console.log(label, "первая отправила");
  await sleep(50);
  first.close();
  second.close();
}

async function main() {
  await talk("канал:", new BroadcastChannel("board-updates"), new BroadcastChannel("board-updates"));
  const bus = createBus();
  await talk("шина:", bus.channel(), bus.channel());
}

main();

Шина повторяет два свойства канала, на которых стоит схема. Отправитель своего сообщения не получает — вкладке, нажавшей «Обновить», не нужно узнавать об этом от самой себя. А получатель узнаёт о сообщении не посреди кода отправителя, а отдельной задачей, когда тот уже дописал свои строки.

Теперь вся схема миниатюрой: автомат и шина лежат на странице, две вкладки видят плашку, нажимают в A. Предскажите, в какой момент о переключении узнаёт B и где в выводе встанет controllerchange.

function createWorkerSide(active, waiting, tabs) {
  return {
    postMessage(data) {
      if (data !== "SKIP_WAITING") return;
      // у воркера свой поток: сообщение доходит до него и переключение наступает не сразу, а отдельными задачами
      setTimeout(() => {
        active.to("redundant");
        waiting.to("activating");
        for (const tab of tabs) tab.onControllerChange();
        waiting.to("activated");
      }, 20);
    }
  };
}

function createTab(name, bus, worker) {
  const channel = bus.channel();
  let updatingHere = false;
  const say = (text) => console.log(name + ": " + text);

  channel.onmessage = (event) => {
    if (event.data === "updating") say("соседняя вкладка обновляется, черновик сохранён");
  };

  return {
    offerUpdate: () => say("плашка «Доступна новая версия»"),
    clickUpdate() {
      say("нажали «Обновить»");
      updatingHere = true;
      channel.postMessage("updating");
      worker.postMessage("SKIP_WAITING");
    },
    onControllerChange() {
      if (updatingHere) say("controllerchange, перезагружаюсь");
      else say("controllerchange, плашка «Доска обновилась — перезагрузите вкладку»");
    }
  };
}

const v3 = createRegistration("v3");
["installed", "activating", "activated"].forEach((state) => v3.to(state));
const v4 = createRegistration("v4");
v4.to("installed");

const tabs = [];
const worker = createWorkerSide(v3, v4, tabs);
const bus = createBus();
tabs.push(createTab("A", bus, worker), createTab("B", bus, worker));

tabs.forEach((tab) => tab.offerUpdate());
tabs[0].clickUpdate();

Предупреждение по каналу пришло в B раньше, чем что-то произошло: у соседки было время сохранить черновик, пока у руля старый воркер. Сохранять черновик доска умеет с проекта части II: это flushSave из задачи статьи «Сохранение и восстановление доски». Задержка в 20 мс здесь условная, и порядок этот стандарт не обещает: канал и воркер — независимые очереди, и на стенде ниже канал выиграл гонку, а не воспользовался гарантией. Черновику проигрыш не страшен: flushSave пишет в localStorage, и воркер для этого не нужен. Потом — порядок самого переключения: старая версия уходит в redundant, новая проходит activating, страницы получают controllerchange, и только после activate наступает activated. A перезагружается, потому что нажимали в ней. B человека не перебивает: вдруг он там что-то печатает, поэтому она лишь просит перезагрузиться.

На настоящей доске добавим одно правило: невидимой вкладке спрашивать некого, и она перезагружается молча. Разметка плашки — <p id="update-banner" hidden>Доступна новая версия <button id="update">Обновить</button></p>, код страницы такой:

const channel = new BroadcastChannel("board-updates");
let updatingHere = false;

navigator.serviceWorker.register("/sw.js").then((registration) => {
  // новая версия могла встать в очередь ещё до этой загрузки
  if (registration.waiting && navigator.serviceWorker.controller) offerUpdate(registration.waiting);

  registration.addEventListener("updatefound", () => {
    const fresh = registration.installing;
    fresh.addEventListener("statechange", () => {
      if (fresh.state === "installed" && navigator.serviceWorker.controller) offerUpdate(fresh);
    });
  });
});

function offerUpdate(worker) {
  console.log("показали плашку «Доступна новая версия»");
  worker.addEventListener("statechange", () => console.log("новый воркер:", worker.state));
  document.querySelector("#update-banner").hidden = false;
  document.querySelector("#update").onclick = () => {
    updatingHere = true;
    channel.postMessage("updating");
    worker.postMessage("SKIP_WAITING");
  };
}

channel.addEventListener("message", (event) => {
  if (event.data !== "updating") return;
  // старый воркер ещё у руля: самое время сохранить несохранённое
  flushSave();
  document.querySelector("#update-banner").hidden = true;
  console.log("соседняя вкладка включает новую версию, черновик сохранён");
});

navigator.serviceWorker.addEventListener("controllerchange", () => {
  console.log("controllerchange, вкладка:", document.visibilityState);
  // в невидимой вкладке спрашивать некого: перезагружаем молча
  if (updatingHere || document.visibilityState === "hidden") location.reload();
  else console.log("показали плашку «Доска обновилась — перезагрузите вкладку»");
});

// flushSave() в опыте — упрощённая запись черновика в localStorage (на доске это flushSave(getState));
// show() печатает, кто обслуживает запросы

Всё по плану. Плашку показали обе вкладки. B узнала о переключении раньше, чем оно началось. Дальше порядок из миниатюры: redundant, activating, controllerchange, activated. A перезагрузилась, потому что нажимали в ней, B — потому что невидима. Обе вернулись уже под board-v4, а в хранилище остался один кеш.

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

Файлы с хешем в имени — хорошая привычка для кода и стилей, и её хочется по инерции приложить к самому воркеру: sw.5d1e8a42.js, при следующей сборке sw.b3c9f071.js. Проверим, что будет. Воркер в этом опыте отдаёт из кеша всё, включая саму страницу, — как в первой статье главы; так часто делают ради мгновенного открытия. Главное, что меняется между сборками, — строка регистрации:

// assets/app.3f9a1c2b.js в board-v3
navigator.serviceWorker.register("/sw.5d1e8a42.js");

// assets/app.7e4d2f90.js в board-v4, а sw.5d1e8a42.js с сервера удалён
navigator.serviceWorker.register("/sw.b3c9f071.js");

// в консоли DevTools в конце опыта:
const registration = await navigator.serviceWorker.getRegistration();
console.log("скрипт воркера:", registration.active.scriptURL);
console.log("ждёт своей очереди:", registration.waiting);
console.log("код страницы:", document.scripts[0].src);

$ node serve.mjs s6 3387

Это тупик, и выхода из него изнутри нет. Страницу отдаёт кеш старого воркера, в ней старый код, и он регистрирует старое имя. Браузер проверяет старый адрес, получает 404, а неудачная проверка ничего не меняет: работает прежний воркер. Новый sw.b3c9f071.js лежит на сервере, но знает о нём только новая index.html, до которой старый воркер не пускает. Выбраться человек может, очистив данные сайта, а вы — выложив новый воркер по старому адресу, который браузер продолжает проверять. С постоянным именем sw.js такой истории не бывает: браузер спрашивает тот же адрес и находит там новые байты.

Второе правило — про HTTP-кеш, и в нём есть кажущееся противоречие. Мы видели, что при проверке браузер идёт за sw.js на сервер всегда. Зачем тогда запрещать долгий кеш? Ответ — в файлах, которые воркер подключает через importScripts. Регистрация по умолчанию создаётся с updateViaCache: "imports": HTTP-кеш обходится для самого sw.js, но не для того, что он подключает.

importScripts("/router.js");
const VERSION = "board-v3";

self.addEventListener("fetch", (event) => {
  const path = new URL(event.request.url).pathname;
  if (path === "/sw-version") event.respondWith(new Response(VERSION + ", " + ROUTER));
});

// router.js
const ROUTER = "router 1";

$ node serve.mjs s5 3387

// выкладка c: sw.js не тронут, в router.js теперь "router 2"

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