Your website is fast. You have checked. It loads instantly on the office wifi, on the laptop it was built on.
Your customer is on a four-year-old Android, on mobile data, with two bars of signal, standing in a shop. For them it takes eleven seconds, and they left after four.
That gap is not a mystery and it is not unfixable. It has four causes, and you can check for all of them yourself this afternoon.
First, measure it properly
Open Chrome on a desktop, load your site, press F12, go to the Lighthouse tab, choose Mobile, and run it. That gives you a throttled score — a simulated slower network and a slower processor.
Take the number seriously and take the individual metrics more seriously than the overall score. The one that matters most is Largest Contentful Paint: how long until the biggest thing on screen — usually your headline or hero image — is actually visible. Under two and a half seconds is acceptable. Over four and you are losing people who will never tell you they left.
Do it two or three times. Lighthouse scores on a busy machine are noisy, and a single run can be off by twenty points in either direction. If two runs disagree wildly, believe the metrics rather than the score.
Cause one: images
This is the biggest one, by a distance, and the easiest to fix.
A photograph straight off a camera or a design tool is often two to four megabytes. On mobile data that is several seconds by itself, before anything else happens. Multiply by six images on the homepage and the page is over before it started.
The fix is boring and total. Serve modern formats — AVIF or WebP rather than PNG or JPEG. Size the file to the space it actually occupies rather than uploading a 4000-pixel-wide image into a 600-pixel column. Set explicit width and height so the layout does not jump as images arrive. And do not load images that are below the fold until the visitor scrolls toward them.
Done properly, a photograph that was 2MB becomes 40KB and looks identical on a phone. That is not a marginal gain, it is the difference between eleven seconds and two.
Cause two: JavaScript before anything renders
Modern sites ship a lot of JavaScript. On a fast laptop that is invisible. On a mid-range Android — where the processor is genuinely several times slower — the browser has to download it, parse it and execute it before it can show anything, and that work is measured in seconds.
The specific failure to look for is a page whose text only appears after the scripts have run. If your headline is rendered by JavaScript rather than being in the HTML the server sent, every visitor waits for the whole framework to boot before reading a word.
You can check this without any tools: right-click, View Source, and search for your headline. If it is not in there, it is being drawn by JavaScript, and that is a fixable architectural decision rather than a fact of life.
Cause three: third-party scripts
Every analytics tag, chat widget, tracking pixel, embedded map and hosted font is a request to somebody else's server, which you do not control and cannot make faster.
Chat widgets are the usual worst offender. A live-chat bubble can weigh more than the entire rest of the page, and it is loading on every visit for a feature a small percentage of visitors use.
Count yours. Open the Network tab and look at what is being requested from domains that are not yours. Then ask, for each one, whether anybody has looked at its data in the last three months. The answer is often no, and removing it is free performance.
The ones you keep should load after the page is usable rather than before, and fonts should be self-hosted rather than fetched from another domain.
Cause four: where the server is
If your hosting is in the United States, every request from Nairobi crosses an ocean and back. That round trip has a floor set by physics, and no amount of optimisation gets under it.
Use hosting with a presence closer to your users, or a CDN in front of it that caches pages nearer to them. Most modern hosting platforms do this by default now, which is one of the few things that genuinely has got easier.
What to do on Monday
Compress every image on the site and convert them to AVIF or WebP. Remove every third-party script nobody has looked at this quarter. View source and confirm your main headline is in the HTML. Check where your hosting actually is. Re-run Lighthouse on mobile.
Those four together will move most Kenyan business websites from unusable-on-data to acceptable. What they will not do is fix a site whose whole architecture renders from JavaScript — that is a rebuild rather than a tune-up, and an honest developer will tell you which of the two you have.
Why this is worth the afternoon
Speed is not a technical vanity metric here. In a market where most of your traffic arrives on mobile data and most of your competitors' sites are also slow, being the one that loads is a genuine commercial advantage — for how many visitors stay, and for how Google ranks you against them.
We build every site against a throttled mobile profile rather than office wifi, because that profile is the honest one. It is also, uncomfortably, the one that makes you fix things.