Why your site is slow in Dehradun but fast in your office
14 September 2026
A client once sent us a Lighthouse score of 97 and asked why their bounce rate was climbing. The score was real. It was also measured on a MacBook plugged into a 300Mbps office line, which is not how anyone outside the building was experiencing the site.
Test the way your users browse
A mid-range Android phone on a congested 4G cell has roughly a fifth of the CPU and a fraction of the bandwidth of a developer laptop. JavaScript that parses in 80ms on your machine can take 600ms on theirs, and that happens before anything is painted.
- Throttle to 4x CPU slowdown and Slow 4G in DevTools, not the default.
- Check field data in Search Console, not just lab scores.
- Test on a real mid-range handset at least once per release.
Fix in this order
1. Images
Images are still the single biggest win on most Indian business sites. Serve AVIF or WebP, size them to the container rather than the original upload, and set explicit width and height so the layout stops jumping. A hero image at 2.4MB is not unusual on sites we audit; the same image at 140KB is visually identical on a phone.
2. Third-party scripts
Chat widgets, heatmaps, three analytics tools and a review badge can easily add 900KB of blocking JavaScript. Audit what each one earns. In most audits at least half the tags are forgotten experiments nobody owns.
3. Fonts
Subset to the characters you use, preload the one face in the first viewport, and set a font-display strategy so text is readable while the custom face loads.
Performance is not a score to chase. It is the difference between a visitor reading your headline and a visitor seeing a blank screen and going back to the search results.
What good looks like
On the builds we ship, the target is LCP under 2.0 seconds on a throttled mid-range phone, interaction latency under 200ms, and no layout shift above 0.05. Those numbers are achievable on WordPress as easily as on Next.js — the platform matters far less than the discipline.