“Online” and “offline” are not two clean states. A phone can show a connection while packets stall. A train can move between coverage areas. Congested Wi-Fi can deliver the page shell but time out on the request that matters. Data can be expensive, batteries can be low, and the device itself can struggle with work a desktop handles invisibly.
Resilient design treats these as normal conditions. The objective is not merely a high performance score. It is helping someone finish a task when the network is least cooperative.
Put the task in the first response
Begin with semantic HTML containing the real heading, explanation, form, links, and any content that is already known. Do not require a framework to construct the basic page after load. If JavaScript fails, the visitor should still understand where they are and what the page is for.
For content pages, useful HTML may be the entire product. For interactive tools, it is the stable foundation on which enhancement can happen.
Reduce round trips
On a high-latency network, the number and order of requests can matter more than their combined size. A stylesheet that discovers a font and a script that later discovers data create a dependency chain. Each link waits for the previous one.
Bundle only what the page needs. Use system fonts. Avoid redirects. Serve correctly sized images and omit decorative media when it does not earn its cost. Place critical interface styles where the browser can use them immediately.
Make submission states explicit
A slow request creates uncertainty: did the tap register? Should the person tap again? Good interfaces disable duplicate submission when appropriate, announce that work is happening, and preserve the previous successful result if the new request fails.
Error messages should distinguish between invalid input, a missing place, provider failure, timeout, and no connection when the distinction helps recovery. “Something went wrong” is small copy but expensive guidance.
Do not erase useful state
If fresh data cannot load, an older result with a visible timestamp is often better than an empty screen. News can retain the last valid feed. Weather can restore a forecast the visitor explicitly saved. A route sheet can remain open when recalculation fails.
Stale information can also be dangerous. Weather and directions need clear timestamps and limitations. Resilience means preserving context, not pretending old data is current.
Design offline behavior deliberately
A service worker can make visited pages available without a network, but indiscriminate precaching quietly consumes data and storage. Cache a small core and add other pages after use. Exclude personalized, sensitive, or one-time responses. Provide an honest offline page for destinations that were never saved.
Local tools and games are strong offline candidates because their logic and data are already on the device. Search and new route calculation are not: they require indexes and current data that do not fit in a small client.
Prefer text when text completes the task
A map is useful for spatial orientation, but turn-by-turn directions can remain valuable as a compact numbered list. A weather icon can support recognition, but words and values should carry the forecast. News does not require autoplay video to communicate headlines and summaries.
Text compresses well, adapts to narrow screens, works with assistive technology, and survives degraded rendering. That does not make images or maps bad; it makes their purpose something to prove.
Keep controls stable
Late-loading content should not move the button someone is about to press. Reserve necessary space, avoid inserting prompts above the active task, and keep status messages from changing the layout more than needed.
Touch interfaces deserve particular care. Controls should be large enough to hit, games should resist accidental scrolling or selection where appropriate, and the page should not depend on hovering.
Test failure, not only success
Fast local development hides network behavior. Test with latency, throttling, offline transitions, empty responses, malformed data, and provider errors. Test a narrow physical phone, not only desktop emulation. Revisit a cached page after deploying a new service worker.
Budgets and automated checks prevent slow growth: compressed page size, number of third-party runtime dependencies, heading and form integrity, offline exclusions, and representative interactions can all be tested.
Progressive enhancement is still modern
Progressive enhancement does not forbid JavaScript or rich interaction. It assigns responsibility in layers. HTML carries meaning and basic operation. CSS improves presentation. JavaScript adds behavior that those layers cannot provide alone.
The result is not identical under every condition. It is useful under more of them.
A practical order of work
- Identify the smallest successful outcome for the page.
- Deliver the known content and controls as HTML.
- Measure the initial response and request chain.
- Add interaction only where it improves the task.
- Preserve the last useful state during failure.
- Define what may be cached and what must never be cached.
- Test at narrow widths, high latency, intermittent connectivity, and offline.
Slow-connection design is ultimately a form of respect. It assumes the visitor’s time, data, battery, and attention are more valuable than the site’s appetite.