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

Опубликовано: 31 июля 2025 г.

Начиная с Chrome 139, примите участие в новом пробном периоде использования общих рабочих процессов с расширенным временем жизни . В пробном периоде добавлена ​​новая опция extendedLifetime: true , позволяющая общим рабочим процессам существовать и после последней выгрузки документа.

Пример использования функции увеличения срока службы.

Многие сайты стремятся выполнить определенную работу, когда пользователь покидает страницу. Например, записать данные в хранилище или отправить их обратно на серверы для сохранения состояния или записи аналитических данных.

Веб-платформа предоставляет несколько API для решения более простых задач, но каждый из них имеет свои ограничения:

  • Синхронные API-функции JavaScript, такие как запись localStorage , выполняются до конца, прежде чем выгрузить текущую страницу.
  • fetch API имеет ряд опций, таких как keepalive , а с недавнего времени fetchLater , которые позволяют отправлять запросы в течение короткого периода времени после завершения выгрузки документа.

Однако эти ограничения распространяются только на синхронную работу, за исключением последнего запроса fetch . Они не позволяют использовать асинхронные API, такие как IndexedDB , Compression Streams или Web Crypto , для хеширования или шифрования. Многие API, особенно новые, являются асинхронными, чтобы избежать блокировки основного потока, поэтому невозможность использования этих API при выгрузке данных является ограничением.

Альтернативным вариантом является использование сервис-воркеров , которые существуют вне жизненного цикла отдельных страниц. Однако это довольно громоздкое решение, требующее от разработчиков более сложного жизненного цикла и управления, не говоря уже о дополнительных требованиях к процессам и памяти для пользователей. Кроме того, оно не соответствует основному сценарию использования сервис-воркеров (выступать в качестве прокси для сетевых запросов). Использование полноценных сервис-воркеров исключительно для выполнения некоторой работы при загрузке страницы кажется излишним.

Предложенное решение

API SharedWorker — это более лёгкий API, используемый для переноса работы с основного потока. Однако в настоящее время он не существует после завершения работы основного потока (когда выгружается последняя страница для этого потока). Chrome предлагает добавить новую опцию в API SharedWorker, которая позволит общим рабочим процессам существовать после уничтожения документа в течение короткого периода времени.

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

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

Обеспечить продление срока службы

Эту функцию можно включить на сайтах для пользователей, зарегистрировавшись для пробного периода Origin с расширенным сроком действия для общих рабочих процессов . В качестве альтернативы разработчики могут включить её для своего браузера, используя флаг chrome://flags/#enable-experimental-web-platform-features .

Пример кода

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

const myWorker = new SharedWorker("worker.js", { extendedLifetime: true });

Поскольку общие рабочие процессы также поддерживают большие двоичные объекты (BLOB), эту функцию можно включить и без отдельного скрипта. Например, для записи данных в IndexedDb:

const sharedWorkerScript = `
  const transaction = db.transaction("analytics", "readwrite");
  const store = transaction.objectStore("analytics");
  const request = store.get("visitCount");
  request.onsuccess = (event) => {
    const newCount = (event.target.result || 0) + 1;
    store.put(newCount, "visitCount");
  };
`;

document.addEventListener("pagehide", () => {
  const blob = new Blob([sharedWorkerScript], { type: "text/javascript" });
  const blobURL = URL.createObjectURL(blob);
  new SharedWorker(blobURL, { extendedLifetime: true });
});

У нас также есть пример приложения здесь: https://sharedworker-extendedlifetime.netlify.app/ . При перезагрузке страницы (или закрытии и повторном открытии в течение 30 секунд) предыдущий расчет по-прежнему доступен.

Совместно используемые рабочие процессы отображаются на сайте по адресу: chrome://inspect/#workers , и в скором времени эта информация будет улучшена, чтобы показывать, использовалась ли опция extendedLifetime . Совместно используемые рабочие процессы с увеличенным временем жизни также будут продолжать отображаться на этой странице в течение 30 секунд после загрузки страницы.

Поделитесь своим мнением.

Мы с нетерпением ждём ваших отзывов о расширенном пожизненном режиме работы с учётом происхождения работника.

Форма API обсуждается на GitHub , и у нас есть более подробное техническое объяснение .

Для обратной связи по реализации в Chrome, отправьте сообщение об ошибке в Chromium .