A site that feels fast on a developer’s laptop can be slow on the budget Android phones many Indian visitors use, because those phones have much slower processors and less memory, and mobile networks vary. JavaScript is the biggest cost: it must be downloaded, parsed and run on a slow CPU. To perform well, test with CPU and network throttling or on a real mid-range device, ship less JavaScript, size images for small screens, limit fonts and third-party scripts, and use field data from real users to check the result.
Why low-end devices are different
- Processors can be several times slower than a laptop, so the same JavaScript takes several times longer to run.
- Less memory means browsers discard tabs and struggle with heavy pages.
- Network speed varies with location, time and signal, even on 4G and 5G.
Core Web Vitals in Search Console come from real Chrome users, so if your visitors use budget phones, their experience is what your scores reflect.
Test in realistic conditions
| Method | How |
|---|---|
| Chrome DevTools throttling | Performance panel: CPU throttling at 4x or 6x slowdown, network throttling set to a slow mobile profile |
| Lighthouse mobile | Simulates a mid-range phone and slower network by default |
| WebPageTest | Test on real or emulated mid-range Android devices from an Indian test location |
| A real device | Keep an inexpensive Android phone in the office and use it for every release |
| Field data | Search Console Core Web Vitals and the web-vitals library for your own users |
The fixes that matter most
1. Ship less JavaScript
- Render content pages on the server and send little or no JavaScript for them. In Next.js, keep pages as server components.
- Split code so each page loads only what it needs.
- Remove unused libraries, and replace heavy ones with smaller alternatives.
2. Right-size images
- Serve images at the size they are displayed, with srcset and sizes, in AVIF or WebP.
- Load the main image early and lazy-load the rest. See image SEO in Next.js.
3. Limit fonts
Self-host fonts, load only the weights you use, subset them to the characters you need, and use font-display: swap.
4. Control third-party scripts
Chat widgets, tag managers and heatmaps often cost more on slow devices than your own code. Delay or remove them. See performance budgets.
5. Keep interactions light
- Avoid heavy work in scroll and input handlers.
- Prefer CSS animations and transitions over JavaScript animation.
- Break long tasks so the page stays responsive. See fixing INP.
6. Respect data saving
Some browsers send a Save-Data header when users enable data saving. You can respond by serving lighter images or skipping autoplay video.
Set a target and track it
Aim to pass Core Web Vitals at the 75th percentile of real users. Record the metrics for key templates on your test device before and after each change, and check field data monthly.
Frequently asked questions
Which device should we test on?
A mid-range Android phone similar to what your visitors use. Analytics shows the most common devices on your site.
Does this matter for AI search?
AI crawlers read your server HTML rather than running your JavaScript, so a server-rendered, light page serves them and budget phones at the same time.
Is a separate “lite” site a good idea?
Usually not. One fast, responsive site is easier to maintain and avoids duplicate content.
Sources
- web.dev, “Web Vitals” and “Optimize Interaction to Next Paint”
- Chrome DevTools documentation, CPU and network throttling
- WebPageTest documentation, test locations and devices