1. What happens after a click
When someone taps a link to your site, four things happen in sequence. The browser asks a server for the page. The server answers with an HTML document. The browser reads that document and discovers everything else it needs — images, fonts, stylesheets, scripts — and asks for those too. Only then can it draw something a human can read.
Every delay you have ever experienced sits in one of those four steps. That is genuinely all there is to it. “The site is slow” always resolves into: the server took too long to answer, the answer was too large, or the browser was made to wait for something before it was allowed to paint.
Hold on to that sentence. It is the whole diagnostic framework, and it lets you follow any technical conversation about performance.
2. The four real causes
Images that were never prepared
This is the most common cause by a wide margin. A photograph straight off a camera or a designer’s export can be four megabytes. Displayed in a 600-pixel-wide slot, it should be perhaps sixty kilobytes — roughly one-sixtieth of the data. Multiply by twelve images on a homepage and you have a site that is unusable on a train.
JavaScript sent for pages that do not need it
Images are heavy but passive; JavaScript is heavy and demanding. The browser has to download it, read it, and run it — on the visitor’s phone, not your laptop. A themed site frequently ships the code for a slider, a chat widget, three analytics tools and an animation library to a page that displays a paragraph of text.
Fonts that hold the text hostage
A custom font is a file, and browsers will often wait for it before showing any words at all. Loaded from someone else’s server, in four weights nobody uses, it produces that familiar second of blank white page — content that had already arrived, waiting on decoration.
Third-party scripts, and where the page is built
Every embedded chat box, tag manager, heatmap and review widget is code you do not control, loaded from a server you do not own. Any one of them can stall your page. Underneath all of it sits the question of where the page is assembled: pre-built and served as a finished file, or constructed from scratch on every single visit. Choosing the second when the first would do is a decision that quietly costs you a second on every page view.
Four causes. Images, scripts, fonts, and where the page is built. Nearly every slow site is one or more of these — not a mystery, and not an argument for a rebuild until you have checked.
3. How to measure it honestly
“It feels fine on my machine” is not measurement. Your machine is on office broadband, has the site cached, and is not a three-year-old phone on patchy mobile data — which describes most of your visitors. Test on a throttled mobile connection, or the numbers mean nothing.
Google publishes three thresholds, and they are the only scoreboard worth arguing about because they are what search ranking and real users both respond to:
- LCP ≤ 2.5sThe largest thing on screen — usually your hero image or headline — should be visible within two and a half seconds.
- INP ≤ 200msWhen someone taps, something visible should happen within a fifth of a second.
- CLS ≤ 0.10Content must not jump around as the page loads. The cause is almost always an image or advert without reserved space.
One more distinction worth knowing: lab data is a test run in ideal conditions, field data is what real visitors experienced. Field data wins every argument. If a report shows a green lab score and unhappy customers, believe the customers.
4. Fixes that work
In rough order of return on effort, and none of these require a rebuild:
- Resize and convert every image to a modern format, and serve a smaller version to phones. Usually the single largest win available.
- Set explicit width and height on images so the browser reserves the space and nothing shifts.
- Audit third-party scripts. Remove what nobody reads; delay the rest until after the page is usable.
- Self-host fonts, in the two weights you actually use, and tell the browser to show text immediately.
- Load only the JavaScript a page needs, rather than one bundle for the whole site.
- Pre-build pages that do not change on every visit, and refresh them on a schedule instead of on demand.
- Serve from a network with a copy near your visitors — a site for Indian customers should not be answered from Virginia.
5. Fixes that only look like fixes
A caching plugin on a site that ships six megabytes of images makes the second visit faster and the first visit — the one that decides whether you get the enquiry — exactly as slow. A bigger hosting plan buys a faster answer to the first request, which was rarely the bottleneck. A loading animation makes the wait more pleasant without shortening it by a millisecond.
None of these are scams. They are simply treatments applied without a diagnosis. Insist on the measurement first, then the fix, then the measurement again.
6. Questions to ask your developer
You do not need to audit code. You need four answers, and the quality of the answers tells you everything:
- What are our LCP, INP and CLS numbers on mobile, from real visitors?
- How large is the heaviest page, in megabytes, and what is the biggest single file on it?
- Which third-party scripts are loading, and who asked for each one?
- Which pages are pre-built, and which are constructed on every visit?
If those four answers come back quickly and specifically, your site is being engineered. If they come back as reassurance, that is your finding.
Speed is not a feature you buy at the end of a project. It is the result of a few decisions made early, honestly measured, and defended every time someone wants to add one more widget.