Prepare a website for slow and interrupted connections

Estimated reading time : 3 min · Published October 1, 2026

Define a useful scope

Classify tasks such as reading stable information, preparing a draft, checking availability or paying. The latter depend on data and confirmations that should not be assumed current offline. Explain unavailable actions usefully.

A simple site can remain useful through lightweight pages and reliable links without adding an offline application. Assess actual interruptions and essential content first. Additional mechanisms need owners and tests rather than merely technical names.

Describe states unambiguously

Separate local draft, awaiting transmission, server receipt and completed processing. Write a message and recovery action for each. A connection icon or disabled button alone does not explain what happened to the request.

MDN documents service workers and offline or background operation. Assess availability and lifecycle in the project’s target browsers. Browsers may interrupt work, so the journey should remain understandable without relying on continuous execution.

Test interruption at an inconvenient moment

In a test environment, disconnect before sending, during transfer and after server receipt. Restore the network and reload. Check what is retained, lost, repeated or shown as complete. The difficult case is often uncertainty about an already-received request.

Use a new session and another device if cross-device continuity is promised. Ask someone unfamiliar with the architecture to test messages. They should understand the remaining action and how to avoid placing a second order.

Check freshness and privacy

For retained information, show date and permitted use. Old availability may orient a visitor without authorising a booking. Define what remains on the device after logout and who reviews shared-device risks.

After a new release, check resource replacement and local-data compatibility. Provide a way to recover permitted drafts or restore simple operation. Deliver states, interruption tests, retention rules and degraded-mode limitations.

Primary documentation : MDN — Offline and background operation.

Reference documents

MDN — Offline and background operation

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

Test cases, expected outcomes and useful evidence
Case	Expected outcome	Evidence to retain
First visit without network	A clear state appears even when no earlier version was stored.	Screen obtained in a browser with no previous site data or caches.
Previously visited page offline	Visitors understand the date and limits of the retained content.	Displayed version and freshness information visible alongside the cached information.
Interrupted form	A local draft is never presented as a received submission.	Displayed wording, local storage and confirmed absence of server-side receipt.
Older session after release	Data and resources remain compatible or offer a clear restart.	Cache and interface versions observed within the same existing browser session.

Frequently asked questions

Does offline operation mean an order is accepted?

No. A draft or pending request must be distinct from server confirmation. Show the actual state and provide recovery that avoids repeated operations.

Does every site need a service worker?

No. Start with uses, page weight and observed interruptions. Specific offline operation is justified when it supports a useful journey the team can maintain and test.