Why your website is slow — and the five fixes that account for most of it

Slow sites nearly always fail for the same five reasons, in roughly the same proportions. You can find yours in about twenty minutes with tools you already have, and most of the gain comes from two fixes rather than fifty.

Speed is not a vanity metric. It changes how many people finish what they started on your site, and search engines use it as a tiebreaker between pages that are otherwise equally relevant. The good news is that the causes are boringly predictable.

Measure before you touch anything

Run your slowest important page — usually a product or landing page, not the homepage — through PageSpeed Insights, and then open your browser's network panel and reload with the cache disabled. You are looking for three numbers.

• Largest Contentful Paint: when the main content appears. Under 2.5 seconds is the target.
• Total page weight: everything downloaded. Over 2MB on a content page means something is wrong.
• Request count: how many separate files load. Over 80 usually means third-party scripts have accumulated without anyone deciding they should.

Write those three numbers down before you change anything. Most speed work fails because nobody measured the starting point, so nobody can tell which change helped.

Fix one: images

Images are the single largest cause of slow pages, and usually the easiest to fix. Three things, in order of impact: serve modern formats, size them correctly, and stop loading the ones nobody has scrolled to yet.

Convert to WebP or AVIF and you typically save 30–50% at identical visual quality. Then check actual dimensions — a 4000px photo displayed in a 600px column is roughly forty times more data than needed, and this is astonishingly common on sites where marketing uploads directly. Finally add loading="lazy" to everything below the fold and explicit width and height attributes to everything, which also removes layout shift.

On a typical business site this one fix alone is worth a second or more.

Fix two: render-blocking assets

Your browser will not paint anything until it has downloaded and parsed every stylesheet and every synchronous script in the head. If that is six CSS files and four scripts, your visitor watches a white screen for all of them.

Move scripts to the end of the body or mark them defer. Combine stylesheets. If you are loading an entire CSS framework to use nine of its classes, that is 200KB of parse time for nothing. Anything that is not needed for the first screen should not block the first screen.

Fix three: fonts

Custom fonts are worth having and routinely implemented in the most expensive way possible. Load only the weights you actually use — most sites request six and use two. Self-host rather than pulling from a third party, which removes a DNS lookup and a connection to somebody else's server.

Add font-display: swap so text renders immediately in a fallback and reflows when the webfont arrives. Invisible text is worse than briefly mismatched text, and it is also worse for your Largest Contentful Paint score.

Fix four: third-party scripts

This is where the surprises live. Analytics, chat widgets, heatmaps, A/B tools, pixels, review embeds and consent managers each seemed small when added. Together they are frequently more than half of total page weight, and they are the part you control least.

Open the network panel, sort by size, and list every domain that is not yours. For each one, ask who looks at the data it produces. In our experience roughly a third of these were installed for a campaign that ended, and nobody removed them. Delete those, load the rest after the page is interactive, and the difference is usually dramatic.

Fix five: hosting and caching

If Time To First Byte is over 600ms, the problem is not your front-end at all — the server is slow to respond and everything else is downstream of that. Cheap shared hosting, an origin server on the wrong continent, or uncached database queries are the usual culprits.

A CDN in front of your site, proper cache headers on static assets, and page caching if you are on WordPress will typically take a second off before you optimise a single image. It is also the cheapest fix on this list.

What to expect

On a typical unoptimised business site, images and third-party scripts account for most of the problem, and both are addressable in a day or two. Sites that stay fast are not the ones that were optimised once; they are the ones where somebody checks the numbers each quarter and removes what crept back in.

If your site is slow and you would rather have someone else find out why, that is a conversation we are happy to have for free.