Website performance on mobile is not what you see when you open your site on an iPhone 13 connected to office WiFi. It is what your customer sees on a Rp 2 million Android with 3 GB of RAM, on a crowded 4G cell, in a mall basement in Bekasi. Those are two different websites, and only one of them earns you money.

I wrote earlier this year about why site speed matters for revenue. This is the hands-on sequel: an actual testing protocol you can run this week, and a prioritized fix list based on where I consistently find the biggest payoff. Nothing here requires rebuilding your site.

The gap is bigger than most owners expect. I recently tested an SME e-commerce site that loaded in 1.8 seconds on the developer's laptop. On a mid-range Android over throttled 4G, first meaningful content took 11 seconds. The developer was not lying, and neither was the customer who gave up. They were just on different planets.

Step 1: test like your customer, not like your developer

You need two things: a realistic device and a realistic connection. Here is the protocol.

Get a real budget device. Buy or borrow a phone in the Rp 1.5 to 2.5 million range, a Redmi, a Realme, a Samsung A-series. This is what a large share of Indonesian users actually carry. Keep it as your permanent test device. Chrome's device emulation is useful, but it runs on your laptop's CPU, and CPU is exactly where cheap phones suffer. JavaScript that parses instantly on a MacBook can take four to six times longer on a budget Android chipset.

Throttle the connection. Two options:

  1. In Chrome DevTools on your laptop, open the Network tab and set throttling to "Fast 3G". It is pessimistic, which is the point.
  2. On the real device, turn off WiFi and test on actual cellular data, ideally away from your office, where signal is unrealistically good.

Clear the cache first. Your customer arriving from an Instagram ad has nothing cached. Test in an incognito tab or clear browsing data, then time the experience by hand: when can you read something, when can you tap something, when does it stop jumping around.

Get the numbers. Run your key pages through PageSpeed Insights, and look at the mobile score, not desktop. Focus on three metrics: Largest Contentful Paint (when the main content appears, aim under 2.5 seconds), Total Blocking Time (how long scripts freeze the page), and Cumulative Layout Shift (how much things jump). PageSpeed also shows field data from real Chrome users if your site has enough traffic, and that data outranks any lab test.

Write down your baseline numbers before touching anything. You cannot claim improvement without a before.

Step 2: the fix list, in order of payoff

After doing this on dozens of SME sites, the same four fixes account for most of the improvement, in roughly this order.

Fix 1: images (usually 60 to 80 percent of the problem)

Nearly every slow SME site I audit is shipping camera-original photos. A 4 MB JPEG straight from a phone camera, displayed in a 400-pixel-wide product card, is pure waste.

  • Resize images to roughly the size they display. A product thumbnail does not need 4000 pixels of width.
  • Compress them. Tools like Squoosh or TinyPNG cut file size by 70 to 90 percent with no visible difference.
  • Serve WebP where you can. Most platforms and CDNs can do this automatically now.
  • Set explicit width and height attributes so the layout does not jump while images load.

Real numbers from a recent job: a homepage went from 9.2 MB to 1.4 MB from image work alone, and LCP on throttled 4G dropped from 10.5 seconds to 3.9.

Fix 2: lazy loading

Do not make the phone download the entire page to show the first screen. Add loading="lazy" to every image below the fold. It is one attribute, supported by every current browser, and on long product-listing pages it routinely cuts initial download by half or more. Keep the hero image eager, lazy-loading the first thing the user sees makes it slower.

Fix 3: the script diet

Open the Network tab and count the third-party scripts. Typical SME site: two analytics tools, a heatmap tool nobody has opened in a year, three chat widgets from different eras, a slider library, and a font service loading six weights. Each one costs download time, and worse, CPU time on that budget chipset.

  • Remove anything not actively used. Be honest.
  • Load the chat widget after the page is interactive, or on first scroll, instead of upfront.
  • Cut font weights to the two or three you actually use.
  • If your theme loads jQuery plus three plugin libraries to power one carousel, that carousel is expensive.

On cheap Androids, Total Blocking Time is where scripts hurt most. A page can look loaded but ignore taps for seconds because the CPU is choking on JavaScript. That feels broken to the user even when the waterfall says fine.

Fix 4: hosting and caching

If the first byte from your server takes 2 seconds, no frontend work saves you. Check the "time to first byte" in DevTools. Common causes: overloaded shared hosting at Rp 300 thousand a year, servers located outside the region serving Indonesian users, and no caching so every visit rebuilds every page. Moving to decent hosting with a CDN typically costs Rp 100 to 300 thousand a month and is often the cheapest second per rupiah you can buy.

Step 3: re-test and set a budget

Run the same protocol after the fixes and compare against your baseline. A realistic target for an SME site on throttled 4G with a mid-range device: main content visible under 3 seconds, page interactive under 5.

Then set a performance budget so it does not decay: for example, no page over 1.5 MB, no image over 150 KB, no new third-party script without removing one. Put it in writing with whoever maintains the site. Performance is not a one-time project, it is a weight class you commit to staying in. This is a small piece of a bigger discipline I covered in why your business needs a technology strategy, not just a website, and the accumulated shortcuts that make sites slow are close cousins of technical debt.

The takeaway

Your customers are not on your WiFi and not on your phone. This week:

  1. Test your site on a budget Android over real or throttled cellular data, incognito, and write down the numbers.
  2. Fix images first: resize, compress, lazy-load. It is most of the win for the least effort.
  3. Delete or defer the scripts you are not truly using.
  4. Check time to first byte, and upgrade hosting if the server itself is slow.
  5. Re-test, then set a written budget so the site stays fast.

The whole exercise costs a borrowed phone and a few days of focused work. The alternative is quietly losing every customer whose phone costs less than yours, which in this market is most of them.