Your Site Is Slow Because of the Phone, Not the Wi-Fi

You open your website on your laptop in the office. It snaps into place. You hand your phone to a customer and watch them tap a menu that does nothing for two seconds, then jumps. Same page, same Wi-Fi, same building. Something is clearly wrong, but everyone's first instinct — the connection must be bad — is usually the wrong one.

Most of the time the difference is not the network. It is the processor in the phone. And once you understand that, the fix list changes completely: you stop buying bandwidth and start deleting work.

Why the same page feels different on two devices

A web page arrives as three kinds of material. HTML is the text and structure. CSS is the styling. JavaScript is the code that makes things do things — sliders, dropdowns, popups, add-to-cart buttons, chat widgets, analytics.

HTML and CSS are cheap. The browser reads them and paints. JavaScript is expensive, because the browser has to download it, unpack it, compile it into instructions the processor understands, and then run it. That last part is not a network job. It is a maths job, done by the phone's chip.

Here is the part that surprises people: the browser does almost all of that on a single thread. One queue, one worker. While that worker is compiling and running your JavaScript, it cannot respond to a tap. Your customer's finger has landed on the menu, the browser knows it, and it simply cannot get to it yet. That is why a page can look finished and still feel dead for a second or two.

Now compare the hardware. Your laptop has a chip with a large cache, aggressive clock speeds, and a fan or a metal chassis to carry heat away. A ₹12,000–₹18,000 Android has a smaller chip, less cache, slower memory, a plastic body and no cooling. When it gets warm — in a Delhi summer, in a pocket, on a call — it deliberately slows itself down to avoid overheating. That is called thermal throttling, and it is not a fault. It is the phone protecting itself.

So the same one megabyte of JavaScript might take a fraction of a second to compile and run on your laptop and several times that on a mid-range phone. The download took the same time on both. The work after the download did not.

Bandwidth decides when the code arrives. The processor decides when the page starts behaving. On cheap phones the second number is usually the bigger one.

What actually eats the processor

In our experience of looking at Indian small-business sites, the same handful of things show up again and again.

• Page builders stacked on themes. A visual builder on top of a theme that already has its own builder means two layers of code, both loading on every page, most of it unused on the page you are actually looking at.
• Sliders and carousels. A homepage slider typically pulls in an animation library, loads every slide's image whether or not anyone scrolls, and runs a timer forever.
• Third-party tags. Chat widget, heatmap recorder, two analytics tools, a pixel, a review widget, a WhatsApp button plugin. Each one is someone else's JavaScript running on your customer's phone, and you control none of it.
• Fonts. Four weights of two font families, each in a format the browser has to fetch before it can draw text properly.
• Enormous images. A photo straight off a phone camera is often four megabytes and 4,000 pixels wide, displayed in a box 350 pixels wide. The phone downloads all of it, decodes all of it in memory, then throws most of it away.
• Huge DOM trees. Every nested row, column, section and wrapper a builder adds is another node the browser must track, style and re-measure whenever anything changes.

None of these are exotic. They are the default output of the way most small-business sites get built.

How to test it honestly

Your laptop is a bad witness. So is your own phone, if it is a recent flagship. Test the way your customers experience the site.

1. Run PageSpeed Insights on the mobile tab. Google's tool deliberately emulates a mid-range Android and slows the simulated processor down. That is why the mobile score is so much worse than desktop — it is not being unfair, it is being realistic.
2. Look at the field data, not just the score. If your site has enough traffic, the top of the report shows real measurements from real Chrome users. That is the truth. The score below it is a lab simulation.
3. Watch Interaction to Next Paint. INP measures the delay between a tap and the screen visibly responding. Google's published thresholds: 200 milliseconds or less is good, above 500 milliseconds is poor. A bad INP is almost always a processor problem, not a connection problem — the code is busy and the tap is waiting in a queue.
4. Borrow a cheap phone. Genuinely. Ask a colleague with a two-year-old ₹15,000 handset. Ten seconds of watching someone try to use your menu tells you more than any report.

The other two published Core Web Vitals thresholds are worth knowing: Largest Contentful Paint should be 2.5 seconds or less, and Cumulative Layout Shift 0.1 or less. LCP is usually images and hosting. CLS is usually things loading late and shoving the page around. INP is the one that maps most directly to "this phone is struggling".

What to cut, in order

Cutting beats optimising. Code that does not exist runs instantly on every device.

1. Delete third-party tags you are not reading

Open your tag manager or plugin list. For each tracking or widget script, ask: who looked at this data in the last three months? If nobody, remove it. This is the single highest-value change on most sites because it costs nothing and breaks nothing.

2. Kill the homepage slider

Replace it with one still image and one clear headline. You lose nothing a customer wanted and you remove an animation library, several unseen images and a permanent timer.

3. Fix images properly

Resize to the largest size actually displayed, convert to WebP or AVIF, and make sure everything below the first screen is lazy-loaded. Do not lazy-load the main image at the top — that delays the thing you are being measured on.

4. Reduce the font load

Two weights of one family is enough for almost every business site. Self-host them and set them to display with a fallback so text is readable while the font arrives.

5. Stop loading everything everywhere

Contact-form code should load on the contact page. Product-gallery code on product pages. On WordPress this usually means a plugin that disables scripts per page, or a rebuild if the theme fights you.

6. Then, and only then, consider rebuilding

If the site is three page builders deep with a decade of plugins, tuning it is repainting a rusted gate. A leaner website build that ships far less JavaScript is often cheaper than a year of patching. That is a judgement call, and it depends on how much of the current site earns its keep.

What we would not buy

A "speed optimisation" package that is just a caching plugin. Caching stores a finished copy of the page so the server does not rebuild it every time. Useful — but it fixes server time, not phone time. Your customer's processor still has to compile the same JavaScript. If a proposal is mostly caching and minification and promises a 90+ score, ask specifically what code is being removed.

A CDN sold as the cure. A content delivery network shortens the distance the files travel. Genuinely helpful if your host is overseas and your customers are in Ludhiana. Completely irrelevant to a phone that is struggling to execute the code once it arrives.

Score chasing. A green 100 in the lab and a customer who cannot open your menu is a failure with good paperwork. Chase the field data and the tap-response feeling; the score follows.

Upgrading hosting first. Sometimes right, often not. If your server response time is fine and your mobile INP is bad, a bigger server buys you nothing. Diagnose before you spend.

What to do next

Do these three things this week. Run PageSpeed Insights on your busiest page, mobile tab, and note the INP and LCP figures. Open your plugin and tag list and delete anything nobody has read data from since last year. Borrow a mid-range Android and try to complete your own enquiry or checkout on it, timing yourself.

That will tell you whether you have a tuning job or a rebuild. If it is tuning, ongoing technical support and maintenance can work through the list. If the structure itself is the problem, tell us what you found and we will look at the actual page and say which it is — including if the honest answer is that your site is fine and the problem is elsewhere.

Questions we get asked