Why your app is slow on Indian networks — and how to fix it

Almost every performance problem we are called in to fix has the same origin story: it was tested on a fast laptop, on office WiFi, on a recent iPhone. Then it shipped to users on a three-year-old Android phone with 4GB of RAM, on a 4G connection that drops in lifts, on a data plan they are conscious of.

Here is what actually goes wrong, roughly in order of how much it costs you.

1. Images are almost always the biggest problem

Uncompressed hero images and full-resolution product photos routinely account for the majority of page weight. A 3MB image that renders into a 400-pixel-wide slot is three megabytes of a user's data plan spent on pixels they will never see.

• Serve modern formats — WebP or AVIF — with a fallback
• Serve responsive sizes so a phone never downloads the desktop asset
• Lazy-load anything below the fold, eagerly load only the one image that is the largest element on first screen
• Set explicit width and height so the layout does not jump as images arrive

2. JavaScript is not free, and it is worse on cheap phones

Bandwidth gets the attention, but on mid-range Android the bottleneck is often the processor. A megabyte of JavaScript downloads in a second and then takes several more seconds to parse, compile and execute on a device with a modest CPU. During that time the interface is visible but unresponsive, which users read as broken rather than slow.

Split your bundle by route so a user opening the home screen does not download the settings screen. Audit your dependencies — a date library, an icon set and an animation framework can quietly outweigh your entire application code.

3. Third-party scripts, which nobody owns

Analytics, chat widgets, heatmaps, ad pixels, A/B testing tools. Each one is added by a different team for a defensible reason, and collectively they often exceed the weight of the product itself. Worse, a synchronously loaded third-party script blocks your page on a server you do not control.

Load every one of them asynchronously or deferred, audit the list quarterly, and delete the ones nobody has opened a report from in six months.

4. Assuming the network is there

This is the specifically Indian failure mode. Connections do not fail cleanly; they degrade, hang and recover. An app that assumes a request either succeeds or fails quickly will freeze on a request that does neither.

• Set explicit timeouts on every network call — the default is usually far too long
• Retry with backoff rather than immediately, and cap the retries
• Cache aggressively so a repeat view does not need the network at all
• Queue writes locally and sync when connectivity returns, rather than blocking the user
• Show useful partial states rather than a spinner over the whole screen

Test on the cheapest phone your users actually carry, on a throttled connection. Everything else is optimism.

5. Fonts, which block text from appearing

A custom webfont loaded without a display strategy will hide your text until the font arrives. Use a swap strategy so text renders immediately in a fallback, preconnect to the font host, and subset the font to the characters you actually use. Two weights is usually plenty; six is a decision worth revisiting.

How to actually measure it

Synthetic tests on a fast machine will tell you everything is fine. Throttle the CPU and the network in your browser's developer tools to approximate a mid-range device on 4G, and test on a real budget Android handset before every significant release.

Then collect field data from real users rather than relying on lab numbers alone. The gap between your lab score and your field score is, precisely, the gap between your assumptions and your users.

The short version

Compress your images, ship less JavaScript, defer third-party scripts, assume the network will fail, and test on the hardware your users own. None of it is exotic. It is just work that gets skipped because the app felt fine on the laptop it was built on.

• mobile apps
• performance
• Android
• Core Web Vitals