Almost every website has this gap: it opens instantly on the computer in your office, and a customer taps the link you sent while out and stares at a blank screen for five seconds.
The reason is not mysterious. You are testing in conditions several orders of magnitude better than your customers have.
Your machine is on wired internet or strong wifi, with a fast processor and every asset from the site already in the browser cache, because you have refreshed it many times. Your customer is on 4G with two bars, using a mid-range phone from three years ago, visiting for the first time with nothing cached.
Four causes, ordered by how much they contribute.
1. Fonts
Severe on Chinese-language sites in particular, and very easy to miss, because it does not happen on your computer at all — your system already has the font.
It arises like this: the design specifies an attractive Chinese typeface. Devices that have it use the local copy; devices that do not must download it. A complete Chinese font file is usually several megabytes, because it contains tens of thousands of characters.
We hit this on our own site: the body font stack fell through to a web font, so every Chinese character on the page triggered a download — close to a megabyte, measured. None of which happens on your machine, where the font is installed locally.
There are several layers of fix:
Use system fonts for body text. Every operating system ships a decent Chinese typeface. Using them downloads nothing. The visual difference is far smaller than the difference between a page and a blank screen.
Use a custom font only for headings, and package only the characters used. Headings contain a few hundred distinct characters at most, so a subset file can be generated from exactly those. Ours came to 49KB — around twenty times smaller.
Declare local fonts first. A font declaration can name local typefaces before the file, so devices that have one use it and never download anything. Most visitors then never trigger the download at all.
2. Images
The second largest contributor, with the simplest cause: uploading photographs straight off a camera or phone.
A phone photo is typically 3 to 8MB and four thousand pixels wide. The space it occupies on the page might be 800 pixels. The browser scales it down for display and downloads the original regardless.
Three of those is over twenty megabytes, which on 4G is ten seconds and more.
What to do: generate several sizes matched to actual display width and let the browser choose; convert to a more efficient format; defer anything below the fold. All standard practice now, handled automatically by the tooling — the only question is whether anyone configured it.
Checking is easy: open your site on a phone and look at total transfer in developer tools. Under 1MB for a company home page is reasonable; over 3MB warrants investigation.
3. Scripts
Every third-party service added to a page brings another script to download and execute: analytics, chat widgets, ad pixels, maps, font services, comment systems.
Each looks small and together they routinely exceed the page itself. Scripts also differ from images: a slow image only appears late, while a script consumes processor time, and on a mid-range phone that difference is very visible.
What to do: list what is actually installed and ask of each whether anyone still looks at it. Pixels from finished campaigns, replaced analytics tools and trialled chat widgets are frequently still running.
4. Content that waits for software to finish
If your site assembles pages on each request — WordPress and similar — the visitor waits while the server queries a database, builds the page and sends it, before rendering even begins. The phone is blank throughout.
That delay exists on your computer too. You do not notice it, because your connection is fast and you are probably testing near the server.
What to do: add caching so repeat visits skip the work, or go further and generate the pages in advance as files. After moving to the latter, our pages arrive in 40 to 60 milliseconds consistently, against 200 as a baseline and occasionally over 500 before.
Simulating your customers on your own machine
No need to buy an old phone. Two switches in developer tools get close:
Network throttling. The network panel offers presets such as slow 4G, which simulate realistic bandwidth and latency.
Disable cache. Same panel. Every refresh then behaves as a first visit, which matters more than it sounds — without it you are permanently measuring the best case.
Add one more: test in a private window, so extensions and logged-in state do not interfere.
With all three on, what you see approximates what a customer sees opening your link for the first time. Most people are startled the first time they try it.
A more important judgement
Having done the above, ask one further question: is more optimisation worth it?
Five seconds to two is enormous. One and a half seconds to one point two is imperceptible, and often more work than the first improvement was.
Performance work has diminishing returns. Clear the obvious problems in the four areas above — fonts and images usually account for most of it — and judge the rest on merit. Time spent on content and conversion frequently returns more.
We run these four as a baseline check on every project rather than as an upgrade. The method is written out above; you can work through it yourself.