Why your website is slow, and what actually fixes it

Almost every slow website is slow for one of four reasons: it sends too many bytes, it sends them from too far away, it blocks the browser from drawing anything while it waits, or the server thinks for too long before replying. Everything below is a variation on one of those.

The useful part is knowing which one you have, because the fixes are unrelated and doing the wrong one costs a week for nothing.

First, stop trusting the score

PageSpeed Insights gives you two different things and people read the wrong one. The big coloured number is a lab score: one simulated load, on a throttled connection, on a machine in a data centre. It is a diagnostic. It is not what Google uses.

What Google uses is field data, collected from real Chrome users on your site over a rolling 28 days, assessed at the 75th percentile. That means three quarters of real visits must hit the threshold. It is entirely normal to score 62 in the lab and pass every field metric, and equally normal to score 95 and fail one.

If you have Search Console, the Core Web Vitals report there is the same data grouped by page type, and it is the number worth acting on. Google's Web Vitals documentation (opens in a new tab) is the primary reference for the thresholds above.

Optimising the lab score is optimising the rehearsal. Field data is the performance, and the audience is on a three-year-old Android phone on mobile data.

Cause 1: images, and it is nearly always images

On a typical business site, images are more than half the page weight and the biggest single cause of a slow Largest Contentful Paint. The specific fault is usually not the format but the dimensions: a 4000-pixel-wide photograph from a phone camera, displayed in a 600-pixel-wide column, downloaded in full by every visitor.

1. 1Resize to the largest size the image is ever displayed at, then stop. A hero image needs about 1600px wide, not 4000.
2. 2Convert to WebP or AVIF. Expect roughly a quarter to a third off JPEG at the same visual quality.
3. 3Set width and height attributes on every image tag. This costs nothing and removes the layout shift when the image arrives.
4. 4Add loading=lazy to images below the fold, and leave it off the one at the top. Lazy-loading your hero image delays the exact thing LCP is measuring.

Cause 2: too much third-party JavaScript

Analytics, a chat widget, a heatmap recorder, two pixels, a cookie banner and a font loader. Each was added for a defensible reason and none of them were removed. Together they are frequently larger than the site itself, and they run on the main thread, which is what Interaction to Next Paint measures.

Open the Network tab, sort by size, and look at what is not yours. Then ask, for each one, whether anybody has looked at its output in the last three months. On most sites at least one can go entirely, and the rest can be deferred so they load after the page is usable rather than before.

Chat widgets deserve a specific mention. A widget that loads its full bundle on every page for a button almost nobody clicks is pure cost. Loading it only when somebody clicks the button is a small piece of work with a large payoff.

Cause 3: the server takes too long to reply

Time to First Byte is how long the browser waits before receiving anything at all. Under 200ms is comfortable. Over 600ms and nothing you do in the browser will rescue the page, because the whole load starts late.

• Cheap shared hosting is the most common cause, and the one nobody wants to hear. If TTFB is 900ms on an empty page, the host is the problem.
• Database queries on every request, uncached. A WordPress site with 30 plugins is running a lot of queries to produce a page that has not changed in a month.
• No page caching. Serving a cached HTML file instead of rebuilding it per request is usually the single largest improvement available.
• The server is far from the visitor. A site hosted in Virginia serving customers in India is paying for the distance on every request.

A CDN addresses the last one and helps with the third. It does not fix slow application code, which is worth knowing before buying one as a solution.

Cause 4: render-blocking resources

The browser cannot draw the page until it has processed the CSS and any synchronous scripts in the head. Every blocking file inserts its full round trip between the visitor and seeing anything.

Web fonts are a common and avoidable version of this. A font loaded without font-display: swap leaves the text invisible until the file arrives. Setting swap shows the fallback immediately, which looks slightly worse for a moment and is much better than blank.

Cause 5: the layout moves while it loads

Not slowness exactly, but it is measured alongside it and it is the fault visitors find most annoying, because it makes them tap the wrong thing. Cumulative Layout Shift has three usual sources: images without dimensions, ads or embeds injected into the flow, and web fonts that reflow the text when they swap in.

All three have the same fix: reserve the space before the content arrives. Set the dimensions, give the ad slot a fixed box, and match the fallback font's metrics to the real one.

The order to work in

The last row is there deliberately. Critical CSS extraction is the sort of task that feels like real optimisation work and usually returns less than resizing four photographs.

What does speed actually do for rankings?

Less than the industry implies. Page experience is a real signal and a weak one; it separates results that are otherwise close. A slow page with the best answer still beats a fast page with a worse one.

The business case is stronger than the ranking case. People leave slow pages, and they leave commercial pages fastest. That is the reason to fix it. If you want the longer version, we have a piece on what Core Web Vitals actually change.

Questions people actually ask

My score is 100 on desktop and 45 on mobile. Which is real?

Mobile, for almost every site, because that is where most visits come from and the test assumes a mid-range phone on a slow connection. Desktop scores are flattering and largely decorative.

Will a caching plugin fix this?

It will fix server response time, which is one of the four causes. It will not shrink your images or remove a tracking script. Plugins that promise all of it at once tend to break layouts by minifying and combining files that did not want to be combined.

How fast is fast enough?

Pass the three field thresholds at the 75th percentile and stop. Chasing a perfect lab score past that point is effort spent on a number that nobody outside the industry ever sees.

Everything is slow and I do not know where to start.

Measure TTFB first with any free tool. Over 600ms means start at the server. Under 200ms means the problem is in the browser, and it is probably images. That one number splits the work in half before you have changed anything.

If the site is slow because of how it was built rather than how it is configured, no amount of tuning will settle it. That is a rebuild question rather than a performance question, and the redesign article covers how to tell which one you have.