Wymuszanie limitu czasu sieci

Czasami masz połączenie sieciowe, ale jest ono zbyt wolne lub zakładamy, że jesteś online. W sytuacjach, gdy mechanizm service worker nie znajduje się w jednym miejscu, strategia buforowania oparta na sieci może trwać zbyt długo, aby uzyskać odpowiedź z sieci, lub żądanie będzie zawieszać się, a wskaźniki wczytywania będą wirować w nieskończoność do momentu wyświetlenia strony błędu.

Niezależnie od sytuacji czasami korzystne może być powrót do ostatniej odpowiedzi zapisanej w pamięci podręcznej dla zasobu lub strony po upływie określonego czasu – a także inny problem, w którym może pomóc Workbox.

Jak korzystać z aplikacji networkTimeoutSeconds

Limit czasu żądań sieci można wymuszać przy użyciu strategii NetworkFirst lub NetworkOnly. W tych strategiach dostępna jest opcja networkTimeoutSeconds, która określa liczbę sekund, przez jaką skrypt service worker ma czekać na odpowiedź sieci, zanim sygnalizuje swój udział i zwróci ostatnią wersję z pamięci podręcznej:

// sw.js
import { NetworkFirst } from 'workbox-strategies';
import { registerRoute, NavigationRoute } from 'workbox-routing';

// Only wait for three seconds before returning the last
// cached version of the requested page.
const navigationRoute = new NavigationRoute(new NetworkFirst({
  networkTimeoutSeconds: 3,
  cacheName: 'navigations'
}));

registerRoute(navigationRoute);

Powyższy kod instruuje skrypt service worker, że po 3 sekundach musi on zrezygnować z żądania nawigacji opartej na sieci i użyć ostatniej wersji przechowywanej w pamięci podręcznej. W przypadku żądań nawigacyjnych gwarantuje to dostęp do ostatniej odpowiedzi zapisanej w pamięci podręcznej dla każdej wcześniej odwiedzanej strony.

Co się jednak stanie, jeśli otwierana strona nie ma starszej odpowiedzi w pamięci podręcznej? W takich sytuacjach możesz utworzyć odpowiedź zastępczą dla ogólnej strony HTML offline:

import {registerRoute, NavigationRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

// Hardcode the fallback cache name and the offline
// HTML fallback's URL for failed responses
const FALLBACK_CACHE_NAME = 'offline-fallback';
const FALLBACK_HTML = '/offline.html';

// Cache the fallback HTML during installation.
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(FALLBACK_CACHE_NAME).then((cache) => cache.add(FALLBACK_HTML)),
  );
});

// Apply a network-only strategy to navigation requests.
// If offline, or if more than five seconds pass before there's a
// network response, fall back to the cached offline HTML.
const networkWithFallbackStrategy = new NetworkOnly({
  networkTimeoutSeconds: 5,
  plugins: [
    {
      handlerDidError: async () => {
        return await caches.match(FALLBACK_HTML, {
          cacheName: FALLBACK_CACHE_NAME,
        });
      },
    },
  ],
});

// Register the route to handle all navigations.
registerRoute(new NavigationRoute(networkWithFallbackStrategy));

Jest to możliwe, ponieważ gdy używasz networkTimeoutSeconds w strategii NetworkFirst, moduł obsługi zwraca odpowiedź o błędzie w przypadku przekroczenia limitu czasu i braku dopasowania pamięci podręcznej dla adresu URL. W takim przypadku wtyczka Workbox handlerDidError może wyświetlić ogólną odpowiedź w zastępstwie.

Jak długo trzeba czekać?

Wymuszanie limitu czasu w przypadku żądań – a zwłaszcza w przypadku żądań związanych z nawigacją – wymaga zachowania równowagi między niedozwoleniem użytkownikowi zbyt długiego oczekiwania na czas oczekiwania na jego przekroczenie. Odczekaj zbyt długo, aby zwiększyć ryzyko utraty powolnych połączeń przez użytkowników przed upływem limitu czasu. Zbyt krótki czas oczekiwania może doprowadzić do wyświetlania nieaktualnych treści z pamięci podręcznej.

Poprawna odpowiedź to „to zależy”. Jeśli prowadzisz witrynę, np. bloga, i nie aktualizujesz jej zbyt często, najlepiej będzie, jeśli nie za długo czekasz, bo wszystko, co znajduje się w pamięci podręcznej, jest wystarczająco aktualne. W przypadku bardziej interaktywnych witryn i aplikacji internetowych warto jednak poczekać nieco dłużej i uniknąć zbyt szybkiego udostępniania nieaktualnych danych z pamięci podręcznej skryptu service worker.

Jeśli rejestrujesz dane w tym polu, sprawdź 75 centyl wyników czasu do pierwszego bajtu (TTFB) i pierwszego wyrenderowania treści (FCP), aby zorientować się, gdzie w Twojej grupie użytkowników mogą znajdować się dłuższe czasy oczekiwania na żądania nawigacji. To może dać Ci wskazówkę, gdzie szukać granic.