In short: Core Web Vitals are three metrics that describe what a visitor actually experiences: LCP measures when the main content appears, INP measures how quickly the page responds to an action, and CLS measures whether content jumps under their finger. The good thresholds are up to 2.5 seconds for LCP, up to 200 milliseconds for INP and up to 0.1 for CLS, measured at the 75th percentile of visits. Real user data lives in Search Console and PageSpeed Insights, and on small business sites the fixes almost always start with images, fonts, plugins and hosting.
The thresholds and figures below are as of 16 September 2026, taken from Google’s documentation and web.dev. Thresholds change rarely, but they do change, so check them.
What do LCP, INP and CLS measure?
- LCP (Largest Contentful Paint): when the biggest piece of content in the viewport appears, usually the main image or the headline. It is the moment a visitor decides the page has loaded.
- INP (Interaction to Next Paint): the time between a visitor’s action and a visible response. A tapped button, an opened menu, a filled field.
- CLS (Cumulative Layout Shift): how much elements move while the page finishes loading. This is what makes people tap the wrong button.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | Loading of the main content | up to 2.5 seconds | over 4 seconds |
| INP | Responsiveness to an action | up to 200 milliseconds | over 500 milliseconds |
| CLS | Movement of content | up to 0.1 | over 0.25 |
Two details get missed. The thresholds apply at the 75th percentile of page loads, segmented between mobile and desktop, and between good and poor there is a middle band that Search Console calls “needs improvement”.
There is also a change that still confuses people. On 12 March 2024 INP became a stable Core Web Vital and replaced FID, and Chrome tools stopped committing to FID availability after 9 September 2024. If a report still talks about FID, it is an old report.
Where do you find real data, and where lab data?
The difference between the two explains why the same site scores differently in different places.
- Field data: comes from the Chrome User Experience Report, that is from real Chrome visitors. PageSpeed Insights shows the previous 28 day collection period. CrUX only includes pages that are publicly discoverable and have enough visitors, so a small site may have no field data at all.
- Lab data: Lighthouse loads the page in a controlled environment, on a single device and with fixed network conditions. It is useful for finding the cause, but it does not describe what your visitors experience.
The Core Web Vitals report in Search Console is also built on CrUX. It groups similar URLs and gives a group the status of its worst metric, and groups without enough data are not shown. For an owner that is the practical starting point: you see which groups of pages are weak, rather than one page you happened to test.
ScaleLab tip: Start with Search Console, not with the PageSpeed Insights score. The score is lab based and moves with every run, while the Search Console report shows what real visitors experienced over recent weeks. Fix pages, not numbers.
Does speed affect rankings?
This is where it pays to quote Google rather than the blogs. In its page experience documentation, updated on 10 December 2025, Google writes that its core ranking systems look to reward content that provides a good page experience, and that Core Web Vitals are used by its ranking systems. The same page says there is no single signal, and that good results in the reports do not put your pages at the top of the results.
Google also states that Search always seeks to show the most relevant content, even where the page experience is sub-par. Translated for a business owner: speed does not make up for content that does not answer the question, but between pages of similar quality it is the difference you feel in both rankings and enquiries.
Google offers a simple self-assessment too. Good Core Web Vitals, a secure connection, content that displays well on mobile, no excessive ads over the main content, no intrusive interstitials, and a clear separation between the main content and everything else.
What usually slows down a small business site?
In practice the causes repeat, and they are rarely exotic.
- Images: uploaded at full size straight from a phone or a camera. The LCP guidance recommends serving the right size, using modern formats and compressing, and making sure the LCP element is discoverable in the HTML source.
- A slow server response: the LCP guidance suggests time to first byte should be around 40% of the whole LCP budget. When hosting is overloaded or far away, the other fixes do not rescue it. How to choose hosting is covered in our article on the domain and hosting of a company website.
- Render-blocking resources: synchronous scripts in the document head and heavy stylesheets delay rendering. The advice is to reduce or inline render-blocking styles.
- Too many plugins and third-party scripts: every chat widget, banner, map and pixel is someone else’s code on your page. For INP the main cause is script evaluation and long tasks that keep the main thread busy.
- Fonts and elements without dimensions: the common causes of CLS are images, ads, embeds and iframes without dimensions, dynamically injected content, and web fonts, where text is laid out in a fallback and reflows once the web font arrives.
For an online shop the cost is direct: a slow product page and a shifting order button are paid for in abandoned baskets. More on how a shop is structured is on our page about e-commerce marketing.
What should you fix first?
The order below is our recommendation, built on the rule “biggest result for the least work first”.
1. Images
Cut the dimensions to what is actually needed, move to a modern format and compress. Set a width and a height on every image so nothing shifts.
2. The server and caching
Check the time to first byte. Caching, sensible hosting and fewer redirects pay off on every page, not just the one you tested.
3. Scripts that earn nothing
List everything third-party: chat, maps, pixels, embedded video, review tools. Remove what you do not use and load the rest after the main content.
4. Fonts
Limit the number of typefaces and weights. Every extra font is extra waiting and extra risk of a shift.
5. Plugins
On WordPress, check which plugins load on every page. Some add their styles and scripts everywhere even though they are used in one place. How to keep plugins under control is covered in our article on WordPress security.
ScaleLab tip: Change one thing at a time and write down the date. If you swap theme, plugins and hosting at once you will not know what helped and what hurt, and the field data arrives weeks later.
If you are not sure where to start, our free website and marketing audit gives an outside view of speed and of the path to an enquiry. The platform also affects how easily these things get fixed: the comparison is in our article on choosing a website platform.
In website development the work on images, code and server runs alongside setting up tracking, before the site goes live.
Frequently asked questions
What counts as fast enough?
Use the thresholds: LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1 at the 75th percentile of visits. If all three are green on mobile, speed is not your problem.
Why do PageSpeed Insights and Search Console show different numbers?
Because they measure different things. Search Console, and the field section of PageSpeed Insights, come from real visitors over the previous 28 days, while the Lighthouse score is lab based, on one device under fixed conditions.
My site is new and has no data in the report. What now?
CrUX only covers pages with enough visitors, so new sites often have no field data. Until then use the lab tools and check by hand on a real phone, not only on a desktop.
Will fixing Core Web Vitals lift my rankings?
Google states that Core Web Vitals are used by its ranking systems, but also that there is no single signal and that good scores do not put a page at the top. Treat speed as a condition to meet, not as a way to outrank more relevant content.
How long before a fix shows up in the report?
Field data accumulates over a 28 day period, so wait a few weeks before judging the result. A lab test shows the change immediately, but it does not prove that visitors feel it.
Sources
- web.dev: Core Web Vitals, metrics and thresholds
- web.dev: Interaction to Next Paint is officially a Core Web Vital (12 March 2024)
- Google Search Central: Understanding page experience in Google Search results (updated 10 December 2025)
- Google Search Console Help: Core Web Vitals report
- Google Developers: About PageSpeed Insights, field and lab data
- Chrome for Developers: Chrome UX Report methodology and eligibility
- web.dev: Optimize Largest Contentful Paint
- web.dev: Optimize Interaction to Next Paint
- web.dev: Optimize Cumulative Layout Shift