PWA Development on 1C-Bitrix: Caching, Push, Offline

Why PWA on Bitrix breaks on a weak connection

PWA on Bitrix most often fails not on "weak internet" as such, but at the junction of three things: the service worker serves a stale application cache, a request to the server is interrupted midway, and the order form is submitted again.

Individually, each failure looks harmless; together, they give the client a picture of "the site shows the old version, the order was duplicated, support is sorting it out manually."

The first failure is the caching strategy. If static assets and HTML are cached "forever," after a release the user sees the old version of the page for weeks, while the new build sits on the server and is never requested by anyone.

This is fixed not by disabling caching, but by separating it: the application shell is updated by build version, data is fetched over the network with background updates, and heavy API responses are not cached at all.

The second failure is offline mode on an unstable network. A request goes out, the connection drops on the response, and the application doesn't know whether the order reached the server.

If at that moment you show "error, please try again," the user clicks again — and gets a duplicate.

That's why critical operations (placing an order, submitting a request, payment) are queued with an operation identifier: the server uses it to recognize that this is the same request and does not create a second entity.

The third failure is push and background sync. Notifications sent without accounting for the subscription state go into the void, while the queue of unsent items accumulates in the browser and is lost when data is cleared.

What matters here is an explicit policy: what is stored locally, for how long, and what happens when the local and server versions conflict.

Let's break down how this is addressed on the Bitrix side: cache versioning, idempotent form submission, and predictable behavior when the connection drops.

What Changes After PWA Implementation

Once a PWA is installed on a user's device, subsequent launches run from the local cache: the interface, fonts, and core blocks render instantly, while data is fetched in the background.

In practice, this noticeably reduces time to first screen compared to a regular browser visit, where every session re-downloads the same resources. The client gets an experience that previously only a native app could deliver, but without a separate build for each platform.

Resilience to connection drops is the second measurable result. A service worker intercepts network requests and serves pre-cached responses, so on a weak mobile connection or when switching between networks, the page doesn't crash with an error.

The user keeps working with the interface, while submitted forms are queued and sent to the server as soon as the connection is restored.

It is precisely this mechanism that directly reduces lost leads. Previously, a connection drop at the moment a form was submitted meant the data never arrived and the customer was gone.

Now the lead is saved locally and re-sent automatically — the share of lost inquiries drops, and along with it, the load on managers decreases, since they no longer need to call back and clarify.

Offline operation and repeat visits are interconnected. A user who opens the app without a network still sees the catalog, order history, and statuses — and comes back again because the experience is predictable.

The icon on the home screen acts as a permanent entry point, and the share of repeat visits grows without additional acquisition costs.

To understand which of these effects will drive growth in your specific case, you need to look at your current analytics: where leads are lost, how mobile users behave, and which scenarios are critical for offline. Describe your task — we'll come back with an estimate and an implementation plan.

PWA implementation approaches: comparison of approaches

In practice, the choice comes down to three scenarios, and the difference between them lies in how much logic moves to the device side.

A wrapper over the current site leaves all rendering and data on the server, the offline layer moves the cache and request queue to the client, and the hybrid additionally connects a native mobile app as a second channel.

What the choice decides

The wrapper is assembled the fastest and barely changes the current site — it is chosen when the goal is speed and installation to the screen, not autonomy.

The offline layer requires thinking through which data goes into local storage, what to do with the queue of unsent requests, and how to mark stale records. The hybrid is justified when the scenario does not work without system notifications and access to hardware.

Where the limitations begin

The cache cannot be kept indefinitely: the update rule sets the data lifetime and the priority of the network or storage for each type of request. If this is not done, the user will see an outdated price or stock, and after synchronization will get a discrepancy with the server.

Hence the requirement for versioning the data schema and an explicit rollback strategy — an update must not break an already installed app.

We analyze your task and select an option for the use case, not the other way around.

PWA Bitrix Implementation Stages

Implementing PWA on Bitrix is not a module installation, but a consistent engineering effort: first we capture the current state, then design caching, then configure and test under real operating conditions. Below are the stages a project goes through from kickoff to handover.

How the process works

1. Audit. We map out pages and requests, review what data the server returns and what can be served from cache. We separately analyze authorization, the cart, and forms — they cannot be cached as static content, otherwise the user will see someone else's data. The output is a list of routes marked "cache / network only / hybrid."

2. Caching scheme. We design strategies for each content type: the app shell and static assets — preloading on install, the catalog — serving from cache with background updates, personalized blocks — network only. We define cache versioning so that after a release the user doesn't get stuck on old files.

3. Configuration. We register the service worker, manifest, icons, and splash screens, and connect push notifications through the server side. We configure behavior when connectivity is lost: what we show from cache, what we queue for sending.

4. Testing on a weak connection. We test not in an office with fast internet, but under slow connection conditions and full offline: opening, navigation, re-entry, submitting a form after connectivity is restored. We observe how the cache behaves when the version is updated.

5. Load testing. We make sure that caching doesn't break order tracking and doesn't create duplicates on repeated submission.

6. Handover. We provide documentation on caching schemes, instructions for updating the version, and a release checklist so that your team can make changes as well.

7. Support. After launch, we track the install rate, session depth, and the number of support requests — these metrics show where the scheme should be fine-tuned.

Describe your project — we'll get back to you with an estimate and a work plan based on these stages.

Caching and data synchronization

A cache in a PWA on 1C-Bitrix is not "save the whole page" but a set of strategies for each data type.

We serve the catalog and static resources on a "cache first, update in the background" basis: the interface opens instantly even on a weak connection, and the fresh version is pulled in right after.

Personal data — the cart, favorites, order statuses — on the contrary, we build on a "network first" basis: we show the current state, and use the cache only as a fallback when the connection drops.

These approaches must not be mixed: this is exactly where data discrepancies for the user most often arise.

Background synchronization works through a send queue. A user action — a placed order, a quantity change, a completion mark — first goes into the local queue and is immediately reflected in the interface, and is sent to the server as soon as a connection appears.

If the connection drops midway, the request is not lost: it stays in the queue marked "unconfirmed" and is retried when the network returns. This way the scenario "filled out the form in the elevator — it sent on the street" works without data loss.

We resolve data conflicts on the server side, not on a "last one wins" basis. For each entity we define a merge rule: orders and payments — server version takes priority, user marks and drafts — local version takes priority.

If the versions diverge critically, the system does not silently overwrite but flags the record and sends it for confirmation. This protects against the classic situation where two devices edit the same record and one silently overwrites the other's work.

We keep data current through response versioning: the server returns a change marker, the client compares it with its own and requests only the delta, not the entire list.

After returning to the network, the user sees not a "load from scratch" but a targeted update — the interface stays responsive, and traffic does not grow proportionally to the data volume.

What the client receives

We hand over not a "finished application" but a package your team can use to operate and evolve the PWA without us.

Each artifact addresses its own class of tasks: caching is responsible for speed and offline, synchronization schemes for data consistency between client and server, and access policies for what a specific role sees.

• Cache configurations — strategies for static assets, API responses, and product cards: what we put into precache at install time, what we update in the background, what we serve from the network with a fallback to a copy. With the time-to-live of entries and invalidation rules when content changes.
• Synchronization schemes — data flow diagrams: which entities go into the background queue when there is no connection, in what order they are sent upon reconnection, and how version conflicts between the device and the server are resolved.
• Access policies — a matrix of roles and permissions at the PWA level: which sections and data are available to a guest, an authenticated user, and an employee; how tokens are refreshed and what happens when a session expires.
• Push scenarios — a list of triggers (order status, new message, promotion), notification templates, and recipient segmentation rules so that the mailing does not turn into spam.
• Documentation — a description of the architecture, integration points with 1C and Bitrix, and instructions for local launch and build for developers.
• Update regulations — the procedure for releasing a new version: how we notify clients about a cache change, how we roll back to the previous build, and who and when checks compatibility with the current core.
• Acceptance checklist — scenarios by which we verify offline mode, installation on the home screen, notification operation, and data correctness after desynchronization.

All of this is handed over in your repository with access for the team. Describe the task — we will come back with an estimate and a plan for your environment.

How does a PWA differ from a native app?

A PWA and a native app solve the same problem — giving the user quick access to a service from their phone — but they are built differently. A native program is installed from an app store, lives in a separate environment, and is updated by publishing a new build with moderation.

A PWA opens at a regular URL and, when needed, is installed to the home screen as a shortcut: the same interface, the same data, but without a separate codebase for each platform.

The cost of ownership differs fundamentally. A native app means two or three parallel projects for different platforms, each with its own release cycle, its own store reviews, and its own update requirements.

A PWA is built on a single codebase on top of a Bitrix site: logic, markup, and integrations are reused rather than duplicated. Maintenance costs stop multiplying by the number of platforms — the team maintains one product instead of several.

Update speed is the second key difference. App stores add a review to every release, which can take days, and some changes are rejected for formal reasons.

With a PWA, the new version is deployed to the server and picked up on the next open: the service worker serves fresh files from the cache, and old versions are evicted according to the rules. A critical bug fix reaches users in minutes, not weeks of approvals.

Installation requirements also diverge. A native app must first be found in the store, downloaded, waited for, and only then launched — each step loses part of the audience.

A PWA works immediately via a link: the user lands on the site, uses it, and installation to the home screen is offered as an optional step. The barrier to entry is lower, and the conversion from first visit to repeat visit is higher.

There are limits, too. A native program works more deeply with hardware: camera, Bluetooth, background geolocation, and system notifications are available without restrictions.

A PWA covers most scenarios — push, offline mode, camera access — but where constant access to sensors in the background is needed, a native build remains more precise. So the choice is not either-or, but a question of which features are critical for your scenario.

Case study: how PWA reduced lost requests

The client — a service company with field crews — accepted requests through a web form on a site running 1С-Bitrix.

Crew leaders worked from tablets in basements and at sites without stable connectivity: the form was submitted, but when the network dropped, the request was lost, and the client saw "submission error." Losses reached up to a quarter of requests during peak hours, and the dispatcher only learned about a lost request when an irritated customer called.

What was changed

We built a PWA wrapper on top of the existing frontend: a service worker intercepts form submission, stores the request in the device's local storage, and retries the request as soon as the network returns.

Conflicts are resolved using the client-side request identifier — duplicates are not created on resubmission. Push notifications via the service worker notify the dispatcher about new requests and the crew leader about status changes, even when the tab is closed.

Metrics before and after

The effect on the dispatch desk was noted separately: previously half of the working time went into reconciling "what got through and what didn't," now the flow of requests is visible in real time.

Recovery time after a failure is no longer a manual operation — the system resends the accumulated data on its own when connectivity returns.

Common technical concerns

The PWA layer sits on top of the existing 1C-Bitrix core rather than replacing it: the service worker intercepts requests and serves cached responses while the core and modules operate as usual.

Therefore, compatibility is determined not by the PWA itself, but by how carefully caching rules are defined for dynamic pages — the cart, the personal account, and search results.

Standard modules ("Online Store", "Information Blocks", "Universal Lists") do not require rewriting: separate strategies are configured for them — static assets and the catalog are cached, while personalized responses go over the network only.

Data security: what ends up in the cache on the device?

Only public resources go into the cache — markup, scripts, images, and the catalog. Authorization tokens, personal account content, and payment data are not cached: the "network only" mode is explicitly set for them.

Push subscriptions are stored separately from user data and are tied to the session; when the user logs out, the subscription is revoked.

How does PWA affect SEO and indexing?

Search engine robots receive the same server-side HTML as before — the service worker is not activated for them. Page URLs do not change, so accumulated rankings and link equity are preserved.

Installing the app on a device adds a second channel for user return visits without competing with search traffic.

What about offline mode and content updates?

Offline mode serves a pre-selected set: the home page, the catalog, and previously opened pages.

When connectivity returns, the service worker synchronizes changes in the background, and the cache version is bumped automatically — the user does not need to reinstall the app to see fresh data.

Let's discuss your task

To come back with an estimate and a plan rather than generalities, we need context on your task.

Describe what already works and what hurts: which catalog section or user account should go offline, which actions are critical without a network, whether there is a working authorization and how the exchange with 1C is structured. That is enough to understand the scope and propose a realistic plan.

What is worth attaching to the description:

• the current address of the site or prototype and a brief description of the product;
• which scenarios should work offline and what data they need;
• how user login, the cart, and checkout are currently structured;
• where notifications come from and what should go into push;
• which integrations with 1C and external services already exist;
• whether there are constraints on timelines, access, and environment;
• who on the customer's side makes product decisions.

Based on the review, we come back with a stage-by-stage estimate, a work plan, and a list of what will be required from your side: access to the repository and the control panel, a test environment, the contact of the 1C integrator.

Then we agree on the order: first the basic offline framework and caching, then push and synchronization, then load testing on real scenarios.

Describe the task in any convenient form — we will come back with an estimate, a plan, and next steps.