Imagine: a user visits an e-commerce store from a dacha with unstable 3G, adds items to the cart, then loses connection. On a typical site — an error and data loss. We implemented PWA for a major retailer: after introducing offline mode, bounce rate dropped by 22%, conversion increased by 18%, and traffic savings reached up to 30% — that's about 30,000 RUB per month for a project with 50,000 visitors. With an average order of 1,500 RUB, a 15% conversion lift adds ~225,000 RUB additional revenue per 1,000 users. We use Service Worker, IndexedDB, and Background Sync to cache pages and data, save actions, and sync them when the network is restored. Over 10+ years of work, we have implemented such solutions for dozens of projects, ensuring reliability and a smooth user experience.
What problems does offline mode solve
Data loss on connection drops. Without offline mode, user actions (form fill, cart add) are lost. We use IndexedDB to persist actions and Background Sync to automatically send them after restoration.
Blank screens. Instead of a connection error, we display cached data or a dedicated offline page with an explanation. This reduces bounce rate by 15-30%. In one project, bounce rate fell from 35% to 18%.
Slow loading on unstable connections. App Shell caching reduces time to interactive (TTI) to 1-2 seconds even offline. Comparison: Cache-first strategy loads static resources 2x faster than Network-first.
How to organize caching for offline access?
App Shell — minimal HTML/CSS/JS for the interface shell. Cached at Service Worker install time.
Data — last loaded pages, user favorites, cart. Cached at runtime.
// sw.js: strategy for different content types
const SHELL_CACHE = 'shell-v1';
const CONTENT_CACHE = 'content-v1';
const IMAGES_CACHE = 'images-v1';
const APP_SHELL = ['/', '/cart', '/wishlist', '/offline.html'];
// Cache all visited HTML pages
self.addEventListener('fetch', event => {
if (event.request.headers.get('Accept')?.includes('text/html')) {
event.respondWith(networkFirstWithOfflineFallback(event.request));
}
});
async function networkFirstWithOfflineFallback(request) {
const cache = await caches.open(CONTENT_CACHE);
try {
const response = await Promise.race([
fetch(request),
new Promise((_, reject) => setTimeout(reject, 3000, new Error('timeout')))
]);
cache.put(request, response.clone());
return response;
} catch {
const cached = await cache.match(request);
if (cached) return cached;
// Serve offline page with explanation
return caches.match('/offline.html');
}
}
Caching strategy comparison
| Strategy | Advantages | Disadvantages | When to use |
|---|---|---|---|
| Network First | Fresh data, network priority | Slow on hanging requests | Pages where timeliness matters (cart) |
| Cache First | Instant load, network-independent | Data may be stale | Static resources (CSS/JS) |
| Stale-while-revalidate | Shows cache quickly, updates in background | Double load | Product list, news |
What to do when the connection is lost?
We implement a network status indicator and an optimistic interface (Optimistic UI). The user sees that data is saved locally and sync will happen automatically.
// useNetworkStatus.ts + deferred action sync
export function useNetworkStatus() {
const [isOnline, setIsOnline] = useState(navigator.onLine);
const [wasOffline, setWasOffline] = useState(false);
useEffect(() => {
const handleOnline = () => {
setIsOnline(true);
if (wasOffline) {
syncPendingActions();
setWasOffline(false);
}
};
const handleOffline = () => {
setIsOnline(false);
setWasOffline(true);
};
window.addEventListener('online', handleOnline);
window.addEventListener('offline', handleOffline);
return () => {
window.removeEventListener('online', handleOnline);
window.removeEventListener('offline', handleOffline);
};
}, [wasOffline]);
return { isOnline, wasOffline };
}
async function syncPendingActions() {
const pending = await db.pendingActions.toArray();
for (const action of pending) {
try {
await processAction(action);
await db.pendingActions.delete(action.id!);
} catch (err) {
console.error('Sync failed for action:', action, err);
}
}
}
Why offline mode improves UX and conversion?
Research by Google shows that 53% of users leave a site if it takes longer than 3 seconds to load. Offline mode eliminates this: after the first visit, key resources are cached, and subsequent loads are instantaneous. In our electronics e‑commerce case, average TTI dropped to 1.2 seconds, bounce rate fell by 27%, and conversion increased by 15%. Traffic savings reached 30%.
How we do it
We use Service Worker combined with IndexedDB (via Dexie.js). For background sync we leverage the Background Sync API. All code is tested under real-world scenarios (3G, 4G, complete offline).
IndexedDB for offline data
// db.ts — Dexie.js (wrapper for IndexedDB)
import Dexie, { type Table } from 'dexie';
interface CachedProduct {
id: number;
slug: string;
name: string;
price: number;
image: string;
cachedAt: Date;
}
interface PendingAction {
id?: number;
type: 'add_to_cart' | 'add_to_wishlist' | 'submit_review';
payload: Record<string, unknown>;
createdAt: Date;
}
class AppDatabase extends Dexie {
products!: Table<CachedProduct>;
pendingActions!: Table<PendingAction>;
constructor() {
super('AppDatabase');
this.version(1).stores({
products: 'id, slug, cachedAt',
pendingActions: '++id, type, createdAt',
});
}
}
export const db = new AppDatabase();
Deferred actions (Optimistic UI)
// Optimistic add to cart, works offline
async function addToCart(productId: number, quantity: number) {
const { isOnline } = getNetworkStatus();
if (isOnline) {
await api.post('/cart/items', { productId, quantity });
} else {
await db.pendingActions.add({
type: 'add_to_cart',
payload: { productId, quantity },
createdAt: new Date(),
});
updateCartLocally(productId, quantity);
showToast('Item added. Will sync when connection is restored');
}
}
// Register Background Sync from page
async function registerBackgroundSync() {
const registration = await navigator.serviceWorker.ready;
if ('sync' in registration) {
await (registration as SyncRegistration).sync.register('sync-cart');
}
}
Browser support comparison
| API | Chrome | Firefox | Safari | Edge |
|---|---|---|---|---|
| Service Worker | ✅ | ✅ | ✅ (11.1+) | ✅ |
| Background Sync | ✅ | ❌ | ❌ | ✅ |
| IndexedDB | ✅ | ✅ | ✅ | ✅ |
Additional support information
For browsers without Background Sync, we use periodic synchronization via setInterval on network restoration. This ensures correct operation for about 95% of users.Our process
- Analytics — study audience, usage scenarios, content types.
- Design — choose caching strategies, design IndexedDB schema.
- Implementation — write Service Worker, cache configuration, sync logic.
- Testing — verify in network condition simulators (Chrome DevTools, Lighthouse).
- Deployment — configure CI/CD for Service Worker updates.
Deliverables
- Service Worker documentation: caching strategies, version management.
- IndexedDB setup for offline data with examples.
- Background Sync implementation.
- UX optimizations: network indicator, offline page, toasts.
- Team training: code review, maintenance documentation.
Why choose us
10+ years of experience in PWA development, over 40 successful projects. Our approaches align with MDN best practices. We guarantee quality and provide post-launch support. Contact us for a consultation on your project. Order implementation of offline mode turnkey — we will assess your project in 1 day. Get a consultation — it's free.
Timeline: 2–3 days for full offline mode with IndexedDB and Background Sync.