Why your site is slow in Accra and fast in the demo
A page that loads instantly on office fibre can take eleven seconds on a phone in Madina. Here's where the time actually goes.
Most performance advice is written for connections that Ghanaian users do not have. It assumes low latency, generous bandwidth and a recent device. Test the same page on a mid-range Android over mobile data in Accra and the numbers look nothing alike.
The single biggest cost is almost always images. A hero photograph exported straight from a design tool can be three megabytes. On a 4G connection that is several seconds before anything appears, and it blocks everything queued behind it. Resizing to the dimensions actually displayed, converting to WebP and serving a smaller file to smaller screens routinely removes eighty percent of a page's weight without anyone noticing a difference in quality.
The second cost is JavaScript, and it is subtler. Bandwidth determines how long a bundle takes to arrive, but the device determines how long it takes to parse and execute — and that is where cheaper phones struggle. A bundle that runs in 200ms on a laptop can take well over a second on a four-year-old Android. The fix is not clever code; it is less code, loaded later, and only where it is needed.
Third is latency, which no amount of optimisation removes. If your server is in Virginia, every request pays that round trip. Serving static pages from an edge network puts the response physically closer, and for content that does not change per visitor there is no reason not to.
None of this is exotic. It is compression, sizing and deferral — the unglamorous work that separates a site that performs in a demo from one that performs in someone's hand on the way to work.