Speed on Low-End Devices: Why Your Site Is Only Fast for You
The most common sentence in any conversation about speed: “it opens instantly for me”. It is usually true and usually means nothing, because it was said by someone with a new computer, a wired connection and the site already in their browser cache.
Real visitors are in different conditions, and that is where the money is lost.
Why developers do not see the problem
| Factor | Development conditions | A real visitor |
|---|---|---|
| Device | A powerful laptop | A three or four year old phone |
| Network | Stable and wired | Mobile, often unstable |
| Cache | Everything already loaded | First visit, empty cache |
| Distance to server | Possibly nearby | Another city or country |
| Background | Only the browser | A dozen apps, low battery |
Each row multiplies the others. Combined, what opens in a second for a developer takes five to eight for a visitor.
What actually slows things down on weak hardware
It matters to separate two different constraints: the network and the processor. The first is fixed by reducing weight, the second by reducing work.
- JavaScript. The main culprit. A 300 kilobyte file downloads in a second but takes several times longer to parse and execute on a weak phone than on a computer. That is not about the network, that is about the processor.
- Fonts. Every weight is a separate file. Four weights in two styles means eight downloads before text appears.
- Unadapted images. A 2000 pixel wide image on a 360 pixel screen downloads in full and is then scaled, spending both bandwidth and memory.
- Third-party scripts. Each is a separate connection to someone else’s server, whose speed you do not control.
- Complex animation. What is smooth on a computer stutters on a budget phone if the animated properties force layout recalculation.
How to test without buying a phone
You do not need to buy an old device, browser developer tools are enough:
- Open developer tools, the network tab.
- Enable throttling at the level of a slow mobile connection.
- In the performance tab, enable CPU slowdown of four to six times.
- Make sure to tick disable cache.
- Reload the page and watch the clock.
This roughly corresponds to a mid-range phone from three years ago on an unstable connection. The difference from what you saw before is usually unpleasant.
A second, even simpler check: take your phone, turn off Wi-Fi and open the site over mobile data somewhere outdoors, not in the office.
What to fix first
Ordered by result relative to effort:
- Server response time. If it exceeds a second, nothing else matters. This is the first thing to check and the most common real problem.
- Unnecessary third-party scripts. Count them and remove those with no answer to what they are for.
- Images. Modern format, dimensions matched to the actual screen, width and height always declared.
- Fonts. Two weights instead of eight, with text displayed immediately.
- JavaScript. Defer everything not needed for the first screen.
- Animation. Opacity and transforms only.
The first three usually deliver most of the result and require no rebuilding of the site.
A performance budget
The most effective tool available, and almost nobody uses it. The idea is simple: agree in advance on limits the page does not exceed.
| Metric | Working limit |
|---|---|
| Server response | under 200 ms |
| Total page weight | under 1 MB |
| A single image | under 300 KB |
| Third-party scripts | no more than 5 |
| Font files | no more than 3 |
The value of a budget lies not in the numbers themselves but in turning “shall we add another widget” from a question of taste into a question of arithmetic. If a new tool does not fit within the limit, something has to go.
Why this matters commercially
The audience with weak devices and poor connections is not a marginal group. These are people travelling, on public transport, outside cities, on budget phones. In many niches they make up the majority of mobile traffic.
And crucially: those people do not write to support saying “your site is slow”. They simply close the tab, and in analytics that looks like an ordinary bounce. Which is why the problem stays unnoticed for years, it produces no signal except a number that is easy to attribute to something else.









