Why Your Website Is Slow for Nepali Visitors

A site that loads in under a second on office fibre can take eight to twelve seconds on a mid-range phone on mobile data outside Kathmandu. The difference is not your imagination and it is usually not your framework.

Four causes account for most of it. Measure before you fix, because the order matters and the fixes are not equally cheap.

Distance to the server

If your server sits in the United States, every request from Nepal crosses roughly half the planet and back. That round trip is physics; no amount of code tuning removes it, and it applies to every asset the page requests.

A CDN fixes most of this by serving static files from an edge location near the visitor. Singapore and Mumbai edges are meaningfully closer to Nepal than anything in North America. What a CDN cannot fix is a slow database query on the origin, so this helps pages that are mostly static far more than it helps a dynamic dashboard.

Images nobody optimised

This is the most common cause and the easiest to fix. A hero image exported straight from a design tool can be 2 to 4 MB. On mobile data that is several seconds by itself, and it is often displayed at a fraction of its actual dimensions.

Three changes, in order of value: resize to the size actually displayed, serve WebP or AVIF with a fallback, and lazy-load anything below the fold. Most frameworks have this built in and unused. Next.js has an image component that handles all three, and plenty of Next.js sites still ship raw img tags.

Fonts blocking the text

A custom web font that loads before text renders leaves a visitor staring at a blank area while the file downloads. On a slow connection that can be several seconds during which the page looks broken rather than slow, which is worse.

Set font-display to swap so text renders immediately in a fallback and switches when the font arrives. Subset the font to the characters you actually use, and self-host rather than loading from a third party, which removes a DNS lookup and a connection to another origin.

If your site serves Devanagari, check the file size specifically. Nepali and Hindi fonts carry far more glyphs than a Latin face, and an unsubsetted one can be several hundred kilobytes on its own.

Third-party scripts

Analytics, chat widgets, tag managers, social embeds, ad pixels. Each is a request to someone else's server, and your page waits on servers you do not control and cannot tune.

Audit them once a year. In practice a site accumulates scripts for tools nobody uses any more, and removing those is free performance. Load what remains after the page is interactive rather than in the head.

How to find which one is yours

Open your browser's network panel, throttle to slow 4G, disable the cache, and reload. Sort by size and by time. The single largest item and the single slowest item are usually your two problems, and they are frequently the same file.

Then check the field data in Google Search Console if you have it verified, because that reports what real visitors experienced rather than what your laptop did. Lab tests tell you what is possible; field data tells you what is happening.

What good looks like

Aim for the largest content on the page to appear within about two and a half seconds on a mid-range Android phone on mobile data, and for the layout to stop moving once it has. Those two targets cover most of what a visitor experiences as fast.

We measure this before handover on every site we build. Not as a guarantee, because the number moves with the visitor's device and network and with whatever scripts get added later, but as a baseline you can hold future changes against.