Every developer has had this conversation. The client says the site is slow. You open it, it appears instantly, and you say — carefully, because you can hear how it sounds — that it seems fine on your end.
You are both right. You are testing on a fast connection, on a good device, close to the server, with the whole site already cached from the last time you looked at it. Almost none of that is true for the person complaining.
When I audited 34 live Nepali websites in August, I recorded response timings alongside the technical checks. I have written about that dataset before, but not about this part of it, and the timings turn out to say something quite different from the usual advice about compressing images.
What the numbers actually looked like
These are server response times — time to first byte, measured from a single fetch of each homepage. TTFB is the part of loading that happens before the browser has anything at all to work with: DNS, connection, TLS, and the server deciding what to send.
- Median time to first byte: 849 milliseconds
- Fastest: 31 milliseconds
- Slowest: 10,367 milliseconds — over ten seconds
- 13 of 34 took longer than one second
- 5 of 34 took longer than two and a half seconds
The spread is the interesting part, not the median. A range from 31ms to 10.4 seconds inside one small sample of the same country's websites means the slow sites are not slow because of Nepal. They are slow because of decisions. The fastest site in the sample proves the ceiling is not the problem.
Ten seconds to the first byte is worth sitting with. Nothing has been downloaded yet at that point. No image, no font, no stylesheet. The visitor has been looking at a blank tab for ten seconds and the server has not yet finished saying hello.
Why images are usually the wrong thing to blame
Image weight is the standard answer to "my site is slow", and it is the one thing most site owners have already tried. It is often not where the time is going.
The median HTML document in the sample was about 27KB, which is unremarkable. If a site with a 27KB homepage takes two and a half seconds to send it, compressing a hero image will not help, because the delay happened before the image was ever requested. Slow TTFB is a hosting, database, or application problem. You cannot optimise your way out of it in the front end.
What I did find in the images was a different problem entirely. Across the sample there were 2,167 images, and 1,584 of them had no width or height attributes — roughly three in four.
Missing dimensions do not make a page slower. They make it feel broken. The browser does not know how tall an image will be until it arrives, so it lays the page out without it and then shoves everything down when it loads. That is the jump that makes you tap the wrong link. Google measures it as Cumulative Layout Shift, and it is one of the few performance problems that is genuinely free to fix: put the real width and height on the tag and the browser reserves the space in advance.
Three in four images is not an oversight, it is a default. Whatever built these sites was not writing dimensions, and nobody checked.
The one that surprised me: 21 render-blocking scripts
The worst site in the sample had 21 scripts in the head of the document, none of them deferred.
A script in the head without defer or async stops the parser. The browser reaches it, stops building the page, fetches the file, executes it, and only then carries on. Twenty-one times, in sequence, before the visitor sees anything. On a fast connection each of those might cost 40 milliseconds and nobody notices. On a congested mobile connection each one is a round trip, and the page is functionally dead until they have all finished.
This is the cheapest fix in performance work and almost nobody does it. Most of those scripts do not need to run before the page renders. Analytics does not. Chat widgets do not. Adding defer to a script tag takes seconds and changes nothing about what the script does — only when it does it.
The conditions your visitors are actually in
Two things make Nepali traffic behave differently from a developer's test, and neither shows up on your laptop.
Latency, not bandwidth. Most performance advice is written about bandwidth, because that is the number people quote. But loading a page is mostly a conversation — request, response, request, response — and each exchange costs a round trip. Distance and congestion make round trips expensive. A site that needs thirty sequential requests before it renders will be slow on a high-latency connection regardless of how fast the connection is rated, because the delay is in the waiting, not the transferring.
Devices. A mid-range Android phone parses and executes JavaScript several times slower than a development laptop. Every kilobyte of script costs more on the device the site is mostly being viewed on. Throttle the CPU in developer tools once and you will stop treating that as a rounding error.
There is also a distinctly local version of the caching problem. A CDN caches per edge, and edges refresh independently — which means the version of your site being served in one place can differ from another. I have watched the same URL return two different files on consecutive requests, which I wrote about in the outage where my site returned 200 and served nothing. It matters here because it means testing once from one location tells you less than you think.
What I would actually do, in order
Roughly the order of return on effort, based on what the sample shows is broken:
- Measure TTFB first. If it is over a second, stop reading about images. The problem is your hosting or your application, and everything else is decoration on top of a delay you have not fixed.
- Defer the scripts in your head. Free, fast, and the single biggest render improvement on most of the sites in this sample.
- Put width and height on every image. Also free. Kills layout shift.
- Then compress images and add lazy loading below the fold. This is where most people start, and it is fourth.
- Test on a throttled connection and a throttled CPU, not on your own machine. Your machine is not evidence.
None of this is exotic and none of it requires rebuilding anything. Most of it is a config change and an afternoon.
Speed is not an SEO tactic
Core Web Vitals are a ranking signal, but a small one, and I would not spend a client's budget chasing them for their own sake. The reason to care is more direct: people leave. A visitor who waited ten seconds for your first byte has already gone back to the results page, and no amount of ranking well fixes that, because you did rank well — they clicked. You lost them after the click.
That is the same gap I wrote about in why websites get traffic but no customers: the metrics look fine right up until the point where the visit becomes a person. The full technical picture from the sample is in the audit writeup, and the raw data is published in full if you want to check any of these figures yourself.
The fastest site I measured answered in 31 milliseconds. It is not a big site or an expensive one. Somebody just did not put twenty-one scripts in front of it.