Progressive
web app development
in Boston

A progressive web app that only reads data offline is simple. The trouble starts the moment a person can change something without a connection. Check a box. Edit a quantity. Add a note. The change has to live somewhere on the device, then travel to the server later. By the time it arrives, the record it touches may have moved. Building for that gap is a distinct engineering job, separate from picking a cache strategy for static assets.

The usual approach stores pending changes in IndexedDb as a small queue. It does not overwrite local state directly. Each entry carries the action, the target record, a client timestamp, and a version marker copied from the last known server value. When the device reconnects, the app replays the queue in order. It does not send one bulk snapshot. Order often carries meaning: a discount applied before a quantity change reads differently than the reverse.

Conflicts happen when the record changed on the server while the device was offline. Three patterns cover most cases. Last write wins is the simplest. The newer timestamp replaces the older value. It suits fields where losing a stray edit is a minor cost, such as a display preference. Field-level merge keeps both sides where the changes do not overlap. That fits forms with many independent inputs. Manual resolution surfaces both versions to the person and asks which one to keep. It is reserved for data where a silent overwrite is a real problem, such as an inventory count or an assigned task.

Version markers matter more than timestamps alone. Device clocks drift, and they cannot be trusted for ordering. A short counter, or a hash of the record, gets stored alongside the cached copy. It is checked against the server value on sync. If it does not match, the base the edit came from is stale. The sync layer routes the change to whichever conflict pattern the field calls for, instead of writing over it blindly.

Queued writes need idempotency. A flaky connection can retry a request that already succeeded. Attaching a client-generated identifier to each queued action lets the server recognize a repeat. It discards the duplicate rather than applying the change twice. Without this, a person editing a record while signal drops in and out can end up with duplicate entries, doubled line items, or a counter that increments twice for one action.

Read data needs its own refresh rule, separate from the write queue. A cached list screen that never revalidates will show stale totals long after the network returns. That erodes trust faster than a visible offline banner ever does. A common pattern refreshes the visible screen on reconnect and on tab focus. It also marks any record touched by a pending local write, so the person can see which values are provisional.

Testing this layer differs from testing a typical form submission. The interesting bugs only appear across a sequence of events: edit, lose connection, edit again, reconnect, and a server-side change landing in between. A short scripted scenario forces the device offline mid-session, queues several actions, then reconnects while the fixture data changes underneath. It catches problems manual testing on a stable connection never will. Automating three or four such sequences during development saves a much longer debugging session after launch.

None of this needs to cover every field in a system. A sensible first pass identifies which records a person is likely to edit while offline. It applies queuing and conflict handling only there, leaving read-only data on a simpler cache-and-refresh path. Scoping the work this way keeps the sync layer small. It stays easy to reason about and test, instead of becoming a general framework nobody fully understands.

Deciding what to test before a release is a separate job from writing the tests themselves. A team with unlimited time could check every browser, every device, and every screen size before every deploy. No real team has that time. So the matrix has to be built on priority, not completeness. The starting point is traffic data, not a generic list of popular devices: which browsers and screen sizes the actual audience uses, pulled from analytics rather than assumed.

A workable matrix separates two tiers. Tier one. Tier two. The first tier covers the browsers carrying most of the traffic, tested manually on every release, including the install flow, offline routes, and push delivery. The second tier covers everything else, checked less often and mainly through automated smoke tests that confirm the app still loads and the service worker still activates. Moving something from tier two to tier one is a data decision, made when usage shifts, not a one-time choice fixed at launch.

Regression testing matters as much as first-release testing, and often gets skipped. A feature that worked on a given browser at launch can quietly break months later. A browser update changes default behavior. A dependency gets upgraded. Either one is enough. Rerunning a fixed set of scenarios against the tier-one browsers on a schedule, rather than only when a related feature ships, catches this kind of drift before a person reports it. A calendar reminder is enough to keep the habit alive.

Automated checks cover a meaningful slice of the matrix without manual repetition every release. A script can confirm a manifest is valid. It can confirm a service worker reaches an activated state. It can verify that key offline routes serve from cache when the network is disabled in the test environment. What a script cannot fully replace is manual verification of the install flow itself, since prompts and home screen icons render through operating system chrome a headless test does not reproduce.

Real devices still catch problems emulators miss. A phone with limited memory evicts a background tab and its service worker sooner than a desktop browser ever would, which changes how often the app has to reinitialize state on resume. Older, cheaper hardware exposes slow script execution a fast development machine hides completely. A short list of real devices, chosen for being genuinely constrained rather than the newest available, earns its place in the matrix more than a longer list of similar new phones.

Storage behavior deserves its own check, separate from layout and function. Some browsers clear storage automatically after a period of inactivity, with no warning and no event the app can hook into. A test plan should include a deliberate run where cached data and queued offline actions get wiped mid-scenario, then confirm the interface degrades to a clear state instead of breaking silently.

A practical release checklist separates blocking issues from acceptable gaps. A broken install flow on a tier-one browser blocks a release, every time. A missing feature on a browser that never carried real traffic for the app is a known limitation, not a bug, and belongs in a short written note rather than a fresh investigation each cycle. Keeping that distinction explicit is what turns the matrix from a source of last-minute panic into routine work.

A performance budget is a small set of numeric limits attached to a build, checked automatically rather than reviewed by feel. For a progressive web app the useful limits usually cover three things: JavaScript sent on first load, time to the page becoming interactive, and the size of the service worker script itself. A bloated worker delays activation on a slow connection just as much as a bloated page delays first paint.

Choosing numbers before writing code avoids a common failure. A budget set to whatever the current build already measures just enshrines existing bloat, rather than limiting it. A better starting point ties the budget to the slowest realistic device and connection the audience actually uses, not the fastest machine on the development team. That figure becomes a ceiling the team commits to defending release after release.

JavaScript weight deserves the most attention. It drives parse time. It drives execution time. It drives the delay before the interface responds to a tap. Splitting code by route keeps the initial bundle close to its budget without cutting functionality elsewhere. A person visiting one screen does not need to download the logic for every other screen too. A bundle analyzer run as part of the build catches the case where one added dependency quietly pulls in a much larger one behind it.

Images and fonts belong in the same budget, even though they are not code. On a slow connection a heavy hero image delays interactivity almost as much as an oversized script does. Serving modern image formats helps. So does sizing assets for the layout rather than the source file, and loading fonts with a fallback that avoids invisible text during load. Each lever has a measurable cost a budget can cap directly.

Enforcement matters more than the numbers themselves. A budget written in a document and never checked drifts within a few releases, as each small addition looks harmless on its own. Running the check in the build pipeline keeps it honest. No exceptions by default. A pull request that pushes the bundle past its limit should fail automatically, without relying on someone remembering to look. A short grace process, where a team can raise the limit deliberately with a reason attached, works better than a rule nobody trusts.

Field data closes a gap lab testing cannot. A budget checked only in a controlled build environment misses real network conditions, device variety, and the effect of a heavy third-party script loaded outside the main bundle. Collecting real user timing data, even a modest sample, and comparing it against the lab numbers on a regular basis reveals the difference. Lab numbers show what the pipeline measures. Field data shows what a person feels on a train platform or a spotty office connection.

A budget that only ever tightens will eventually collide with a genuine feature need. That is expected. Treating every request to spend more of it as a negotiation, rather than a rule violation, keeps the process useful instead of adversarial. The goal is not the smallest possible bundle. It is a build that stays inside a limit the team chose on purpose, adjusted deliberately rather than by small compromises nobody signed off on.