Almost every "our site is slow" conversation ends in one of five places. None of them require rebuilding the site, and most can be measured in an afternoon. What follows is the order I check them in, and why that order saves money.

Before any of it: measure on a mid-range phone over mobile data, not on your laptop over office wifi. A desktop score is close to meaningless, because that is not how most of your visitors arrive.

1. Images that were never resized

This is the single most common cause, and the least interesting. A photograph goes straight from a camera or a stock library into a page, at four thousand pixels wide and three megabytes, to be displayed in a box six hundred pixels across. The browser downloads the whole thing before it can show anything.

The fix is unglamorous: resize to the dimensions actually used, serve modern formats, and let the browser pick a size appropriate to the screen. On a content-heavy page this alone can halve the time to first meaningful paint. If your site is on a framework with a built-in image component, most of this is a configuration change rather than a project.

2. Third-party scripts nobody audits

Chat widgets, analytics, heatmaps, A/B testing, consent banners, embedded video, social feeds, a tag manager that loads four more things. Each was added for a reason, each was added by a different person, and nobody has ever removed one.

These are worse than they look, because a third-party script is code you do not control, executing on your main thread, from a server whose response time is not your responsibility. A slow tag server makes your site slow, and there is nothing in your codebase to fix.

  • List every external script currently loading on the homepage.
  • For each one, find the person who wanted it and ask whether it is still being used.
  • Remove anything nobody can justify — this is usually a third of the list.
  • Load what remains after the page is interactive, not before.

3. Fonts loading the slow way

Custom fonts are usually fetched from a third-party host after the browser has parsed the CSS that mentions them — two network round trips before a single word can be drawn. Meanwhile the text is either invisible or renders in a fallback and then jumps when the real font arrives.

Self-host the font files, subset them to the characters you actually use, preload the one or two weights that appear above the fold, and set a fallback that is metrically close so the swap does not move the layout. Modern frameworks do most of this automatically if you use their font tooling instead of a stylesheet link.

4. Hosting and how the page is generated

If every visit makes your server assemble the page from a database, you are paying that cost on every request, and the visitor waits through all of it before the first byte arrives. For a marketing site whose content changes weekly, that work is being repeated thousands of times for no benefit.

Pages that do not change per visitor should be generated once and served from a cache close to the visitor. This is the difference between a first byte in fifty milliseconds and one in eight hundred, and it usually costs less to run rather than more.

5. Content that moves while it loads

Layout shift is not slowness exactly — it is the experience of slowness. The page appears, you go to tap a link, and an image finishes loading above it and pushes everything down. Google measures this, visitors resent it, and it is entirely preventable.

The cause is almost always an element whose size the browser cannot know in advance: an image without width and height, an ad slot, a banner injected by script, or a font swap. Reserve the space before the content arrives and the problem disappears.

What to do with this

Measure first, on a real phone. Then work down the list in order, because it is roughly ordered by effort-to-benefit. In most cases the first two items account for the majority of the problem, and neither requires touching how the site is built.

If you have been quoted for a rebuild on performance grounds, this list is a reasonable second opinion. A rebuild is sometimes right — but "the site is slow" on its own is not the evidence for it.