In this guide
On your fast office Wi-Fi, loading looks fine. Users are on trains, in lifts and on old phones. Test each screen that fetches data under bad conditions.
How to simulate slow networks
- Android emulator: Extended controls, Cellular section: choose a slower network type and a weaker signal strength.
- iOS: Apple offers network conditioning tools for developers; check Apple's current developer documentation for where to find them.
- Any device: a proxy with throttling, or switch between Wi-Fi and airplane mode during a request.
- Real test: a device with one bar of signal, or a slow public hotspot.
The checklist
- Something shows immediately. - Why: a frozen screen after a tap feels like a bug. - How to check: throttle hard, tap an item. Within a moment a spinner, skeleton or placeholder appears.
- Feedback matches the wait. - Why: a spinner for a minute with no information makes users leave. - How to check: keep a request slow for 10+ seconds. Is there text such as "Still loading..." or progress for long jobs?
- A timeout exists and ends in a message. - Why: infinite spinners are a dead end. - How to check: block the request entirely. After a limit the app stops and shows an error with retry.
- Retry works. - Why: it is the escape from every failed load. - How to check: fail the load, restore the network, retry. Content appears without leaving the screen.
- Leaving the screen cancels or ignores the request. - Why: late responses can crash or update the wrong screen. - How to check: start a slow load, go back, wait. No crash, no stale data popping into another screen.
- Repeated taps do not stack requests. - Why: impatient users tap again and trigger duplicates. - How to check: tap load, refresh or submit repeatedly on a slow connection. One request, or the later ones replace the earlier.
- Pull-to-refresh behaves. - Why: indicator that never ends or double content is common. - How to check: pull to refresh on slow and failing networks. The indicator stops and the list is not duplicated.
- Partial content. - Why: one slow part should not block the whole screen. - How to check: delay one of several requests. The rest shows, the slow part has its own placeholder or error.
- Cached content vs fresh. - Why: old data shown silently is confusing, a blank screen when cache exists is wasteful. - How to check: open a screen once online, then offline. Cached content shows and is marked as possibly outdated, if that matters.
- Pagination and infinite scroll.
- Why: the next page can fail or end without notice.
- How to check: scroll to the end on a slow network and with a failed page. A footer loader, a retry and an end-of-list state show.
- Uploads and downloads show progress and can be cancelled.
- Why: users need to know it is working and to be able to stop it.
- How to check: upload a large file on a slow connection, cancel midway, then retry. No half-finished item remains.
- App backgrounded during a load.
- Why: the OS may pause or kill the app.
- How to check: start a load, switch apps for a minute, return. It resumes or restarts cleanly.
- Loading placeholders do not jump.
- Why: layout shifts make users mis-tap.
- How to check: watch the transition from skeleton to content; elements do not move under the finger.
- Screen reader announces loading and completion.
- Why: silent loading leaves blind users guessing.
- How to check: with the screen reader on, check that "loading" and "loaded" are announced or the focus moves to the new content.
Related
Back to all checklists · Search and filter checklist · Settings screen checklist
A tester on a poor connection finds what your office Wi-Fi hides. Start here: private, structured feedback, 1 feedback = 1 credit.