Why We Test Client Websites on a Slow Phone Before They Launch

Every designer and developer works on a fast machine with a fast connection. Most visitors do not. The gap between the two is where launch-day complaints come from, so before a site goes live we test it on something slow.

The test is simple. Take an older mid-range phone, switch off wifi and load the site over mobile data, or use the throttling controls in browser developer tools. Then use it like a stranger would: land on the homepage, tap the menu, scroll to the first image, open a project page.

We watch for four things. How long until something useful appears. Whether the layout jumps as images and fonts load. Whether a tap does anything immediately or sits there thinking. And whether the page still makes sense if a script fails to load.

Images are the usual cause. A hero image exported at the size of a poster, then scaled down by the browser, can be several megabytes of waste. We export at the size actually shown, use modern formats with a fallback, and load anything below the first screen lazily. Fonts come next: two weights from one family is almost always enough.

For 3D and motion-heavy pages the rule is stricter. The page has to be useful before the heavy asset arrives, and the heavy asset needs a still image standing in for it. A client site that shows a loading bar for ten seconds loses the visit, however good the animation.

Accessibility sits in the same pass. We tab through the page with the keyboard, check text contrast against the background, and make sure every image that carries meaning has a description. None of it takes long.

None of this is glamorous. It is half an hour of checking that catches the problems clients would otherwise find for us. A site is only as good as its worst visit, so we test the worst visit first.