Реализация Service Worker: стратегии кэширования и офлайн-режим

При загрузке сайта каждый лишний запрос к серверу увеличивает LCP. Без SW ресурсы загружаются из сети при каждом переходе, что особенно критично для мобильных пользователей с нестабильным соединением. Мы решаем эту проблему, внедряя фоновый скрипт, перехватывающий запросы. Правильная конфигурация стратегий позволяет сократить LCP на 40–60%, а TTFB — в 3–5 раз. Наш опыт показывает, что грамотная настройка Service Worker повышает конверсию на 10–20% и снижает нагрузку на сервер вдвое.

Недавний кейс из нашей практики: интернет-магазин на Next.js имел LCP 4.2 с вместо нормы 2.5 с. После настройки SW со стратегией Network First для страниц и Cache First для статики LCP упал до 1.8 с, конверсия выросла на 15%. За 6 лет работы мы реализовали более 80 проектов с PWA, гарантируя улучшение Core Web Vitals минимум на 30%.

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

Какие проблемы решает Service Worker

Service Worker устраняет несколько типовых узких мест:

• Медленная загрузка повторных посещений: без кэша все ресурсы запрашиваются заново. SW возвращает их из кэша мгновенно.
• Отсутствие офлайн-доступа: при обрыве сети пользователь видит пустую страницу. SW может показывать кэшированную версию.
• Высокий TTFB: если API-запросы не кэшируются, каждый рендер страницы ждёт ответа сервера. SW может отвечать из кэша, обновляя данные в фоне.
• Hydration mismatch: при SSR несоответствие между серверным и клиентским HTML. Кэширование статики уменьшает время гидратации.

Стратегии кэширования: сравнение

Основные стратегии: Cache First, Network First, Stale While Revalidate. Выбор стратегии зависит от типа ресурса и требуемой свежести.

Cache First обеспечивает загрузку из кэша в 10 раз быстрее, чем Network First, для статики. Первая стратегия подходит для неизменяемых файлов, вторая — для страниц, которые должны быть всегда свежими, третья — для ресурсов, где можно показать устаревшую версию на 1–2 секунды.

Как мы это делаем: кейс внедрения

Работаем с React, Next.js, Vite. Для production используем библиотеку Workbox — она избавляет от ручного кэширования и даёт готовые обработчики. Пример настройки с vite-plugin-pwa:

// vite.config.ts
import { defineConfig } from 'vite';
import { VitePWA } from 'vite-plugin-pwa';

export default defineConfig({
  plugins: [
    VitePWA({
      registerType: 'autoUpdate',
      workbox: {
        globPatterns: ['**/*.{js,css,html,ico,png,svg,woff2}'],
        runtimeCaching: [
          {
            urlPattern: /^https:\/\/api\.example\.ru/,
            handler: 'NetworkFirst',
            options: {
              cacheName: 'api-cache',
              networkTimeoutSeconds: 3,
              expiration: {
                maxEntries: 50,
                maxAgeSeconds: 300,
              },
            },
          },
          {
            urlPattern: /\.(?:webp|avif|jpg|png|svg)$/,
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'images-cache',
              expiration: {
                maxEntries: 200,
                maxAgeSeconds: 30 * 24 * 60 * 60,
              },
            },
          },
        ],
      },
    }),
  ],
});

// src/service-worker-registration.ts
export function registerServiceWorker() {
  if ('serviceWorker' in navigator) {
    window.addEventListener('load', () => {
      navigator.serviceWorker.register('/sw.js', { scope: '/' })
        .then(registration => {
          console.log('SW registered:', registration.scope);
          setInterval(() => registration.update(), 60 * 60 * 1000);
        })
        .catch(err => console.error('SW registration failed:', err));
    });
  }
}

Почему важно кэшировать API-запросы?

API-запросы — частая причина высокого TTFB. Если не кэшировать ответы, каждый переход на страницу вызовет новый запрос. Стратегия Network First с коротким временем жизни кэша (например, 5 минут) ускоряет повторные просмотры. В случае неудачи сети пользователь получит хотя бы кэшированные данные, а не ошибку. Время ответа API может достигать 500 мс, а кэширование сокращает его до 0–50 мс.

Как обновлять кэш без потери пользователей?

При обновлении Service Worker важно корректно управлять версиями кэша. В activate-событии мы удаляем старые кэши, оставляя только актуальный. Для уведомления пользователя о новом SW используем событие updatefound и показываем кнопку «Обновить»:

navigator.serviceWorker.ready.then(registration => {
  registration.addEventListener('updatefound', () => {
    const newWorker = registration.installing!;
    newWorker.addEventListener('statechange', () => {
      if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
        showUpdateNotification(() => {
          newWorker.postMessage({ type: 'SKIP_WAITING' });
          window.location.reload();
        });
      }
    });
  });
});

Процесс работы

1. Аналитика: аудит текущих Core Web Vitals, определение узких мест (LCP, CLS).
2. Проектирование: выбор стратегий для каждой группы ресурсов, определение scope.
3. Реализация: написание Service Worker (вручную или через Workbox), интеграция с билд-системой.
4. Тестирование: проверка в Chrome DevTools (Application > Service Workers), Lighthouse, WebPageTest.
5. Деплой: поэтапный rollout, мониторинг ошибок.

Сроки ориентировочно

Базовая настройка — от 1 до 2 дней. Если требуется кастомная логика (например, кэширование GraphQL), срок увеличивается до 4-5 дней. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки.

Что входит в работу

• Конфигурация Service Worker со стратегиями для статики, страниц и API.
• Настройка Workbox (если используется Vite/Webpack).
• Реализация уведомления об обновлении.
• Создание офлайн-страницы.
• Тестирование и профилирование.
• Документация по стратегиям и эксплуатации.
• Пост-релизная поддержка (2 недели).

Типичные ошибки при внедрении Service Worker

Свяжитесь с нами для консультации по вашему проекту. Закажите внедрение Service Worker для улучшения Core Web Vitals.

MDN Web Docs: Service Worker API