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

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

Нещодавній кейс з нашої практики: інтернет-магазин на 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: /^\/api\/.*/, 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 кешування — це ключовий етап для швидкого сайту. Замовте впровадження Service Worker під ключ для покращення Core Web Vitals. Пишіть нам, щоб оцінити проект — звертайтеся за консультацією.

MDN Web Docs: Service Worker API