PWA development on 1C-Bitrix: caching, push, offline

Developing a PWA on top of 1C-Bitrix turns a website into a progressive web app with offline access and push notifications. The standard pwa module in Bitrix generates a basic manifest.json and Service Worker, but it cannot version the cache or handle complex scenarios: catalogs with thousands of products, authorized users, integration with composite. We customize the Service Worker, set caching strategies, and ensure a green Lighthouse. The result is budget savings on native development and increased conversion.

What problems does PWA on Bitrix solve?

The built-in pwa module generates /manifest.json and registers /sw.js, but it does not manage cache versioning or handle complex offline catalog scenarios. For an e-commerce store with tens of thousands of products, the default Cache First approach is not suitable — custom strategies are needed: Stale While Revalidate for API, Network First with fallback for HTML. We solve these issues by adapting the Service Worker to the specific template and business logic.

Another problem is interaction with the composite module. Composite HTML is cached by the Service Worker, and when content changes (prices, stock levels), users see outdated data. Cache versioning via CACHE_VERSION eliminates this, along with proper exclusion of dynamic URLs.

How we implement PWA on Bitrix

Audit of the current site

We evaluate the impact of composite, check iOS support, calculate Lighthouse scores. We identify bottlenecks: incorrect start_url, missing 512×512 icon, incompatible caching strategies. More about PWA can be found on Wikipedia.

Service Worker setup

Custom logic is written in /local/templates/main/sw-custom.js and connected via importScripts(). We do not modify /sw.js directly — it is regenerated by the module. We use three strategies:

• Cache First for static assets (/bitrix/js/, /bitrix/css/, /upload/)
• Network First for HTML, excluding URLs with sessid and AJAX requests to bitrix/services/main/ajax.php
• Stale While Revalidate for catalog API responses — serve from cache, update in parallel

Cache versioning

We add a custom field sw_version to manifest.json. On deploy, we increment it, and the Service Worker cleans old caches on activation:

const CACHE_VERSION = 'v1.4'; self.addEventListener('activate', event => { event.waitUntil( caches.keys().then(keys => Promise.all(keys.filter(k => k !== CACHE_VERSION).map(k => caches.delete(k))) ) ); }); 

Why is cache versioning critical for PWA?

Without versioning, users see outdated content even after the site is updated. The Service Worker continues to serve old files until the cache expires. Versioning ensures that after deploy everyone gets fresh resources — critical for e-commerce with frequently changing prices.

PWA vs native app: which to choose?

PWA is developed 3–5 times faster than a native app and takes up 10 times less space. For a catalog, corporate site, news portal, PWA is sufficient. For an app with Bluetooth, NFC, a native client is needed.

Stages and timelines

Work stages:

1. Audit (2–3 days) — template check, composite impact, Lighthouse.
2. Module and Service Worker setup (3–5 days) — manifest.json, caching strategies, offline page, push subscription.
3. Testing (2–3 days) — Android (Chrome, Samsung Internet), iOS (Safari), desktop; Lighthouse at each step.
4. Launch and monitoring (1–2 days) — deploy, metric check, alerts on Service Worker errors.

Approximate timelines:

Pricing is determined individually — contact us for a consultation and savings estimate.

What's included in PWA development?

• Audit and recommendations
• Manifest.json and custom Service Worker setup
• Push notifications via pull module
• Offline page creation
• Documentation and administrator training
• 30-day warranty support

Typical mistakes when implementing PWA

• iOS Safari does not support Background Sync, Badge API, full push without Home Screen.
• Service Worker update — even with skipWaiting(), the new version is only applied on the next page open.
• Cache size is limited: Chrome allocates up to 80% of free space, Safari — 50MB per origin. Caching the entire catalog of 10,000 products is not possible — only critical resources.
• The composite module with CDN may generate HTML with absolute CDN domain URLs — the Service Worker will not intercept requests to another origin. We check scope in register().

Get a consultation — we'll help determine the optimal PWA implementation route for your project. Request an audit and cost estimate today.