What to Fix First on a Slow Site

The score is not the problem, and it is not the target

The usual sequence is that someone runs a page through a testing tool, gets a two-digit score in a colored circle, and forwards it to a developer with a subject line about fixing the site. Weeks of work follow. The score improves. Nothing else does.

The reason is that the score came from a lab test — one simulated load, on one machine, on one connection, of one URL — and the thing that actually matters is what real visitors experienced across your real traffic mix of devices, networks and locations. Those two numbers routinely disagree, and when they disagree, the field data is the one describing your business.

So triage runs in a fixed order. Find out whether real users are experiencing a problem. Find out which of the three metrics is failing. Find out which template that failure lives on, and how much traffic and revenue sits behind that template. Fix that, alone. Then wait long enough for the field data to speak before deciding whether it worked.

Step one: get the field numbers, at the 75th percentile, split by device

Core Web Vitals are assessed at the 75th percentile of page loads, segmented by mobile and desktop. Both halves of that sentence change what you should do.

The 75th percentile means you are not optimizing for the average visit. You are optimizing so that three-quarters of visits are good, which puts the work squarely in the slower quarter of your audience — older phones, worse networks, the third-party script that only fires for some visitors. An average masks exactly the visits the metric is built to catch.

The device split matters because mobile and desktop are assessed separately, and a site can pass comfortably on desktop while failing on mobile, which is usually where the traffic is. Read them as two separate reports about two separate populations, and do not let a passing desktop number reassure anyone.

Field data has one property that trips teams up: it accumulates. It describes a period of real visits, so it lags your deploys and it moves gradually rather than the instant a fix ships. That is a reason to be patient, not a reason to switch back to the lab number because it responds faster.

Step two: which of the three is failing decides everything after

There are three metrics and they measure entirely different failures. The fixes do not overlap, so identifying the failing one is the whole of the prioritization.

• Largest Contentful Paint — good is 2.5 seconds or under. This is a loading problem: the main content took too long to appear.
• Interaction to Next Paint — good is 200 milliseconds or under, and above 500 milliseconds is poor. This is a responsiveness problem: the page did not react to what someone did.
• Cumulative Layout Shift — good is 0.1 or under, and above 0.25 is poor. This is a stability problem: things moved while someone was reading or reaching for them.

One note on vocabulary, because it appears in old documentation and old audits: First Input Delay is not current. Interaction to Next Paint became a stable Core Web Vital in 2024, replacing it. Any report still discussing FID as the responsiveness metric was written against a superseded standard, and its recommendations should be treated accordingly.

If two metrics fail at once, start with the one on the template carrying the most revenue rather than the one with the worst number. The point of triage is commercial ordering, not tidiness.

Step three: fix templates, not pages

Almost nobody has a slow page. They have a slow template, rendered across thousands of URLs, and the tool happened to test one of them.

So before any work starts, group the failing URLs by template — product pages, category listings, articles, the homepage — and put traffic and revenue against each group. The output is a short list in commercial order: this template is failing this metric and carries this share of organic revenue. That list is what a developer can act on, and it is what stops an afternoon being spent on a page type that receives forty visits a month.

The corollary is that a fix ships once and lands everywhere, which is why speed work has better economics than most technical SEO. It is also why a single bad decision — a heavy third-party tag, an unoptimized hero image in a shared component — costs you across the whole site rather than on one page.

Loading: what usually costs the seconds

When LCP is the failing metric, the question is what the largest visible element is on that template and what stands between the request and its appearance. In my experience the recurring causes are dull and repeatable: an oversized hero image served at desktop dimensions to phones, a headline blocked by a web font that loads late, a server that takes too long to respond before anything can begin, and render-blocking resources sequenced ahead of the content people came for.

Server response time and caching are worth attention beyond the metric itself. Google's crawl guidance states the connection directly: if Google can load and render your pages faster, it might be able to read more content from your site. The same guidance recommends supporting 304 Not Modified so a cached version can be reused, and enabling HTTP caching. Those changes serve visitors and crawling simultaneously, which makes them easy to justify to a development team that has heard enough about SEO for one quarter.

Two cautions. First, third-party scripts are usually the largest single lever and the hardest politically, because each one belongs to someone who will defend it; get the list of what is loading and what each tag is for before proposing removals. Second, a faster site is a better site, but do not sell page speed internally as a ranking strategy. It is a user experience and crawling argument. Overstating it is how the whole program loses credibility when rankings do not move.

Responsiveness: what INP actually counts

Interaction to Next Paint surprises people because it counts less than they think and measures more than they think.

It counts exactly three interaction types: clicking with a mouse, tapping a touchscreen, and pressing a key, physical or onscreen. Scrolling, hovering and zooming are excluded. So a page that feels janky while scrolling can post a perfectly good INP, and the complaint in your inbox and the number in your report are describing different things.

What it measures is the full round trip: the time from the start of the interaction to the moment the next frame is fully presented. That is input delay plus event handler processing plus rendering — not just the moment before your code runs. A handler that finishes quickly but forces an expensive re-render still produces a bad score, which is why a fast handler is not a defense on its own.

For most pages the worst interaction is what gets reported. Pages with many interactions get an outlier allowance of one discarded interaction per fifty. Practically, this means a single slow control — a filter, an accordion, an add-to-cart button that revalidates the whole page — can define the metric for a template where everything else is fine. Find that one control before optimizing anything general.

Stability: bursts, not sums

Cumulative Layout Shift is widely misunderstood as a running total of every movement on the page. It is not. Shifts are grouped into a burst when the gap between individual shifts is under one second, with a maximum window duration of five seconds, and CLS is the largest such burst rather than the sum of everything that moved.

That definition tells you where to look. One bad moment — an ad slot that resolves without reserved space, a cookie banner injected above the content, an image without dimensions, a font swap that reflows a heading — dominates the score. Scattered small shifts spread across a long session matter far less than a single cluster at the moment the page settles.

The fixes are mostly about reserving space in advance rather than making anything faster: explicit dimensions on images and embeds, reserved containers for anything injected asynchronously, and overlays that composite rather than push content down. CLS is usually the cheapest of the three to fix and the most visibly annoying to leave broken, which makes it a good first win when you need internal support for the rest of the work.

Verifying, and knowing when to stop

Verification has two stages, and confusing them is the last common mistake in this sequence.

The lab check happens immediately after the fix ships and answers one question: did the change do what was intended on this template. It is a build test, not a result.

The field check answers whether real visitors experienced the improvement, and it cannot happen immediately, because the data is accumulated from real visits over time. Ship, wait, and re-read the field numbers at the 75th percentile on the same device split you started from. Compare against the baseline you recorded before the work, on the same segmentation. If you did not record one, you have already lost the argument you are about to have.

Know when to stop. Once a template sits inside the good thresholds at the 75th percentile on both device classes, further optimization has real engineering cost and diminishing returns. Move to the next template on the commercial list. And keep one thing in proportion: a fast site removes an obstacle, it does not create demand or relevance. If pages are not indexed, or not relevant to what people search, the fastest site in the category will still not be found. Speed is table stakes, not a strategy.

Frequently Asked Questions

Published 2026-08-11