Why is my website slow on mobile? A diagnostic sequence

The complaint usually arrives secondhand. A customer said the site was slow, or someone saw a number in an analytics tool, and now there is a meeting. Meanwhile everyone in the meeting is looking at the site on a recent phone, on good wifi, with the whole thing already cached, and it loads instantly. So the complaint gets filed under exaggeration.

That is the first mistake, and it is worth naming before any technical work starts. Your phone is not the test. The test is a mid-range device on a congested mobile network, arriving cold, which is what most of your traffic actually is.

The thresholds you are actually measured against

Before diagnosing anything it helps to know what counts as slow, because the number is published rather than a matter of opinion. Google's documentation sets the Largest Contentful Paint target at 2.5 seconds or less, with anything over 4.0 seconds classed as poor, and it is explicit that the threshold is assessed at the 75th percentile of page loads, segmented across mobile and desktop.

Two things follow from that and both matter. The 75th percentile means your median visitor is not the one being judged, so a site that feels fine to most people can still fail. And because mobile and desktop are segmented, a strong desktop score does not rescue a weak mobile one. They are marked separately.

The order to check things in

Mobile slowness is almost never one cause, which is why fixing one thing often changes nothing measurable and the effort gets abandoned. Work in this order, because it goes cheapest and most likely first:

• Field data before lab data. Find out what real visitors experience before you run a synthetic test. A lab score describes one simulated device on one simulated connection.
• The largest image on the page. Still, in 2026, the most common single cause and usually the cheapest to fix.
• Third party scripts. Chat widgets, tag managers, heat maps, consent banners. Nobody owns them and nobody removes them.
• Fonts. Custom fonts block text from rendering or cause it to jump. Both are visible and both are avoidable.
• Server response time. Real, but usually a smaller share than the three above, and the most expensive to change.

Notice that the first four are content and configuration decisions rather than engineering ones. That is the good news in most audits: a large share of mobile slowness is fixable by people who do not write code.

Images, still, after all these years

The pattern repeats across nearly every site we look at. A hero image is exported at desktop dimensions, served at that size to a phone, and then scaled down in the browser. The visitor downloads several times the pixels they can see, on the connection least able to afford it.

The fix is unglamorous: serve appropriately sized images per device, use a modern format, and stop lazy-loading the one image that appears at the top of the page. That last one is a common own goal. Deferring the image that defines your Largest Contentful Paint makes the metric worse, not better.

The scripts nobody owns

Every marketing tool added over three years is still loading. The chat widget from a trial that ended. Two analytics tags because the first one was thought to be broken. A heat map tool from a redesign that shipped in 2024.

A useful exercise, and it takes an afternoon: list every third party script the site loads and put a name next to each one. Not a department, a person. Anything without a name gets removed, and the removals are reversible, so the risk is smaller than it feels. It is the same instinct we apply to reports that survive past their purpose in automating manual reporting: if nobody can say which decision depends on it, that is the finding.

What responsiveness measures that load time misses

Loading is only half of what users call slow. The other half is a page that has appeared but does not react: you tap, and nothing happens for long enough that you tap again. Google's Interaction to Next Paint metric measures exactly that, and the documented thresholds are 200 milliseconds or below for good, above 500 milliseconds for poor.

This is the failure mode people describe as the site being laggy rather than slow, and it is far more common on mid-range phones than on the devices most teams test with. A page can hit its load targets and still feel broken to tap, and that experience is a separate number with its own threshold.

When it is the network and not the site

Sometimes the answer is that the site is fine and the connection is not. That is worth establishing early, because it changes what you should do rather than ending the conversation. A site cannot fix a congested network, but it can be built to degrade well on one: text first, images progressive, nothing critical waiting on a script.

It is also worth checking the crawl and indexing side while you are in there, since the two sets of problems overlap and are often found by the same audit. UCourses covers that ground for the Egyptian market in their walkthrough of technical SEO fixes worth doing before anything more ambitious.

The honest limit

Performance work has a floor, and past it you are buying tenths of a second at rising cost. If your site is at four seconds, the work is clearly worth it. If it is at 2.4 seconds and someone is proposing a rebuild to reach 1.9, that is a preference dressed as a requirement, and the money almost certainly does more elsewhere.

The reason to care at all is commercial rather than technical, which we argued separately in a slow site is a revenue problem, not a design opinion. Speed decides how much of the traffic you already paid for ever reaches the offer. That is the frame that gets the work approved, and it is also the frame that tells you when to stop.

What to do this week

Pull the field data for your top five pages. Find the largest image on each and check what size it is actually served at. List the third party scripts and find an owner for every one. That is a day of work, no rebuild, and it resolves the majority of what people mean when they say a site is slow on mobile.

If it turns out the problem is structural rather than a matter of assets, that is a scoping conversation rather than a performance one, and scoping it before anyone writes code is the cheaper path. What you want to avoid is a rebuild commissioned to fix a symptom nobody measured first, which is why the work we take on usually starts with the measurement rather than the rebuild.