On older devices the constraint is processing rather than the connection. Reducing what has to be executed helps where reducing what is downloaded does not.

Two different bottlenecks

Most performance advice is about the network: how much is sent and how quickly it arrives.

Once it has arrived, the device has to do something with it, and that takes time too.

On a current phone the second part is fast enough to ignore, and on a five-year-old one it can exceed the download entirely.

So a page that arrives in a second can take another few seconds before anything responds to a tap.

Why the gap is large

The last is the point. The difference between devices is a multiplier rather than a fixed amount, so a page with little code is fine everywhere and a page with a great deal of it is fine on a new phone and unusable on an old one.

What the symptoms look like

Since they read as a broken site rather than a slow one.

The page appears and taps do nothing for a few seconds.

Scrolling stutters rather than being smooth.

A menu takes a moment to open after being pressed.

And a form field responds late to typing, which is the most irritating of all.

None of those is a download problem, and none of them improves by making images smaller.

Reduce what has to run

Which is a different exercise from reducing weight.

Every script has to be downloaded, parsed, and executed, and the last two are what the device pays for.

So removing a script helps twice, and compressing it helps only the download.

The heaviest offenders on a small business site are usually a page builder, a slider, an animation library, and any tool that watches what the visitor does.

Ask what each is for, and whether the same effect is achievable with less, which for most visual effects it is.

A site built with plain markup and a little styling is fast on every device by construction.

A worked example

A business had a site that tested well and about which customers complained.

On a current phone it was fine, and on a four-year-old one it took roughly six seconds before the menu would open.

The cause was a page builder loading a large amount of code on every page, plus an animation library and a session recording tool.

Removing the recording tool and the animations, and rebuilding two pages without the builder, brought the older phone under two seconds.

The downloaded weight barely changed, since the removed code was not large.

What changed was how much the phone had to work through, which no weight measurement had shown.

Test on a real old device

Since this is the one thing a simulation reports poorly.

Browser tools can slow the processor artificially, which is a reasonable approximation and worth using.

A real old phone is better, because it also has less memory, throttles when warm, and runs an older browser.

Find the oldest phone anybody in the business has and keep it for this, which costs nothing since it already exists in a drawer.

Test the things that involve interaction: opening the menu, filling the form, using the gallery.

Those are where processing shows and where a load-time measurement tells you nothing.

Who is on old devices

Worth knowing, since it affects how much this matters to you.

Your analytics report the devices visitors use, which is a specific answer rather than a guess.

Look at the proportion using devices more than three or four years old, and whether their behaviour differs.

A high bounce rate concentrated on older devices is this problem showing up in the figures.

For some businesses that group is a fifth of visitors and for others almost nobody, and the two situations justify different effort.

Check before deciding, since assumptions about who has what device are frequently wrong.

The site should work without the code

Which is the underlying protection.

Where the content, the navigation, and the contact details work with no scripts at all, a slow device gets a usable page immediately and the enhancements arrive later.

Where the page depends on code to display anything, a slow device gets nothing until it has finished working.

That is a construction decision rather than an optimisation, and it is the difference between degrading gracefully and failing.

Test it by disabling scripts entirely and seeing whether the page is still usable, which takes a minute and tells you which of the two situations you are in.

Watch what runs on scroll and on typing

A specific category worth checking, since it costs continuously rather than once.

Code attached to scrolling or to keystrokes runs many times a second, so anything inefficient there is felt constantly rather than at load.

That is the usual cause of stuttering scroll and of a form field that lags behind typing, both of which read as a cheap site.

The common sources are scroll-triggered animations, sticky elements repositioned by code rather than by styling, and live validation on form fields.

All three have versions that cost almost nothing, so this is usually a matter of how it was built rather than of whether to have it.

The counter-case

This can be over-weighted.

Devices are replaced steadily and the share on genuinely old hardware falls every year.

For a business whose customers are mostly on recent phones, the effort belongs elsewhere.

And some functionality genuinely requires code, which is a fair trade when the function is valuable.

Check what proportion of your visitors are on older devices, test interaction on a real one, and remove what does not earn its execution.

What to do

  1. Check the device report in analytics.
  2. Find the oldest phone in the business.
  3. Test the menu, form, and gallery.
  4. Time the delay before a tap responds.
  5. List what scripts are running.
  6. Remove what is decorative.
  7. Check the page works with scripts off.

Step three is what reveals it, since this problem shows up in interaction rather than in loading and no page speed figure captures it.

The network side is covered in why your site feels slow on a phone.


Frequently asked questions

What is the second bottleneck?

Processing. Once files arrive the device has to parse and execute them, which on a five-year-old phone can take longer than the download did.

Why is the gap so large?

Processors improve faster than connections, and the difference between devices is a multiplier rather than a fixed amount, so it widens with the amount of code.

What do the symptoms look like?

Taps doing nothing for a few seconds, stuttering scroll, a menu opening late, and a form field responding late to typing. None improves by making images smaller.

What actually helps?

Removing scripts rather than compressing them. Removing helps twice, since the device pays for parsing and executing as well as downloading.

How should I test it?

On a real old phone rather than a simulation, testing interaction: opening the menu, filling the form, using the gallery. Load time measurements miss this entirely.

How do I know if it matters to me?

Your analytics report device models. Look at the proportion on hardware more than three or four years old and whether their bounce rate differs.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Site tests well and customers complain?

Try it on the oldest phone in the business and time how long before the menu opens.

Start a Conversation