Core Web Vitals Thresholds in 2026: The Numbers to Hit and How to Test Them

The Core Web Vitals thresholds are: Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less. Google measures each at the 75th percentile of real page visits, separately on mobile and desktop. Hit all three to pass.

Those three numbers are easy to memorise. What trips people up is everything around them: which data counts, why a perfect Lighthouse score can still fail, and why Search Console says one thing while a test tool says another. This guide is the reference version. If you want the background on what each metric actually measures, read our Core Web Vitals explainer first, then come back here for the targets and the testing method.

The Core Web Vitals thresholds at a glance

Google sorts every measurement into three bands. These come from web.dev's metric pages for LCP, INP and CLS:

A few details matter more than they first appear:

• LCP is timed from when the page starts loading, not from when the server responds. Slow DNS, redirects and a slow server response all count against it.
• INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. FID only measured the delay before the first interaction was handled. INP watches every interaction during the visit and reports one of the slowest, so it is a much harder test.
• CLS has no unit. It is a score built from the size of the shifting area and the distance it moves. Shifts are grouped into "session windows" (bursts with less than a second between shifts, up to five seconds long), and CLS reports the worst window.

Why Google uses the 75th percentile

Your page does not have one LCP. It has thousands, one per visit, spread across fast fibre connections and slow 4G on a train. Google needs to reduce that spread to a single number.

It picks the 75th percentile: the value that three out of four visits beat. Google's article on defining the thresholds explains the trade-off. The value should show that most visits had a good experience, but it shouldn't be dragged around by a handful of extreme outliers. A higher percentile such as the 95th would be skewed by a few very slow devices.

In practice this means:

• Fixing only the fast cases does nothing. Improving the experience for people already on quick devices won't move the 75th percentile much. Focus on the slower quarter of your audience, which usually means mid-range Android phones on mobile data.
• Mobile and desktop are judged separately. Many sites pass on desktop and fail on mobile. Look at both, but treat mobile as the one to fix first if most of your visitors use phones.
• A page passes only if all three metrics are "good" at the 75th percentile. Two out of three is a fail.

Field data vs lab data: which one counts

This is the source of most confusion.

Field data decides pass or fail

Field data comes from real Chrome users who have opted in to share usage statistics. It's collected in the Chrome User Experience Report (CrUX) and is what Google uses for the Core Web Vitals assessment. PageSpeed Insights shows it at the top of the report as "Discover what your real users are experiencing", based on a rolling 28-day window.

Two limitations:

• Low-traffic pages have no field data. If a URL doesn't have enough visits, PageSpeed Insights falls back to the whole origin (your domain), or shows nothing at all.
• It's slow to react. Because it's a 28-day window, a fix you ship today takes weeks to show fully.

Lab data is for diagnosis

Lab data comes from a simulated test: one page load, on an emulated device and throttled connection, run by Lighthouse. It's repeatable and instant, which makes it ideal for checking whether a change helped. But it is one synthetic visit, not your audience.

The biggest gap: Lighthouse cannot measure INP, because nobody is clicking anything during the test. It reports Total Blocking Time (TBT) instead, which tracks how long the main thread was busy during load. High TBT often goes with poor INP, but not always. Only field data tells you your real INP.

When the two disagree

How to test your Core Web Vitals, step by step

You don't need paid tools for any of this.

1. Run the page through a PageSpeed test. Our free PageSpeed checker shows the field data (where Google has it) and lab metrics for mobile and desktop in one view. Start with your home page and your three highest-traffic pages.
2. Read the field section first. Note which of LCP, INP and CLS are outside "good", and whether the data is for the URL or the whole origin.
3. Open Search Console's Core Web Vitals report. It groups URLs with similar experiences, so one fix to a template can clear hundreds of pages. Our Search Console beginner's guide shows where to find it.
4. Use the lab section to find the cause. For LCP, look at which element is the LCP element and what delays it. For CLS, look at the layout shift culprits. For INP, look at long tasks and TBT.
5. Fix one thing, then retest in the lab. Lab results confirm the change worked straight away.
6. Wait for the field data. Give it four weeks before judging, then use "Validate fix" in Search Console.
7. Re-check after big changes. A new theme, plugin, chat widget or tag manager container can undo months of work.

What usually causes each metric to fail

The fixes deserve their own guides, so here's a short map to the right one.

Slow LCP

The usual culprits are a slow server response, a large hero image, render-blocking CSS and JavaScript, and lazy-loading the image that's actually the LCP element. Start with improving Largest Contentful Paint and, if the server is slow, work on your server response time (TTFB). Oversized images are a quick win with the free image compressor.

Poor INP

INP problems come from JavaScript keeping the main thread busy when someone interacts: heavy frameworks, third-party tags, big event handlers. See how to fix Interaction to Next Paint, and audit every third-party script you load.

High CLS

CLS is usually caused by images and embeds without set dimensions, adverts or cookie banners pushing content down, and web fonts swapping late. Fixing cumulative layout shift walks through each one.

Do Core Web Vitals affect rankings?

Yes, but modestly. Google uses Core Web Vitals as part of its page experience signals. Its documentation is clear that relevant, helpful content still matters far more, and that good scores don't guarantee top rankings. Think of passing as removing a disadvantage, not gaining a big boost.

The stronger reason to care is visitors. A page that loads slowly or jumps as someone goes to tap a button feels broken, and that costs enquiries and sales whatever Google thinks.

A realistic target for small business sites

For most small business sites built on WordPress, Shopify, Wix or Squarespace, here's a sensible order of work:

1. Get LCP under 2.5 seconds on mobile. This is the metric most sites fail, and image and hosting fixes are usually enough.
2. Get CLS under 0.1. Often a handful of template changes: image dimensions, reserved space for banners, font loading.
3. Then tackle INP. It's the hardest to fix without a developer, because it means removing or deferring scripts.

If your site has no field data yet, aim for good lab results and keep checking monthly. Make It Flow's free tools are a good starting point, and our website speed guide covers the wider picture beyond the three vitals.

FAQ

What is a good Core Web Vitals score?

There isn't a single score. A page has good Core Web Vitals when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. The 0 to 100 PageSpeed performance score is a separate lab measure and isn't what Google uses for the assessment.

Have the Core Web Vitals thresholds changed?

The good thresholds for LCP (2.5 seconds) and CLS (0.1) have stayed the same since the metrics launched. The main change was in March 2024, when INP replaced First Input Delay as the responsiveness metric, with a good threshold of 200 milliseconds. Check web.dev's metric pages if you need to confirm the current values.

Why does my page show no Core Web Vitals data?

Field data comes from the Chrome User Experience Report, which needs enough real visits to a URL or site to report on. New or low-traffic pages often have none. PageSpeed Insights may show origin-level data instead, or nothing. Use lab tests in the meantime and check again as traffic grows.

Is a 90+ PageSpeed score the same as passing Core Web Vitals?

No. The PageSpeed score is calculated from a single simulated lab test, while the Core Web Vitals assessment uses field data from real Chrome users. A page can score highly in the lab and still fail in the field, especially on INP, which the lab test cannot measure at all.

How long does it take for fixes to show in Search Console?

Field data is based on a rolling 28-day window, so improvements appear gradually and take around four weeks to show fully. Once you've shipped a fix, use "Validate fix" in the Core Web Vitals report. Search Console then monitors the affected URLs over the following weeks.

Do I need to pass on both mobile and desktop?

They're assessed separately, and Search Console reports them separately. Google primarily uses the mobile version of a page for indexing, and most small business sites get much of their traffic from phones, so prioritise mobile. Desktop usually passes once mobile does.

Related reading

• WordPress Core Web Vitals: Which Plugins Actually Help: Improve WordPress Core Web Vitals with the right plugin types for LCP, INP and CLS, a before-and-after testing method, and the plugin overlaps to avoid.