Indian SMB Sites Load in 9 Seconds on Jio. Your Customers Are on Jio.

You built your site, opened it on your office WiFi, scrolled it on your iPhone, and it felt fast. Of course it did. You are testing on a 500 Mbps connection with a phone that has a faster chip than most laptops sold in India.

Your customer is not you.

She is standing in a market in Indore, opening your link on Jio 4G that just dropped to two bars, on a 12,000 rupee Android phone with a mid-range chip and a browser tab that is already eating RAM. She taps your link. She waits. White screen. She waits more. Three seconds. Five. By the time your hero image shows up, she has already gone back to WhatsApp.

That is the gap nobody tells you about. The site you approve is not the site your customer loads.

The throttling math founders never see

Here is the part that hurts. When Google's PageSpeed Insights or Lighthouse tests your site on "mobile," it does not test on your conditions. It simulates Slow 4G. That means roughly 1.6 Mbps download, around 400 Kbps upload, and a 150ms round-trip delay added to every single request. On top of that it throttles the CPU to about a quarter of a normal machine, to fake a cheap phone.

That is not Google being mean. That is Google being honest about who actually uses the internet in India.

Now run the numbers on a typical SMB site I see every week. A 2.4 MB hero image that nobody compressed. Three Google Fonts loading four weights each. A chat widget, an analytics script, a pixel, and a "free" popup tool. Add it up and you are pushing 5 to 7 MB of stuff over a 1.6 Mbps pipe. Do the division. The network alone needs 4 to 5 seconds just to move the bytes, before the cheap phone's CPU even starts assembling the page.

Across the small-business sites I have audited this year, the median load on that Slow 4G profile lands around 9 seconds to interactive. Not the homepage you see. The homepage your customer sees.

What 9 seconds actually costs you

People throw around "speed matters" like it is some checkbox you tick for Google. Speed decides how many of the people you already paid to attract ever see your page. Every visitor who leaves during those 9 seconds was a click you spent money or effort to earn.

Google's own field data has been blunt about this for years. As page load goes from 1 second to 3 seconds, the chance of a bounce climbs sharply. By the time you cross into the 5 to 6 second range, the probability of someone leaving roughly doubles compared to a 1-second load. At 9 seconds you are not losing a few visitors. You are losing the majority of the people who clicked, and you paid for that click.

See, the cruel part is the cost stays the same. You spent the same money on the ad, the same effort on the Instagram post, the same favor asking a friend to share your link. The click happened. The visitor arrived. And then your own site threw them out before they read a word.

I watched this exact thing with a retainer client, Zulal. Their PageSpeed score on mobile was sitting at 39. Thirty-nine. I took it to 77 and did it for free, partly because I love the work and partly because goodwill pays you back later in ways you cannot predict. The traffic did not change. The bounce did. Same visitors, more of them stayed long enough to do something.

So the question is not "is my site nice." The question is "does my site survive a bad signal in a small town." Because that is where most of India is.

The fix order, in the exact sequence I use

Do not random-walk this. There is an order, because the heaviest, dumbest problems are at the top and the clever stuff is at the bottom. Most founders do it backwards: they tweak hosting and caching and skip the 2 MB image that is actually killing them.

1. Images first, always

Images are usually 60 to 70 percent of the weight on an SMB site. This is where 80 percent of your win lives.

Stop shipping PNGs and giant JPEGs. Use modern formats and let the browser pick. If you are on Next.js, the next/image component does most of this for you, but you have to actually use it and set the sizes.

import Image from "next/image";

export function Hero() {
  return (
    <Image
      src="/hero.jpg"
      alt="Handmade brass lamps from our Moradabad workshop"
      width={1280}
      height={720}
      priority
      sizes="(max-width: 768px) 100vw, 1280px"
      quality={70}
    />
  );
}

Two things doing the heavy lifting here. priority tells the browser to load this image now instead of lazily, because it is your largest contentful paint element. sizes stops a phone from downloading a desktop-width image it will never show. That alone can cut a hero from 2.4 MB to under 200 KB.

If you are not on Next.js, convert manually and serve WebP with a fallback:

<picture>
  <img
    src="/hero.webp"
    alt="Handmade brass lamps from our Moradabad workshop"
    width="1280"
    height="720"
    fetchpriority="high"
    decoding="async"
  />
</picture>

Always set width and height. An image with no dimensions makes the page jump around as it loads, and that jump is its own ranking and trust problem.

2. Fonts second

Fonts are the silent killer because the text is there, the browser has it, and then it hides your words for half a second waiting for a font file to arrive over Jio.

Two rules. Use font-display: swap so text shows immediately in a system font and swaps when the custom one lands. And stop loading four weights of three families when you use two. On Next.js:

import { Inter } from "next/font/google";

const inter = Inter({
  subsets: ["latin"],
  weight: ["400", "600"],
  display: "swap",
  variable: "--font-inter",
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={inter.variable}>
      <body>{children}</body>
    </html>
  );
}

This self-hosts the font, removes the round-trip to Google's font servers, and ships only the weights you named. Three round-trips gone, on a network where every round-trip is 150ms.

3. Scripts third

This is where the popup tool, the chat widget, the heatmap recorder, and the two analytics pixels live. Each one is JavaScript that the cheap phone's CPU has to download, parse, and run. On a throttled CPU, parsing 300 KB of third-party JS can take a full second of frozen screen.

Audit them honestly. Open the network tab, list every third-party script, and ask one question per script: did this make me money last month? If you cannot answer, kill it. When I audited my own site, webight.com, I found two leftover third-party scripts doing nothing but adding weight. I removed them. Gone.

For the ones you keep, load them late so they do not block your page from showing:

import Script from "next/script";

export function Analytics() {
  return (
    <Script
      src="https://example-analytics.com/script.js"
      strategy="afterInteractive"
    />
  );
}

afterInteractive means the script waits until your page is usable before it loads. Your customer sees content first, the tracking happens second. That is the right order.

One more thing from my own audit. I turned on experimental.inlineCss in next.config.ts and it inlined two render-blocking stylesheets, 22.5 KiB that were holding up the first paint. Small config change, real result.

4. Hosting region last

This is last because it is the smallest win, but it is a free one and people get it wrong constantly. If your customers are in India and your server is in Virginia, every request crosses an ocean. That is 200 to 300ms added round-trip on top of the Jio delay.

Host in or near India. On Vercel, set the region to Mumbai (bom1). On most platforms it is a one-line config or a dropdown.

// next.config.ts equivalent for serverless functions on Vercel
// vercel.json
{
  "regions": ["bom1"]
}

Mumbai is the closest major edge to most Indian users. Combine that with a CDN that caches your static assets at Indian edge nodes and your time-to-first-byte drops from "ocean" to "across town."

Test the way your customer lives

Here is the thing you can do today, in ten minutes, for free.

Open Chrome DevTools. Go to the Network tab. There is a dropdown that says "No throttling." Change it to "Slow 4G." Then open the Performance tab and add CPU throttling, set it to 4x slowdown. Now reload your homepage.

That screen you are looking at? That is your customer in Indore. Not the one on your iPhone.

Run PageSpeed Insights too, but read the mobile number, not the desktop one. The desktop score is a lie you tell yourself. The mobile score on Slow 4G is the truth your revenue runs on.

I did this on my own site and the audit found a 4,190ms render delay on the hero headline, caused by an animation waiting for the page to hydrate before it showed the text. I swapped it for a CSS animation that runs immediately, and the render delay dropped to 382ms. My own site. The point is everyone has this, including the people who build sites for a living.

So stop testing your business on the best phone and the best connection you own. Go open your site on Slow 4G right now, watch it crawl, and fix it from the top of that list down. Your customer already made her judgment in second three. The only question is whether you will see what she saw before she leaves for good.

If you run a Slow 4G test and your number scares you, send it to me. I will tell you which one of the four to fix first.