Website Speed and Core Web Vitals

The three metrics and the thresholds Google documents

As of August 2026 there are three Core Web Vitals. Each measures a different kind of user frustration, and each has a published "good" threshold in Google's own documentation.

• Largest Contentful Paint (LCP) measures loading — how long until the largest thing on screen has rendered. Google's guidance is that LCP should occur within 2.5 seconds of when the page first starts loading. Good is 2.5 seconds or less; poor is greater than 4.0 seconds.
• Interaction to Next Paint (INP) measures responsiveness — how long after a tap before the page visibly reacts. Google documents good as at or below 200 milliseconds, needs improvement as above 200 and at or below 500, and poor as above 500 milliseconds.
• Cumulative Layout Shift (CLS) measures visual stability — how much content jumps around while it loads. Good is 0.1 or less; poor is greater than 0.25.

One qualification if you are checking somebody's numbers: the middle "needs improvement" bands for LCP and CLS appear in Google's documentation as threshold charts rather than sentences. The values follow from the good and poor boundaries, but those two boundaries are the ones written out in prose.

The thing everyone gets wrong: all three are assessed at the 75th percentile of page loads, segmented across mobile and desktop. Not the average, and not your own phone on office wifi. Three quarters of real visits have to be that fast. Your experience on a laptop connected to fiber is one sample near the good end of the distribution, and it is not the sample being measured.

INP replaced FID on 12 March 2024

The third Core Web Vital used to be First Input Delay. It is not any more. INP officially became a Core Web Vital and replaced FID on 12 March 2024, in Google's own wording, and FID was removed from Search Console the same day. INP had been promoted to a pending metric in 2023 with the stated intent of retiring FID, and became a stable Core Web Vital in 2024. PageSpeed Insights and the Chrome User Experience Report were given a deprecation window of several months before FID disappeared from them too.

It also gives an owner a free and completely reliable test to run on any proposal or audit they have been handed. Search the document for "First Input Delay". If it is there, that document was written before March 2024 or copied from something that was. It does not prove the sender is incompetent; it proves the specific piece of work is out of date. Run the same check on any audit template, checklist or dashboard somebody bills you for monthly.

What Google has actually said about ranking

This is where the industry substitutes folklore for reading, so here is the documentation, close to verbatim, from Google's page experience guidance:

There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.

Core Web Vitals are used by our ranking systems.

Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available.

Keep in mind that getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone.

Read together, those four statements say something specific. Speed is a tiebreaker among comparable results. It is not a lever that beats relevance, and there is no discrete "page experience ranking factor" available for purchase, because Google says explicitly that there is no single signal. So when somebody sells a Core Web Vitals project as a fix for rankings, they are selling something Google's own documentation contradicts, and you can open that page in front of them.

What speed genuinely does is stop you losing visitors you already have. Somebody who taps a search result on a phone at the lake, waits, and taps back is a customer you paid to reach and then lost at the door.

Lab data, field data, and why two reports disagree

Lab data is a synthetic test. Lighthouse, and the performance score at the top of PageSpeed Insights, simulate one device on one throttled connection loading the page once. Lab data is repeatable and excellent for diagnosis — it tells you which image is the problem. It is not what Google uses to assess Core Web Vitals.

Field data is measurement of real visits. The Chrome User Experience Report collects it from actual Chrome users on actual devices and connections, as a rolling distribution over the previous 28 days. That is what the assessment uses and what Search Console shows you.

Three consequences follow, and each saves money. The 0 to 100 performance score is not a Core Web Vital and is not a ranking factor; a site can score in the sixties in the lab and pass all three in the field, and the reverse happens too. A single test run is not a measurement — lab runs vary between executions on the same page, while field data is a 28-day distribution. And mobile and desktop are assessed separately, so a report that does not say which one it is showing is not a report.

The right sequence is field data first, to find out whether there is a real problem, then lab tools to find the cause. Doing it the other way produces a long list of technically true recommendations that fix nothing anyone experienced. Google's Web Vitals documentation covers the definitions and the percentile rules directly.

What actually makes a small local site slow

In descending order of how often it is the real cause on a real small-business site:

1. Unresized photographs. A photo straight from a modern phone is several thousand pixels wide and several megabytes. Displayed in a spot eight hundred pixels wide, it still downloads at full size. This is the most common LCP cause by a wide margin and it is free to fix — and LCP is the metric the largest share of sites fail on mobile, according to HTTP Archive's July 2025 data.
2. A slider or hero video at the top of the page. Usually both the largest element on screen and the heaviest object on the page.
3. Third-party script sprawl. Chat widget plus popup plus analytics plus heatmap plus review carousel plus tracking pixels, on every page. This is the usual cause of poor INP: the main thread is busy running somebody else's code, so the tap does not paint.
4. Images without width and height set, so the page reflows as each one arrives — a direct CLS cause, as is a cookie banner injected above content that has already rendered.
5. Server response time. The floor under LCP. Google treats good as at or below 0.8 seconds and poor as above 1.8 seconds, and states explicitly that it is not itself a Core Web Vital.

Note the ordering. The host is number six. Most "we need faster hosting" conversations are about numbers one to three, and moving a five-megabyte hero image to a faster server produces a five-megabyte hero image on a faster server. HTTP Archive also found fewer than half of sites passing all three Core Web Vitals on mobile, so failing is the normal condition of the web rather than an emergency.

When speed work is a waste of money

This is the section that costs us projects, and it is the most important one on the page.

When the site has no field data at all. Google documents two requirements for inclusion in the Chrome User Experience Report: the page must be publicly discoverable, and it must be sufficiently popular, meaning it has a minimum number of visitors. Google deliberately does not publish that number, stating only that it was chosen to ensure enough samples for confidence, and that pages and origins that do not meet the popularity threshold are not included in the dataset. So run your address through PageSpeed Insights. If it reports no real-user data for the page or the origin, then there is no Core Web Vitals assessment happening for your site at all. There is no ranking effect to recover and no number anybody will watch change. Fix the oversized images anyway, because it takes an hour and the site is nicer for the humans who do visit. Do not buy a project.

When the site already passes all three. Going from 1.8 seconds to 1.2 seconds crosses no threshold. There is no bonus tier above good. That money buys more in content or reviews.

When the real problem is that nobody visits. Speed work has a hard ceiling: it can only preserve traffic you already have. It cannot create demand. A site with forty sessions a month does not have a speed problem, it has an audience problem.

When the fix means rebuilding a working site. Sometimes the honest answer is that the theme is heavy and replacing it costs more than the speed is worth to this business.

What we actually do, and in what order

The sequence is designed to answer the expensive question first. We check for field data before anything else, because if the site has too little traffic to be measured we would rather say so than sell a project. If it does have data, we read it properly: which metric is failing, on mobile or desktop, at the 75th percentile, across which pages. Not the homepage alone — visitors from search land on interior pages, and optimizing only the homepage is the classic wasted engagement.

Then lab tools for diagnosis, to find the specific element causing the specific failure. Then fixes in order of effect: resize and compress the images, remove scripts nobody uses, set dimensions on images, and load the largest element eagerly rather than lazily, since lazy-loading the biggest image on the screen is common and measurably makes LCP worse. Then re-measure after the field data has had time to move, which takes weeks.

We have been working in search since 1996 and running this business from Kaufman since 2003. For a small brochure site, most of the useful work here is an afternoon rather than a retainer, and we will tell you when that is the case.