Wymuszanie limitu czasu sieci

Zdarzają się sytuacje, gdy masz połączenie sieciowe, ale jest ono zbyt powolne lub fałszywe jest to, że jesteś online. W sytuacjach, w których występuje skrypt service worker, strategia buforowania w pierwszej kolejności sieci może zbyt długo czekać na odpowiedź z sieci lub żądanie będzie się zawieszać, a wskaźniki wczytywania będą się bez końca kręcić, aż wyświetli się strona z komunikatem o błędzie.

Niezależnie od sytuacji zdarzają się sytuacje, w których preferowane jest powrót do ostatniej odpowiedzi na zasób lub stronę z pamięci podręcznej po upływie określonego czasu. Jednak w rozwiązaniu problemu może pomóc Workbox.

Jak korzystać z aplikacji networkTimeoutSeconds

Wymuszanie limitu czasu żądań sieciowych można wykonać przy użyciu strategii NetworkFirst lub NetworkOnly. Te strategie udostępniają opcję networkTimeoutSeconds, która określa liczbę sekund, przez jaką mechanizm Service Worker powinien czekać na odpowiedź sieci, zanim cofnie się żądania i zwraca jej 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, aby po 3 sekundach zrezygnował z nawigacji po stronie sieci i używał ostatniej wersji w pamięci podręcznej. W przypadku żądań nawigacji gwarantuje dostęp do ostatniej odpowiedzi na każdą odwiedzoną wcześniej stronę w pamięci podręcznej.

Co jednak, jeśli strona, którą odwiedzasz, nie ma starszej odpowiedzi w pamięci podręcznej? W takich przypadkach możesz ustawić odpowiedź zastępczą na ogólną stronę 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));

Dzieje się tak, ponieważ gdy używasz networkTimeoutSeconds w strategii NetworkFirst, moduł obsługi zwróci odpowiedź o błędzie, jeśli upłynie czas oczekiwania i nie uda się znaleźć adresu URL w pamięci podręcznej. W takim przypadku wtyczka Workbox handlerDidError może wyświetlić ogólną odpowiedź zastępczą.

Jak długo trzeba czekać?

Wymuszając limit czasu dla żądań – zwłaszcza tych dotyczących nawigacji – musisz zachować odpowiednią równowagę między zbyt długim oczekiwaniem użytkownika a zbyt szybkim przekroczeniem limitu czasu. Zbyt długo to wiąże się z ryzykiem odrzucenia wolnych połączeń, zanim minie limit czasu. Zbyt krótki czas oczekiwania może spowodować niepotrzebne wyświetlanie nieaktualnej treści z pamięci podręcznej.

Właściwa odpowiedź to „to zależy”. Jeśli prowadzisz witrynę (np. bloga) i nie aktualizujesz treści zbyt często, właściwą odpowiedzią jest prawdopodobnie nie zmuszać się zbyt do czekania, ponieważ zawartość pamięci podręcznej jest prawdopodobnie „świeży”. wystarczy. W przypadku bardziej interaktywnych witryn i aplikacji internetowych warto jednak odczekać trochę dłużej i unikać zbyt szybkiego udostępniania nieaktualnych danych z pamięci podręcznej skryptu service worker.

Jeśli rejestrujesz dane w terenie, sprawdź 75 centyl wartości Czas do pierwszego bajtu (TTFB) i Pierwsze wyrenderowanie treści (FCP), aby się zorientować, gdzie wśród użytkowników może być dłuższy czas oczekiwania na żądania nawigacji. To powinno dać Ci wyobrażenie, gdzie musisz wyznaczyć granicę.