If your website is slow on a cheap Android, you have already lost the visitor

Open your website on the cheapest Android phone you can find. Maybe it is the one your driver carries, or the one your shop assistant has. Time how long it takes from a cold tap until the page is actually useful. If that number is more than three seconds, you have already lost a meaningful share of your potential customers.

This is not a vanity metric. Page speed on a mid-range Android over a 4G connection is the single most consequential technical decision for almost every business website in East Africa. Here is why, and the four things that fix it most of the time.

The two facts that decide everything

1. Almost all East African web traffic is mobile. Across the retainers we manage in Tanzania, Kenya, Uganda and Rwanda, mobile sessions run between roughly 75% and 95% of total. We rarely see a site below 70%.

2. A large share of that mobile traffic is on connections that are not at full 4G speed. Patchy LTE in central Dar or Nairobi at peak hours. 3G on the road between Arusha and Moshi, or between Kampala and Jinja. Genuinely slow connections in many neighbourhoods outside the major cities.

A website that loads in 1.4 seconds on a Mac in a Masaki or Westlands office is not the same website that loads in 6.2 seconds on a mid-range Android in Mbezi Beach or Eastleigh at 19:00. The same code, the same design, a completely different experience.

Google knows this. Google ranks accordingly.

What "fast" actually means in 2026

Google’s Core Web Vitals are the standard. There are three numbers and you should be able to recite them:

• LCP (Largest Contentful Paint): under 2.5 seconds. The hero image or headline showing up.
• INP (Interaction to Next Paint): under 200 milliseconds. How fast the page responds when someone taps something.
• CLS (Cumulative Layout Shift): under 0.1. The amount the page jumps around as it loads.

Run your homepage through pagespeed.web.dev. Read the mobile number, not the desktop one. That is the score that matters.

If the mobile number is below 80, you have a performance problem. If it is below 60, you are losing business every day.

The four fixes that move the needle for most sites

1. Compress your images, properly

The single biggest source of weight on most small-business websites is an unoptimised hero image. A 4.2MB JPEG straight from the camera, displayed as a 1280px wide hero, downloaded by every visitor.

The fix is to serve images in AVIF or WebP, at the actual size they will be displayed, with explicit width and height so the page does not jump as they load. Most modern build tools do this automatically. If yours does not, switch tools.

2. Use less JavaScript than your designer wants to

Animation libraries, page builders, third-party widgets, chat popups, six different analytics scripts - they all run JavaScript. JavaScript runs on the user’s phone, not your server. A cheap phone executes JavaScript far slower than a Mac, and every kilobyte of script blocks the page from being useful.

The fix is a ruthless audit: what does this script do, who asked for it, and can we remove it. The answer is usually yes more often than designers like.

3. Host somewhere that serves East Africa well

A site hosted on a server in Johannesburg or Frankfurt with a global CDN edge in Dar, Nairobi, Kampala or Kigali will feel meaningfully faster than the same site on a server in Texas with no CDN. This is not a minor difference, it is often a full second on first paint.

Most modern static-site platforms (Vercel, Netlify, Cloudflare Pages) include a global CDN by default. If you are still on a single-region VPS for a marketing site, you are leaving speed on the table.

4. Render the important stuff first

If your hero section depends on JavaScript to render, mobile visitors stare at an empty screen for two seconds while the script downloads and runs. The fix is server-rendered or statically generated HTML - the page is useful as soon as the HTML arrives, and any interactive features hydrate in afterwards.

If you are using Next.js, Astro, or even WordPress with a properly cached page cache, this is mostly handled. If you are using a heavy single-page React app for a brochure website, you are using the wrong tool.

What this is worth to you

Published performance case studies across the industry consistently report, after a real performance fix on a previously-slow site: meaningfully lower mobile bounce rates, more form submissions at the same traffic, and a measurable improvement in organic ranking over the following 3–6 months.

That is from fixing performance only. No other change. We hold our own builds to that standard from day one, and we will publish our own numbers as engagements ship.

If you have not measured your site in the last six months, do it this week. The fix list is usually shorter than you think.

---

If you want us to do the audit and the fix, see Website Design & Development and Website Management & Care. Or plan your growth on a 30-minute call.