Site Speed and Core Web Vitals: Why a Slow Site Loses You Customers

In short: Core Web Vitals are the three metrics Google uses to measure page experience: LCP for loading (2.5 seconds or less), INP for responsiveness (200 milliseconds or less) and CLS for visual stability (0.1 or less). For a page to count as "good", it has to hit these thresholds for 75% of real visits, measured separately on mobile and desktop. Speed alone will not lift you to the top of the results, but a slow page loses the visitor before they ever see your content.

Most questions we get about site speed fall into a handful of topics. We have built this article as direct answers to those questions rather than as an essay. We explain the technical terms without going deeper than necessary — the aim is for you to understand the subject well enough to manage it and to ask your team or agency the right questions.

What exactly do Core Web Vitals measure?

Not how fast your server is, but how the page feels to a user. That distinction matters: a server can be very fast while the page still delivers a poor experience. There are three metrics, and their thresholds are defined the same way on web.dev's Core Web Vitals page and in the Search Console documentation:

The assessment is not based on the average but on the 75th percentile: if at least 75% of your visits fall within the "good" threshold, that metric passes. In other words, it is not the experience on the fastest device that counts — the visitor with a slow phone and a weak connection is included too.

What is LCP, and how many seconds should it be?

LCP is the time until the largest piece of content on the page — usually a hero image or main heading — appears on screen. In practice it answers the question "when did the visitor see something meaningful?" The target is 2.5 seconds or less.

Google's LCP optimization guide splits this time into four parts: the server sending the first byte (TTFB), the delay before the browser starts requesting the image, the time it takes to download the image, and the time to render it on screen. "Speeding things up" without knowing which part is slow usually hits the wrong target.

What is INP? Did it replace FID?

Yes. INP replaced FID and became a stable Core Web Vitals metric in March 2024. The difference: FID measured only the delay on the first interaction, whereas INP looks at the interactions on the page and measures the full time from the click until the response is painted to the screen. The target is 200 milliseconds or less.

A menu that "sticks" when you tap it is a typical INP problem. The cause is usually JavaScript keeping the browser's main thread busy for too long: the page cannot respond to your tap until it finishes whatever else it is doing.

What is CLS, and why is it so irritating?

CLS measures how much content moves while the page loads. You are about to press a button, an image above it loads and pushes everything down, and you click the wrong thing — that is precisely what it measures. The target is 0.1 or less.

The most common cause is that no space has been reserved in advance for images, ad slots and components that load later. Late-loading web fonts that suddenly reflow the text are the second most frequent culprit.

Do these scores really affect my ranking?

They do, but the effect is limited and worth understanding properly. Google's page experience documentation says two things plainly: good Core Web Vitals results do not guarantee top rankings, and Google will show the most relevant content even if its page experience is sub-par. According to the same page, page experience mainly makes a difference when many similarly helpful pages are competing.

The right reading is this: poor content does not rise because it is fast, but between two pieces of content of similar quality, the one with the better experience can move ahead. The real impact starts before ranking anyway: a visitor who leaves before the page loads is lost no matter what position you hold.

How do I measure my score, and why does the testing tool disagree?

This confusion comes up constantly, because there are two different kinds of data:

• Field data — measurements collected from Chrome users who actually visit your site (the Chrome User Experience Report, or CrUX). PageSpeed Insights shows this data for the previous 28-day period. The Core Web Vitals assessment is based on it.
• Lab data — a measurement Lighthouse makes on a single simulated device with fixed network conditions. It is very valuable for finding problems, but it may miss the bottlenecks real users hit; getting different results when you test the same page twice is normal.

An important detail: because there is no user interaction in a lab test, Lighthouse cannot measure INP; it uses Total Blocking Time (TBT) as a proxy instead. So the "performance score" in PageSpeed Insights and whether the page passes Core Web Vitals are not the same thing.

The Core Web Vitals report in Search Console groups URLs that offer a similar experience and labels each group "Good", "Need improvement" or "Poor", separately for mobile and desktop. Low-traffic sites may not have enough field data; in that case the report can stay empty or fall back to data for the whole site (origin level).

That is why an improvement does not show up immediately after a fix. When you start validation for an issue in Search Console, a 28-day monitoring period begins; and because field data is based on a rolling 28-day window, you need to wait a few weeks.

Should my score be 100?

No. Chasing 100 burns hours on micro-optimizations that change nothing for a real user. The meaningful goal is sitting in the "good" band on all three metrics in field data. The difference between a lab score of 92 and 100 is not something your visitor will notice; the difference between 2.4 seconds and 6 seconds absolutely is.

What are the most common causes of slowness, and the concrete fixes?

On the sites we audit, problems cluster under largely the same headings. The fixes line up with Google's CLS, LCP and INP guides:

Common mistakes

• Testing only on desktop. Mobile and desktop are assessed separately; problems usually show up on mobile.
• Treating the lab score as the goal. The Lighthouse score can rise while field data stays flat; decisions should be based on field data.
• Lazy-loading every image. Deferring the image in the first visible part of the screen directly worsens LCP.
• Trying to speed things up with "one more plugin". If a third-party script caused the problem, the fix is usually removing what is there, not adding a new tool.
• Expecting results the day after a fix. Field data moves on a 28-day window.

Can it be fixed after launch?

Some of it, yes — image optimization and clearing out unnecessary scripts can always be done. But how a page is cached, whether it is rendered on the server or in the browser, and in what order content loads are architectural decisions; changing those later comes close to rebuilding. That is why speed is not an item to handle at the end of a project, but a decision to make at the start. We make these decisions from day one in our corporate website and e-commerce projects; for existing sites, we run speed audits as part of our SEO and GEO service.

Related reading: our technical SEO checklist on the issues we found on our own site, our piece on increasing e-commerce conversion rates, which discusses how speed touches sales, and when to redesign your corporate website, where slowness is one of the signals.

If you are curious where your current site is getting stuck, we can measure it and give you a concrete list — noting which metric each fix will affect.