Принудительное тайм-аут сети,Принудительное тайм-аут сети

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

Какой бы ни была ситуация, бывают случаи, когда предпочтительнее вернуться к последнему кэшированному ответу для ресурса или страницы через определенный период времени — еще одна проблема, с которой может помочь Workbox.

Использование networkTimeoutSeconds

Принудительное тайм-аут для сетевых запросов можно выполнить при использовании стратегий NetworkFirst или NetworkOnly . Эти стратегии предлагают опцию networkTimeoutSeconds , которая указывает количество секунд, в течение которых работник службы должен ждать получения ответа сети, прежде чем он выйдет из строя и вернет последнюю его кэшированную версию:

// 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);

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

Однако что, если страница, к которой вы обращаетесь, не имеет более старого ответа в кеше? В подобных случаях вы можете установить резервный ответ на общую автономную HTML-страницу:

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));

Это работает, потому что когда вы используете networkTimeoutSeconds в стратегии NetworkFirst , ваш обработчик вернет ответ об ошибке, если произойдет тайм-аут и нет совпадения с кэшем для URL-адреса. Если это произойдет, плагин handlerDidError Workbox может предоставить общий ответ в качестве запасного варианта.

Как долго еще ждать?

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

Правильный ответ: «Это зависит». Если вы управляете таким сайтом, как блог, и не обновляете контент слишком часто, правильный ответ, вероятно, будет заключаться в том, чтобы не слишком долго ждать, поскольку все, что находится в кеше, вероятно, достаточно «свежее». Однако для более интерактивных веб-сайтов и веб-приложений, возможно, лучше подождать немного дольше и избегать слишком быстрого предоставления устаревших данных из кэша сервисного работника.

Если вы записываете метрики в полевых условиях , посмотрите на 75-й процентиль показателей времени до первого байта (TTFB) и первой отрисовки контента (FCP), чтобы понять, где среди вашей пользовательской базы может быть более длительное время ожидания навигационных запросов. Это может дать вам представление о том, где провести черту.