Site speed and Core Web Vitals, explained for a manager

An SEO report lands with three red bars and three acronyms: LCP, INP, CLS. Your developer replies that the site scores 98 out of 100 with Google. Both statements can be true at the same time, and that's exactly where the conversation goes off the rails. Speed is one of the first things we measure when we take over an existing site on subscription.

Core Web Vitals aren't a technical exam. They're three moments lived by a person opening your page: does something appear, does it react when I touch it, does it stop moving under my thumb. Translated that way, the three metrics become business decisions you can arbitrate without writing a line of code.

This article does four things: translate the three metrics with their current thresholds, explain where the "98 out of 100" misunderstanding comes from, give you a five-minute self-test, and answer the question that actually matters, which is what speed pays.

The short answer, for the busy

Core Web Vitals is the name Google gives to three measurements of what your real visitors experience. LCP (Largest Contentful Paint) marks the moment the main content of the page finishes rendering: the target is 2.5 seconds or less. INP (Interaction to Next Paint) measures the delay between a click and the page's visible response: the target is 200 milliseconds or less. CLS (Cumulative Layout Shift) measures unexpected layout movement during loading: the target is 0.1 or less. A page passes the assessment when all three targets are met at the 75th percentile of real visits, aggregated over 28 days. That field data is what counts, not the lab score the tools display alongside it. In July 2026, 55.7% of the sites Google measures passed all three, and the one that fails most often is LCP.

Three metrics, three moments of the same visit

LCP answers "is anything happening?" It marks the instant the largest visible element on the page, usually the hero image or the main headline, finishes rendering. Google considers 2.5 seconds or less good, and more than 4 seconds poor. This is the blank-screen metric, the one a visitor feels before reading a single word.

INP answers "does it react?" It measures the time between someone touching an element (a button, a menu, a form field) and the screen visibly changing in response. Good at 200 milliseconds or less, poor beyond 500. This is the "I clicked twice because nothing happened" metric, and the one that punishes script-heavy sites hardest.

CLS answers "does it stop moving?" An ad slotting in, a font loading late, a cookie banner pushing the text down at the exact moment your thumb comes down: every jump counts. Good at 0.1 or less. It's the most irritating one for visitors and often the cheapest to fix.

A page only passes if all three are good. And if you're wondering which one will hurt you most, Google's own data answers: across roughly 18 million origins measured in July 2026, 85.7% had good INP and 81.6% had good CLS, but only 68.3% had good LCP. Initial rendering is still the web's weak link, and it's almost always where to start.

Where the "98 out of 100" misunderstanding comes from

There are two ways to measure a site's speed, and they don't answer the same question.

Lab measurement loads the page once, in a simulated environment, on an emulated mobile device over a deliberately throttled network. That's what Lighthouse does, the tool behind the famous score out of 100. It's repeatable, useful for diagnosis, and it runs in thirty seconds. Two limits, though. First, the score fluctuates between runs for reasons that have nothing to do with your site. Second, and nobody mentions this in meetings: the Lighthouse performance score contains no INP at all. Its weighting is split between first paint, speed index, LCP, total blocking time and CLS. A site can post a 98 and still make your visitors wait half a second on every tap.

Field measurement is the other half of the story. Chrome anonymously collects the timings real users experience and aggregates them into the Chrome User Experience Report (CrUX), a rolling average over the last 28 days. That's the data Google feeds into its page experience signal. And it doesn't take the average: it takes the 75th percentile, chosen explicitly, Google says, to represent the most frustrating user experiences. You aren't graded on your median visitor with fibre at the office, but on the unluckiest quarter, the one on the subway with a four-year-old phone.

There's a practical consequence many SMBs find surprising: if your site gets little traffic, there is no field data at all. A page has to be publicly indexable and receive a minimum number of visitors to enter the dataset. Failing that, the tool falls back to whole-domain data, and if the domain isn't busy enough either, it shows nothing. In that case the lab becomes your only compass. It's imperfect, but it beats intuition.

The five-minute self-test

You need no paid tool and no technical skill to run this diagnosis yourself.

Open PageSpeed Insights (pagespeed.web.dev), paste the address of your most important page, the one that gets the most visits or generates your enquiries, and run it. Stay on the mobile tab: it's the demanding one, and it's where your visitors judge you.

The first section is the real-user one. If it appears, read the three numbers, not the colours: an LCP of 3.8 seconds tells you something "amber" does not. Note whether the page passes or fails, and which of the three makes it fail. If that section is missing, you now know why, and you can move straight on.

The second section is the lab: the score out of 100 and, further down, a list of diagnostics with estimated savings in seconds. The value is in that list. The score is mostly there to be screenshotted and emailed around. Run the same test on a competitor who worries you, then bring both reports to your developer with a single question: which two or three items on this list would actually improve this page's LCP, and how long would that take? The rest can wait.

What to fix, in order

Three levers explain the vast majority of slow sites we take over, and they always come in the same order.

Images. The largest element on your page is almost always a photo, so LCP is almost always an image story. A 4 MB hero photo served at full resolution to a phone is the classic. Modern formats, dimensions matched to actual display size, and above all: never lazy-load the hero image. The loading="lazy" sprinkled reflexively across every image on the site delays precisely the one that defines your LCP.

Third-party scripts. This is the least understood lever, because each piece looks harmless on its own. According to HTTP Archive's 2025 Web Almanac, 90% to 92% of web pages load at least one third party, and the median inclusion chain runs 3 deep: most third-party scripts bring along others you never chose (the deepest chain observed in the study was 2,285 levels). Tag managers load other scripts by design, chat widgets are among the heaviest, and consent banners sit on the critical path. Inventory everything added to the site over the last five years and remove what nobody reads any more. It's free, and it's usually the cleanest win on INP.

Hosting. Server response time, the first byte, sets the floor for everything else: Google's documentation is blunt that a high response time makes a 2.5-second target hard, or even impossible, to hit. No amount of image optimization rescues an overloaded shared server or a site served from a different continent than your customers. We covered what you're really paying for in web hosting.

CLS, for its part, is fixed mostly by reserving space in advance (declared dimensions on images, room set aside for the banner) rather than by buying power. And because slowness creeps back with every plugin added, this is a maintenance line item, not a one-off project.

What speed pays, honestly

On rankings, Google is more measured than the SEO industry. Core Web Vitals are used by its ranking systems, that's stated plainly in its documentation. But the same page adds that good results in these reports don't guarantee top rankings, and that "trying to get a perfect score just for SEO reasons may not be the best use of your time." Google also notes that Search shows the most relevant content even when page experience is sub-par, but that for the many queries where plenty of helpful content exists, a great page experience can contribute to success. That's the definition of a tie-breaker: speed won't lift you past a clearly better competitor, it separates you from the one who looks just like you.

On conversion the effect is more direct and better documented. The "Milliseconds Make Millions" study, commissioned by Google and run by 55 and Deloitte across 37 brands and more than 30 million sessions, measured that a 0.1-second improvement in mobile speed lifted retail conversions by 8.4% and average order value by 9.2%. The figure that matters more to a services SMB sits elsewhere in the same study: on lead generation sites, progression to the form submission page rose 21.6%. Two honest caveats, because these percentages get copied without them: the study ran in 2019-2020, and it moved four speed indicators at once, none of them today's Core Web Vitals. It establishes a direction and an order of magnitude, not a promise that transfers to your thirty-visitors-a-day site.

Which leads to this article's most useful position: once you're under 2.5 seconds, under 200 milliseconds and under 0.1, stop. The marginal return on the next tenths is small, and the money is better spent on content and page clarity. Speed is a floor you shouldn't break through. Nobody ever picked a supplier because the site loaded in 1.9 seconds. And if your site fails all three metrics and it's eight years old, you don't have an optimization problem, you have a redesign problem.

Run the five-minute test this week. If the result worries you and you'd rather know what fixing it costs than decode a diagnostics list alone, that's exactly what we hand over in an audit.

→ Request an audit of your site