Build for the network your users actually have

Most software is built on fast office Wi-Fi and a recent laptop. Many of its users have a low-cost Android phone, a metered data bundle and a signal that comes and goes. If you only test on the first setup, you will not see what the second group sees.

Test on the real thing

Keep a low-cost Android phone at the office and use it for every demo. Browser network throttling is useful, but it does not reproduce a slow processor or a congested tower. A page that feels instant on a laptop can spend seconds running JavaScript on a budget phone.

Data costs real money

For many users, every megabyte has a price, so a heavy page is more than slow. It is expensive. Set a budget and enforce it in your build.

• Serve modern image formats at the size they are displayed.
• Audit each script and remove what is not earning its place.
• Render on the server so that content appears before JavaScript finishes.
• Host fonts yourself and load only the weights you use.

Offline is a feature you can ship

A service worker can save your pages and assets on the device, so that a returning visitor gets an instant load, or a working page with no connection at all. This website works that way: once it has loaded, you can turn off your data and keep browsing.

Pages:         try the network, fall back to the saved copy
Hashed assets: use the saved copy, it never changes
Live data:     never cache it in a shared cache

Be careful with personal data. Keep anything private out of shared caches, and clear it from the device when someone signs out.

Never lose what a person typed

Nothing is more frustrating than filling in a long form and losing it to a dropped connection. Save input on the device, then send it when the network returns, and always tell the person clearly what happened. A small status message such as "saved, will send automatically" turns a failure into something they can trust.

Show state honestly

Slow is acceptable when people know what is going on. Show that the app is waiting for a network, show what has been saved, and retry on its own. Reserve full-page error screens for problems the person can actually do something about.