Обработчик networkOnly

Стратегия networkOnly в библиотеке Sw-precache реализует максимально «чистое» сетевое поведение: каждый запрос обрабатывается исключительно через сеть, полностью игнорируя кэш Service Worker. Это означает:

  • отсутствует чтение из кэша;
  • отсутствует запись ответа в кэш;
  • каждый запрос инициирует обращение к серверу;
  • при отсутствии сети запрос завершится ошибкой.

Такая стратегия применяется в ситуациях, где актуальность данных критичнее производительности и офлайн-доступа.

Принцип работы

При использовании networkOnly Service Worker выступает лишь как прокси:

  1. Перехватывает запрос через событие fetch.
  2. Передаёт его напрямую в сеть с помощью fetch().
  3. Возвращает ответ без дополнительной обработки.

Схематически:

Request → Service Worker → Network → Response

В отличие от других стратегий (cacheFirst, networkFirst, staleWhileRevalidate), здесь отсутствуют:

  • fallback-механизмы;
  • логика синхронизации;
  • промежуточные уровни хранения данных.

Конфигурация в Sw-precache

В sw-precache стратегия задаётся через параметр runtimeCaching.

Пример конфигурации:

module.exports = {
  runtimeCaching: [
    {
      urlPattern: /\/api\/.*$/,
      handler: 'networkOnly'
    }
  ]
};

Разбор параметров:

  • urlPattern — регулярное выражение для сопоставления URL;
  • handler: 'networkOnly' — указание стратегии.

В данном случае все запросы к /api/ будут обрабатываться исключительно через сеть.

Типичные сценарии использования

1. API-запросы с динамическими данными

Когда данные часто обновляются и устаревание недопустимо:

{
  urlPattern: /\/api\/user\/.*$/,
  handler: 'networkOnly'
}

Причины выбора:

  • персонализированные данные;
  • высокая частота изменений;
  • необходимость строгой актуальности.

2. Аутентификация и сессии

Запросы, связанные с безопасностью:

{
  urlPattern: /\/auth\/.*$/,
  handler: 'networkOnly'
}

Особенности:

  • исключение риска использования устаревших токенов;
  • отсутствие хранения чувствительных данных в кэше.

3. Платежные операции

Любые финансовые транзакции:

{
  urlPattern: /\/payments\/.*$/,
  handler: 'networkOnly'
}

Кэширование здесь недопустимо из-за:

  • требований безопасности;
  • необходимости точного состояния операции.

Поведение при отсутствии сети

Ключевая особенность networkOnly — полное отсутствие fallback-логики.

Если сеть недоступна:

  • fetch() выбрасывает ошибку;
  • Service Worker не возвращает никакого альтернативного ответа;
  • клиент получает failed request.

Пример обработки ошибки на уровне приложения:

fetch('/api/data')
  .then(response => response.json())
  .catch(() => {
    console.error('Сеть недоступна');
  });

Сравнение с другими стратегиями

Стратегия Кэш используется Поведение при offline Актуальность данных
cacheFirst Да Работает Низкая
networkFirst Да Есть fallback Высокая
staleWhileRevalidate Да Работает Средняя
networkOnly Нет Ошибка Максимальная

Преимущества

  • Максимальная актуальность данных — всегда свежий ответ с сервера;
  • Простота логики — отсутствие сложных механизмов кэширования;
  • Безопасность — чувствительные данные не сохраняются локально;
  • Предсказуемость — поведение полностью соответствует стандартному fetch.

Ограничения

  • Отсутствие офлайн-доступа;
  • Зависимость от сети — ухудшение UX при нестабильном соединении;
  • Повышенная нагрузка на сервер;
  • Отсутствие оптимизации производительности.

Комбинирование с другими стратегиями

В реальных приложениях networkOnly редко используется изолированно. Чаще применяется в комбинации:

module.exports = {
  runtimeCaching: [
    {
      urlPattern: /\/api\/secure\/.*$/,
      handler: 'networkOnly'
    },
    {
      urlPattern: /\/images\/.*$/,
      handler: 'cacheFirst'
    },
    {
      urlPattern: /\/.*$/,
      handler: 'networkFirst'
    }
  ]
};

Такое разделение позволяет:

  • API — всегда свежие данные;
  • статические ресурсы — быстрый доступ;
  • HTML — баланс между скоростью и актуальностью.

Влияние на архитектуру приложения

Использование networkOnly накладывает требования:

  • наличие стабильного сетевого соединения;
  • корректная обработка ошибок на клиенте;
  • продуманная UX-логика при offline-состоянии;
  • отказ от офлайн-first подхода для отдельных модулей.

Расширение поведения вручную

При необходимости можно реализовать собственную логику поверх networkOnly:

self.addEventListener('fetch', event => {
  if (event.request.url.includes('/api/')) {
    event.respondWith(
      fetch(event.request).catch(() => {
        return new Response(
          JSON.stringify({ error: 'offline' }),
          { headers: { 'Content-Type': 'application/json' } }
        );
      })
    );
  }
});

Здесь добавляется минимальный fallback без полноценного кэширования.

Практические рекомендации

  • использовать только для критически актуальных данных;
  • избегать применения к статическим ресурсам;
  • обязательно обрабатывать сетевые ошибки;
  • комбинировать с другими стратегиями;
  • учитывать нагрузку на backend.

Отладка

Для проверки работы стратегии:

  1. Открыть DevTools → Network.
  2. Включить режим Offline.
  3. Выполнить запрос.

Ожидаемое поведение:

  • запрос завершится ошибкой;
  • в Cache Storage отсутствуют записи.

Взаимодействие с HTTP-кэшированием

Важно различать:

  • Service Worker cache — игнорируется;
  • HTTP cache (браузера) — может использоваться.

Даже при networkOnly браузер может вернуть ответ из HTTP-кэша, если заголовки позволяют:

Cache-Control: max-age=3600

Для полного отключения кэширования требуется:

Cache-Control: no-store

Влияние на производительность

Показатели:

  • Latency: выше из-за обязательного сетевого запроса;
  • Throughput: зависит от сети;
  • TTFB: увеличивается при медленных соединениях.

Оптимизация возможна только на стороне сервера:

  • CDN;
  • кеширование на backend;
  • минимизация payload.

Использование в современных инструментах

Хотя sw-precache считается устаревающим решением (в пользу Workbox), стратегия networkOnly полностью перенесена и используется аналогично:

workbox.routing.registerRoute(
  /\/api\/.*$/,
  new workbox.strategies.NetworkOnly()
);

Логика и поведение остаются идентичными.

Контроль областей применения

Рекомендуется чётко ограничивать URL-паттерны:

Плохо:

{
  urlPattern: /\/.*/,
  handler: 'networkOnly'
}

Хорошо:

{
  urlPattern: /\/api\/v1\/orders\/.*$/,
  handler: 'networkOnly'
}

Это предотвращает:

  • деградацию производительности;
  • потерю офлайн-возможностей;
  • избыточные сетевые запросы.

Диагностика проблем

Частые ошибки:

  • забытая обработка offline;
  • неправильный urlPattern;
  • ожидание кэширования при его отсутствии;
  • путаница с HTTP-кэшем.

Методы диагностики:

  • проверка Cache Storage;
  • логирование в Service Worker;
  • анализ заголовков ответа;
  • тестирование в offline-режиме.

Итоговая роль стратегии

networkOnly занимает нишу строго сетевых операций:

  • критичные данные;
  • безопасность;
  • актуальность выше доступности;
  • отказ от офлайн-first подхода.

Это инструмент точечного применения, а не универсальное решение для всего приложения.

Оглавление