Built for Nepal's phones: how your website performs on real 4G and budget Android

Most Nepali visitors will open your website on an Android phone over 4G, not on the office laptop it was designed on. On that setup, a typical 2.6 MB page with 632 KB of JavaScript takes roughly four seconds to become usable on a decent connection and well over ten on a weak one. Google's line for a good experience is 2.5 seconds. Lighter pages get under it.

How do most Nepalis actually reach your website?

On a phone. The Nepal Telecommunications Authority's latest report, for Shrawan 2083 (mid-July to mid-August 2026), counts 31.3 million broadband subscriptions. Of those, 27.7 million, or 88.6%, are mobile broadband. Fixed wired connections are 3.55 million. Subscriptions are not people, since many Nepalis carry two SIMs, but the direction is not in doubt. And 4G is the default: about 27 million subscriptions, with roughly 745,000 still on 3G.

Browsing data points the same way. StatCounter's figures for July 2026 put 61% of web page views in Nepal on mobile and 38% on desktop. On mobile, Android carries 74% of page views. By vendor, Xiaomi (19%) and Samsung (18%) lead the Android pack, followed by Realme, Vivo and Oppo at roughly 5-6% each, brands whose ranges run well down into the budget end. Apple shows 26%, which is higher than many expect. StatCounter counts page views, not handsets, and iPhone owners tend to browse more, so read that as a floor for Android rather than a ceiling.

How fast is mobile internet in Nepal, really?

Here is the honest answer: nobody publishes a trustworthy current median. Ookla dropped Nepal from its mobile Speedtest Global Index from June 2024, because Nepal's results failed its consistency rule, which needs three-month average speeds to stay within about 5%. The gap between operators was simply too wide, as NepaliTelecom reported in June 2025. Fixed broadband stayed in the index, at a median of 84.6 Mbps in February 2026, 90th in the world.

That inconsistency is the real finding. The same page, in the same city, can feel quick on one network and painful on another, or on the same network at 8 pm. So we plan for a range, using two well-documented reference points. Alex Russell's 2026 baseline for the 75th-percentile mobile user worldwide is 9 Mbps down, 3 Mbps up and a 100 ms round trip, on a Samsung Galaxy A24 4G that cost about $250 at launch. Lighthouse, Google's own audit tool, tests mobile at 1.6 Mbps and 150 ms, which it describes as roughly the bottom quarter of 4G connections. Neither is a Nepal measurement. Treat them as a sensible middle and a sensible worst case.

Why does a budget Android phone make a heavy site even slower?

Because bytes are only half the cost. Images just need to download and decode. JavaScript has to be downloaded, then parsed, compiled and run on the phone's processor, usually on a single core, and the page often cannot respond to a tap until that work is done. Russell's 2026 analysis finds low-end Android single-core performance still about nine times slower than a current iPhone, and mid-tier phones more than 3.5 times slower. The V8 team, who build Chrome's JavaScript engine, measured the same pattern years ago: a median phone took three to four times longer than a high-end one to run Reddit's JavaScript, and a low-end phone over six times longer.

Meanwhile, pages keep getting heavier. The HTTP Archive's Web Almanac 2025, based on a July 2025 crawl of millions of sites, puts the median mobile home page at 2.6 MB, up 8.4% on the year before, with 632 KB of JavaScript. Compare that with the budgets Russell sets for a three-second load on that 75th-percentile phone and network.

The median site is over both budgets. That is the uncomfortable part: "average" is already too heavy for the phones most of your customers carry.

What happens between the tap and a usable page?

A first visit to a page is a relay race with two halves. The first half crosses the network, where every step costs at least one round trip. The second half runs on the phone, where every script costs CPU time. At a 100 ms round trip, finding your server, opening a secure connection and asking for the HTML can burn 300-400 ms before a single byte of your page arrives.

Two things follow. A CDN helps the network half by shortening the distance for every round trip and serving cached files without waking your origin server. But nothing on the network side helps the phone half. If a page needs 600 KB of JavaScript before it works, a budget Android will spend well over a second on it even on fast fibre.

Does a slow site actually cost a Nepali business anything?

It can, in two ways. The first is search. Google completed its move to mobile-first indexing in 2023, which means it crawls and ranks the mobile version of your site. Its Core Web Vitals treat a Largest Contentful Paint of 2.5 seconds or less as good and anything over 4 seconds as poor, measured across the 75th percentile of real visits. Russell notes that not even half of sites pass Core Web Vitals for mobile users. Be clear about the weight, though: relevance and content quality matter far more than speed for rankings. A fast page with nothing useful on it won't rank. A slow page with a better answer often still will. The same logic applies to AI search, which we covered in how Nepali businesses stay visible in Google's AI Mode.

The second is people. Deloitte's "Milliseconds Make Millions" study for Google tracked 37 brands in Europe and the US and found that a 0.1-second improvement in mobile site speed went with 8.4% more retail conversions and 10.1% more travel conversions. That's a correlation across foreign brands, not a promise for a Kathmandu store. We would not put a rupee figure on it. But the direction matches common sense: a customer on a slow connection who waits eight seconds for a menu has plenty of time to open a competitor's page instead.

How long would your site take on a Nepali phone?

The estimator below runs the maths for a first visit. Pick a page, a connection and a phone. It adds up connection setup, download time and JavaScript processing, then checks the total against Google's 2.5-second line. It is deliberately simple and the assumptions are listed underneath it.

Two results tend to surprise people. On home fibre, a budget Android still spends about 1.4 seconds just running the median page's JavaScript. And on weak 4G, download time swamps everything else, so every megabyte you cut is worth more than any server upgrade.

How do you build a website for Nepal's phones?

None of this needs exotic technology. It needs decisions made early and kept.

• Set a performance budget before design starts. For a content or brochure site we aim well under Russell's JS-light line: roughly 1 MB per page and under 150 KB of JavaScript.
• Send real HTML. Pre-build pages as static files or render them on the server, so text and images appear before any script runs.
• Fix images first. Serve AVIF or WebP, size them for the screen with srcset, give them width and height so the layout doesn't jump, and lazy-load anything below the fold.
• Ship less JavaScript. Question every slider, chat widget, tracker and animation library, and split what remains into small chunks. The V8 team suggests splitting bundles above roughly 50-100 KB.
• Put a CDN in front and cache hard. Static files with hashed names can be cached for a year, so repeat visits skip most of the network half.
• Test on a real budget phone on mobile data, not on office fibre. Use Lighthouse's mobile profile as a floor, and watch real-user data once you have traffic.

If you already have a site that fails these tests, a rebuild is not always the answer. Often the images and third-party scripts account for most of the weight. When the platform itself is the problem, our blueprints for a mobile-first booking platform rebuild and re-platforming a legacy storefront for speed show how we would approach it.

Where should you start this week?

Open your site on the cheapest Android phone in the office, switch off Wi-Fi, and time how long it takes before you can tap something useful. Then run Google's PageSpeed Insights on mobile. If both tell you the same story, you know where you stand. Most of the fixes above are cheaper than a new site, and the first two, image sizes and third-party scripts, often halve the page weight on their own.

This is the work our Studio Engineering team does every day: websites and apps built for the phones and networks Nepal actually has, with a measured budget rather than a guess. If you'd like a second opinion on your own site, send us the link or read more about how we build.