Skip to main content
TekXpat

14 July 2026 · 4 min read

Why your website is slow in Malawi (and it is probably the fonts)

A site that loads instantly in the office can take eight seconds on a phone in Limbe. Here is what actually causes that, measured rather than guessed, and what we do about it.

There is a particular conversation we have had more than once. A business owner shows us their website on the office wifi. It loads immediately. They cannot understand why customers say it is slow.

Then we open it on a mid-range Android phone on a mobile connection, and it takes eight seconds before anything appears.

Both experiences are real. The office is not where your customers are.

What "slow" is actually made of

When someone opens your site on a phone, four things happen in order, and each one has to finish before the next can start:

  1. The phone looks up your domain and opens a connection.
  2. It downloads the HTML.
  3. It reads the HTML, finds the CSS and fonts, and downloads those.
  4. Only then can it draw text on the screen.

Step 4 is the one people feel. Google measures it as Largest Contentful Paint — how long until the biggest piece of content appears. Under 2.5 seconds is the target. Most Malawian business sites we have measured are well over four.

The interesting part is that step 3 is usually where the time goes, and fonts are usually why.

The font problem

Almost every site built in the last decade loads its fonts from Google Fonts. It is one line of code and it feels free.

It is not free. Here is what that line actually does:

  • The browser downloads your CSS.
  • Inside it finds a link to fonts.googleapis.com and opens a second connection to a different server.
  • That returns another stylesheet, which points at fonts.gstatic.com — a third connection to a third server.
  • Only then does it start downloading the font itself.

Each new connection costs a DNS lookup, a TCP handshake and a TLS negotiation. On a fast connection that is maybe 50 milliseconds and nobody notices. On a mobile network with 300ms of latency, each round trip costs real time, and you are paying for several of them before a single letter of your font has been downloaded.

Then, while all this is happening, the browser has a choice: show nothing, or show a fallback font and swap it later. Show nothing and your page is blank. Swap it later and your text jumps around as it reflows — which Google also measures, as Cumulative Layout Shift, and also penalises.

What we do instead

We put the font files in the project. They are served from the same server as everything else, over the connection the browser has already opened.

For this site, that is two files totalling 41 KB — one for the body text, one for the headings. No extra DNS lookup, no extra handshake, no third-party server that has to be up for our site to look right.

There is a second reason, which is less about speed and more about not getting stuck. Build environments cannot always reach Google's CDN. When the download fails, the build fails, and you cannot deploy — sometimes at exactly the moment you need to push a fix. A font file committed to the repository cannot fail to download.

Both of our clients' sites are built this way, and so is this one.

The other things worth doing

Fonts are the biggest single win, but they are not the only one.

Send fewer images, and send them smaller. A 3 MB photograph straight off a phone camera is common on business sites and is completely unnecessary. The same image at the size it will actually be displayed is usually under 100 KB and looks identical.

Reserve space for anything that loads late. If an image appears and pushes the text down, the person reading has lost their place — and Google counts it against you. Give every image an explicit width and height so the space is held before it arrives.

Do not ship JavaScript for things CSS can do. Animation libraries are convenient and heavy. A modern browser can run animations without any JavaScript at all, on a part of the phone designed for exactly that, and it stays smooth on hardware that would stutter under a library.

Target the phones people actually have. Build tools have a default list of browsers they support, and it quietly excludes older Android and older iOS. In Malawi those are not an edge case, they are customers. Widening that list costs a few kilobytes and includes people who would otherwise see a broken page.

How to check your own site

Open Chrome on a computer, press F12, go to the Lighthouse tab, choose Mobile, and run it. It will simulate a slow connection and a slow phone and give you a number.

Do not run it on your fast laptop connection without the throttling on — that is the office wifi problem again, and it will tell you everything is fine.

If your Largest Contentful Paint is over 2.5 seconds, the fonts are the first place to look.

We build websites for Malawian businesses and measure them on a throttled connection before they go live. If yours is slow and you are not sure why, send us the URL — we will tell you what is causing it, whether or not you hire us.