3G/4G mobile internet in Uzbek regions: how network speed eats sales
Developers test on office fibre; buyers open the site on a minibus in a provincial capital. The experience gap is an order of magnitude.
The real conditions your site is opened in
Tashkent has solid 4G, but in regional centres and beyond phones routinely fall back to 3G, and at peak hours throughput drops to hundreds of kilobits. Add latency: 3G round trips easily reach 300–500 ms, so every extra request costs half a second.
A large share of the audience is on metered data plans. An 8 MB page is not just slow, it visibly spends the user's money — and they notice.
Test with Chrome DevTools throttling on Slow 4G and Fast 3G, not on your own phone. If the homepage does not render content within 5 seconds on Slow 4G, half your regional audience leaves before the first screen.
A page weight budget
A sensible local target: under 1 MB for the first screen including fonts and critical CSS, and 2–2.5 MB for the full page after lazy loading. JavaScript bundle: 150–200 KB compressed.
The biggest offenders, in order: unoptimised images, custom fonts shipping every weight, third-party analytics and chat scripts, and heavy UI libraries pulled in for two components.
Fix the budget as a measurable acceptance criterion or it dissolves by the third sprint. Lighthouse CI can fail the build when a threshold is exceeded.
Images come first
WebP cuts roughly 25–35% of weight at comparable quality; AVIF goes further at higher decode cost. Serve both through <picture> with a JPEG fallback.
Responsive sizes via srcset and sizes are mandatory: a 360 CSS-pixel phone does not need a 1920-pixel image. next/image handles this automatically, but only with a correct sizes attribute.
Set loading="lazy" on everything below the fold, and the opposite on the LCP image: fetchpriority="high" and no lazy loading. Always declare width and height or you inherit layout shift and a failing CLS.
Fonts, JavaScript and third-party scripts
Ship at most two weights, subset to the character ranges you need, use woff2 and font-display: swap. Split Cyrillic and Latin into separate subsets with unicode-range.
Load third-party scripts — chats, pixels, widgets — after interaction or with a lazyOnload strategy. A single live chat widget often weighs more than the rest of the site combined.
Server rendering beats client rendering on slow networks: the user sees finished HTML instead of a blank screen until the bundle lands. For content pages, prefer static generation served from a CDN.
What this does to sales
On a slow network users drop at three points: the blank screen before first paint, the delay after tapping a button, and the long form submission. Each loses its own slice of traffic.
Submit forms optimistically: show the result immediately and retry in the background. On 3G, a synchronous submit that waits for the server reads as broken, and people tap the button repeatedly.
Catalogues on slow connections do better with a load-more button than infinite scroll, because the user controls when data gets spent.
Keeping it under control
Lighthouse gives lab numbers; the real picture comes from field data in the Chrome UX Report and Search Console. Look at regional distribution, not the national average.
Wire a regression check into CI so the build fails when bundle weight or metrics cross the agreed threshold. Without automation a performance budget does not survive a quarter.
Every quarter, test on a real mid-range Android device with throttling on. A flagship iPhone on office Wi-Fi tells you nothing about your audience.