При завантаженні сайту кожен зайвий запит до сервера збільшує 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 | Статика (CSS, JS, шрифти) | 0–50 мс (з кешу) | Ні | Низький, якщо версіонувати файли |
| Network First | HTML-сторінки, API | 200–500 мс (мережа) або 0 (офлайн) | Середня | Низький, кеш оновлюється після кожного успіху |
| Stale While Revalidate | Зображення, товари | 0 (кеш) + 100 мс (фон) | Низька | Помірний, видача застарілого до оновлення |
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();
});
}
});
});
});
Процес роботи
- Аналітика: аудит поточних Core Web Vitals, визначення вузьких місць (LCP, CLS).
- Проектування: вибір стратегій для кожної групи ресурсів, визначення scope.
- Реалізація: написання Service Worker (вручну або через Workbox), інтеграція з билд-системою.
- Тестування: перевірка в Chrome DevTools (Application > Service Workers), Lighthouse, WebPageTest.
- Деплой: поетапний rollout, моніторинг помилок.
Строки орієнтовно
Базове налаштування під ключ — за 1-2 дні. Якщо потрібна кастомна логіка (наприклад, кешування GraphQL), термін збільшується до 4–5 днів. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки проекту.
Що входить в роботу
- Конфігурація Service Worker зі стратегіями для статики, сторінок та API.
- Налаштування Workbox (якщо використовується Vite/Webpack).
- Реалізація сповіщення про оновлення.
- Створення офлайн-сторінки.
- Тестування та профілювання.
- Документація зі стратегій та експлуатації.
- Пост-релізна підтримка (2 тижні).
Типові помилки при впровадженні Service Worker
| Помилка | Наслідок | Рішення |
|---|---|---|
| Неправильний scope | Service Worker не перехоплює запити | Вказуйте scope: '/' |
| Відсутність очищення старих кешів | Накопичення версій, зайвий трафік | Видаляйте старі кеші в activate |
| Кешування без версіонування | Користувач бачить застарілі дані | Використовуйте Network First або короткий термін життя |
Оптимізація завантаження за допомогою Service Worker кешування — це ключовий етап для швидкого сайту. Замовте впровадження Service Worker під ключ для покращення Core Web Vitals. Пишіть нам, щоб оцінити проект — звертайтеся за консультацією.