Testowanie źródła wspólnych pracowników o wydłużonym czasie działania

Barry Pollard
Domenic Denicola
Domenic Denicola
X GitHub

Data publikacji: 31 lipca 2025 r.

Od Chrome 139 możesz wziąć udział w nowym eksperymencie Origin Trial dotyczącym pracowników współdzielonych o dłuższym czasie życia. Wersja próbna dodaje nową opcję extendedLifetime: true, która umożliwia instancjom roboczym współdzielonym działanie po zwolnieniu ostatniego dokumentu.

Przypadek użycia funkcji wydłużonego okresu eksploatacji

Wiele witryn chce wykonać pewne działania, gdy użytkownik opuszcza stronę. Na przykład zapisywanie danych w pamięci lub wysyłanie ich z powrotem na serwery w celu zapisania stanu lub rejestrowania danych analitycznych.

Platforma internetowa udostępnia kilka interfejsów API, które obsługują niektóre prostsze przypadki użycia, ale każdy z nich ma ograniczenia:

  • Synchroniczne interfejsy JavaScript API, takie jak zapisy localStorage, są wykonywane do końca przed zwolnieniem bieżącej strony.
  • Interfejs fetch API ma kilka opcji, takich jak keepalive i ostatnio fetchLater, które umożliwiają wysyłanie żądań przez krótki czas po zamknięciu dokumentu.

Obejmują one jednak tylko pracę synchroniczną, z wyjątkiem ostatniego żądania fetch. Nie zezwalają na używanie asynchronicznych interfejsów API, takich jak IndexedDB, Compression Streams czy Web Crypto, do szyfrowania lub tworzenia skrótów. Wiele interfejsów API, zwłaszcza nowszych, jest asynchronicznych, aby uniknąć blokowania głównego wątku, więc brak możliwości korzystania z nich podczas zwalniania zasobów jest ograniczający.

Alternatywą jest użycie service workerów, które działają poza cyklami życia poszczególnych stron. Jest to jednak dość złożone rozwiązanie, które stawia przed deweloperami bardziej skomplikowane wymagania dotyczące cyklu życia i zarządzania, a przed użytkownikami – dodatkowe wymagania dotyczące procesów i pamięci. Nie pasuje też do głównego zastosowania service workerów (działania jako serwer proxy dla żądań sieciowych). Używanie pełnych usług Service Worker wyłącznie w przypadku wykonywania pewnych działań po zamknięciu strony wydaje się przesadą.

Proponowane rozwiązanie

SharedWorker API to prostszy interfejs API, który służy do przenoszenia zadań z głównego wątku. Obecnie jednak nie działają one dłużej niż okres istnienia źródła (gdy ostatnia strona tego źródła zostanie zwolniona). Chrome proponuje dodanie do interfejsu SharedWorker API nowej opcji, która pozwoli pracownikom współdzielonym działać przez krótki czas po usunięciu dokumentu.

Standard HTML zachęca już do utrzymywania aktywności współdzielonych procesów roboczych przez krótki czas po zwolnieniu dokumentu, aby nawigacja między stronami z tej samej domeny nie powodowała zamykania i ponownego tworzenia współdzielonego procesu roboczego. Propozycja wydłużenia czasu życia polega na tym, że nawet jeśli użytkownik nie przechodzi do miejsca docelowego z tej samej domeny, agent użytkownika powinien utrzymywać działanie współdzielonego pracownika przez pewien czas, aby można było dokończyć pracę asynchroniczną.

Proponujemy, aby współdzielone wątki robocze działały po zwolnieniu ostatniego dokumentu przez taki sam czas, jak wątki robocze serwera, czyli 30 sekund w przypadku Chrome. Pamiętaj, że w przypadku współdzielonych instancji roboczych jest to maksymalny czas życia po zwolnieniu, a nie czas bezczynności. Oznacza to, że 30-sekundowy limit zaczyna się od momentu zwolnienia, a nie od czasu bezczynności. Prace, które rozpoczęły się w tym okresie, ale nie zostały jeszcze ukończone, zostaną anulowane.

Włączanie wydłużonego okresu eksploatacji

Funkcję można włączyć w witrynach dla użytkowników, rejestrując się w eksperymencie z interfejsem API dotyczącym współpracowników z dłuższym czasem życia. Deweloperzy mogą też włączyć tę funkcję w swojej przeglądarce za pomocą flagi chrome://flags/#enable-experimental-web-platform-features.

Przykładowy kod

Po wyrażeniu zgody na okres próbny lub włączeniu flagi funkcji włącz rozszerzony okres ważności w ten sposób:

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

Współdzielone procesy robocze obsługują też obiekty blob, więc można je włączyć bez osobnego skryptu. Na przykład aby zapisać dane w 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 });
});

Mamy też przykładową aplikację: https://sharedworker-extendedlifetime.netlify.app/. Gdy strona zostanie ponownie załadowana (lub zamknięta i ponownie otwarta w ciągu 30 sekund), poprzednie obliczenia będą nadal dostępne.

Udostępnieni pracownicy są widoczni w przypadku witryny pod adresem chrome://inspect/#workers. Wkrótce zostanie to ulepszone, aby pokazywać, czy użyto opcji extendedLifetime. Pracownicy współdzieleni o wydłużonym czasie życia będą też widoczni na tej stronie przez 30 sekund po zamknięciu strony.

Prześlij opinię

Chętnie poznamy Twoją opinię o okresie próbnym dotyczącym dłuższego czasu życia wspólnego źródła workerów.

Kształt interfejsu API jest omawiany na GitHubie. Mamy też szczegółowe wyjaśnienie techniczne.

Jeśli masz uwagi dotyczące implementacji w Chrome, zgłoś błąd w Chromium.