There is a standard we apply to everything we build, and it sounds like a technical footnote until you follow it through: a page must be usable within three seconds on a 3G connection.
Not on office broadband. Not on a recent phone. On the connection and the device most of this market actually has.
That single constraint shapes more decisions than any design choice we make, and it is the one clients are most often surprised by, because performance is usually sold as refinement. Here it is not refinement. It is whether the product exists for the person trying to use it.
Performance is an access question
Ghana had 24.3 million internet users in 2025 and 77 percent of web traffic arrives on a mobile device. A large share of that is on prepaid data, bought in bundles, consciously rationed.
Now consider what a heavy page costs that person. It is not only the wait. It is data they paid for, spent before they saw anything useful. A visitor on a metered connection who watches a blank screen for eight seconds is not experiencing a slow website. They are watching money leave their bundle for nothing, and they will close the tab.
A site that only performs on good infrastructure has quietly decided which customers it serves. That decision is usually made by accident, in a code editor, by someone who has never had to think about a data bundle.
The same logic applies to a student opening a revision session on a shared phone, or a shop owner checking stock between customers. Slow is not an inconvenience in those moments. It is a reason to stop.
What the constraint actually forces
Committing to three seconds on 3G is uncomfortable, because it removes options that are otherwise easy to reach for.
- Fonts. Every external font is a blocking network request before text appears. We load a small, deliberate set, and we do not add one because a design looks marginally better with it.
- Images. WebP, compressed, lazily loaded below the fold, with width and height declared so the layout does not jump while they arrive. An image with no declared size shifts the page under the reader's thumb, which on mobile means mis-taps.
- JavaScript. Split by route, so a visitor reading one page does not download the code for twenty others. Nothing blocking in the head.
- Third-party scripts. The hardest one to hold. Every analytics tag, chat widget and pixel is someone else's code on your critical path, and each is individually easy to justify. Collectively they are usually the largest thing on the page.
We target a Lighthouse performance score of 90 or above on mobile, and under 150KB of initial load on the lightweight tools. Those numbers are not aspirations written in a proposal. They are the pass mark.
The part that gets skipped
Most performance work fails for an unglamorous reason: it is measured in the wrong conditions.
A developer in an office, on fibre, on a fast laptop, with the browser cache warm, will find almost any site fast. Everything passes. The site ships. Then real users arrive on mid-range Android phones over mobile data, and the experience bears no resemblance to what was tested.
Testing has to happen throttled, on a cold cache, at mobile viewport, or it is not testing. It is confirmation. We check at 375 pixels wide because that is where the design has to survive, not at 1440 where everything looks composed.
Why this connects to being found
Speed is not only a user experience concern. It feeds directly into both discovery channels.
Search engines measure loading performance as a ranking input, so a slow site competes at a disadvantage before its content is even considered. Meanwhile a page whose content only appears after JavaScript runs is a page some crawlers will read as empty, which means the words you wrote may never be indexed or quoted.
This is why our marketing pages ship as prerendered HTML rather than an empty shell that fills itself in. The first response contains the actual text and its structured data. A crawler, an AI assistant, or a person on a bad connection all get the substance immediately, without executing anything.
The same discipline serves the slow-connection user and the machine reading on someone's behalf. That is a rare alignment, and it is worth building around.
Check your own
You do not need tooling to get a useful answer.
- Open your site on your phone, on mobile data, with wifi off. Count out loud until you can read something. That number is your real load time, and it is the only one your customers experience.
- Do it again somewhere with weak signal. A queue, a lift lobby, the far side of a building. This is where a meaningful share of your traffic actually is.
- Watch whether things move as the page settles. Content that jumps around while loading means sizes were never declared, and every mis-tap it causes is a small tax on the visitor's patience.
If any of that is bad, no amount of design or copy will rescue the page, because most people will never reach the part you spent the money on.