Making a website fast on a Nepali network.

Before changing anything, get a number you trust. Three tools, in this order, and each answers a different question.

• PageSpeed Insights. Run it and read the field data at the top, not the lab score below it. Field data is what real visitors experienced; the lab score is a simulation and it is the number people mistakenly optimise for.
• Search Console, Core Web Vitals report. This is the same field data grouped by page type, which tells you whether the problem is site-wide or confined to one template.
• Chrome DevTools, with the network throttled to Slow 4G and the CPU throttled four to six times. This approximates the device your customer owns and it is where the real culprits become obvious.

On most sites we audit, images are more than seventy percent of the page weight and the direct cause of a failing LCP. Four fixes, in descending order of return.

1. 1Serve the size you actually display. A 4000-pixel-wide photograph rendered into a 600-pixel column wastes roughly ninety-five percent of the bytes it cost. Generate multiple widths and let the browser choose with srcset and sizes.
2. 2Use a modern format. WebP is universally supported now and typically saves twenty-five to thirty-five percent over a comparable JPEG. AVIF saves more again where you can produce it.
3. 3Set width and height on every image, always. Without them the browser cannot reserve space, so the page reflows as each image arrives, which is most of a bad CLS score.
4. 4Lazy-load everything below the fold with loading="lazy", and explicitly do not lazy-load the hero image. Lazy-loading the LCP element delays the exact thing you are being measured on.

One more, less obvious: reduce quality further than feels comfortable on large soft images. Photographs with broad gradients or watercolour washes are visually indistinguishable at quality 60 and materially smaller than at 80. Detailed product shots need more. Judge per image rather than setting one global number.

Custom fonts are worth their cost, but most sites pay several times over for nothing. Three rules cover it.

• Two families, at most three weights each. Every additional weight is a separate file, and nobody has ever noticed the difference between six weights and three.
• Subset to the characters you use. A full Devanagari or Latin-Extended face is many times the size of the subset a given page actually needs.
• Set font-display: swap so text renders immediately in a fallback rather than leaving the page blank while the webfont downloads. Invisible text is worse than the wrong font for a quarter of a second.

Self-host or use a framework font loader that inlines the declarations. A stylesheet fetched from a third-party font host adds a DNS lookup, a TLS handshake, and a round trip before any text can render, on a connection where each of those is expensive.

A megabyte of JavaScript is not a megabyte of download problem. It is a download, then a parse, then a compile, then an execute, on a processor several times slower than the one you wrote it on. This is why sites feel worse on a mid-range Android than the numbers suggest they should.

• Audit what you actually ship. A jQuery plugin for one carousel, a date library for one format string, an icon font for six icons. Each is a common and entirely removable few hundred kilobytes.
• Defer everything non-essential. Analytics, chat widgets, heat-map tools, and social embeds have no business on the critical path. Load them after the page is interactive.
• Chat widgets and embedded video are the two heaviest third-party additions in common use. An embedded YouTube player costs hundreds of kilobytes before anyone presses play. Use a static thumbnail that swaps to the real player on click.
• Render your content in HTML on the server. If the text of the page requires JavaScript to appear, you have made every visitor and every crawler wait for a round trip to see words that could have arrived in the first response.
• Split by route so a visitor to one page does not download the code for all the others.

A note on tag managers

Tag managers are convenient and they accumulate. We regularly find containers loading six or seven tools nobody at the company remembers commissioning, several of them redundant. Audit the container annually and delete what is not read.

The fastest possible site still waits for the first byte. Two decisions govern that, and both are cheap.

• Use a CDN. If your server is in Singapore or Frankfurt and your customer is in Biratnagar, every uncached request crosses that distance twice. A CDN puts a copy near them, and for static sites it eliminates most of the latency entirely. Cloudflare’s free tier is sufficient for most businesses in this market.
• Do not run e-commerce or anything database-backed on the cheapest shared hosting. Shared plans are oversold by design, and time-to-first-byte on a busy shared host regularly exceeds a second before your code has done anything at all.
• Enable compression. Brotli where available, gzip otherwise. It is a server setting and it typically cuts text payloads by seventy percent.
• Set long cache headers on assets with hashed filenames, so returning visitors download almost nothing.

If you do nothing else, do these five things in this order. On a typical slow site they account for the large majority of the available improvement, and none of them requires touching the design.

1. 1Resize and convert every image to WebP at the dimensions actually displayed, and set explicit width and height on all of them.
2. 2Put a CDN in front of the site and turn on Brotli compression.
3. 3Cut font families and weights to what the design genuinely uses, and add font-display: swap.
4. 4Move analytics, chat, and every other third-party script off the critical path.
5. 5Replace embedded video and map iframes with click-to-load placeholders.

Then measure again, in field data, after a few weeks rather than the same afternoon. Field data is a rolling twenty-eight day window, so it moves slowly by design, and reading it the day after a deployment will tell you nothing.