Page experience is a confirmed Google ranking factor, and it is measured largely through Core Web Vitals — a set of metrics that quantify how fast, responsive and visually stable a page feels to real users. In March 2024, Google made the biggest change to this program since launch: it replaced First Input Delay (FID) with Interaction to Next Paint (INP), raising the bar for responsiveness. If you have not revisited your performance since then, now is the time.

What Core Web Vitals measure

The three vitals each capture a different part of the user experience, and Google has a clear 'good' threshold for each:

  • LCP (Largest Contentful Paint) — loading. How long until the biggest element (usually a hero image or headline) is visible. Target: under 2.5 seconds.
  • INP (Interaction to Next Paint) — responsiveness. How quickly the page reacts to user input across the whole visit. Target: under 200 milliseconds.
  • CLS (Cumulative Layout Shift) — visual stability. How much the layout jumps around as it loads. Target: under 0.1.

Google measures these on real-world mobile traffic (field data) for ranking, while lab tools help you debug. The goal is to be in the 'good' range for at least 75% of visits.

Why INP replaced FID

FID only measured the delay before the browser began processing the very first interaction. It was easy to pass and did not reflect real frustration. INP is stricter: it looks at the latency of all interactions throughout the visit and reports a value near the worst one. In practice, INP exposes pages bogged down by heavy JavaScript that FID happily ignored — so many sites that 'passed' before now need work.

Improving LCP (loading)

LCP is usually limited by server speed and your largest above-the-fold asset. Start by measuring real Time to First Byte and total load time with the Page Speed & Size Test. If TTFB is high, improve hosting, add caching or use a CDN. Then optimize the LCP element itself: compress and properly size the hero image, preload it, and avoid lazy-loading anything above the fold. Confirm compression is active with the Gzip / Brotli Compression Test.

Improving INP (responsiveness)

INP problems almost always trace back to JavaScript blocking the main thread. To improve it: break up long tasks, defer non-essential scripts, remove unused third-party code, and minimize the work done in event handlers. Each heavy script you remove gives the browser more room to respond quickly. If your site is built on a JavaScript framework, read our JavaScript SEO guide for related considerations.

Improving CLS (visual stability)

Layout shift is jarring and easy to fix. The main causes are images without dimensions, ads and embeds that load late, and web fonts that swap. The fixes: always set width and height (or aspect-ratio) on images and video, reserve space for ads and dynamic content, and load fonts carefully to avoid a visible swap. These changes cost little and often move CLS into the green immediately.

Do not forget mobile and caching

Because Core Web Vitals are measured mobile-first, every fix should be validated on mobile. Confirm your responsive setup with the Mobile-Friendly Checker, and review caching and security headers with the HTTP Header Checker — long cache lifetimes make repeat visits dramatically faster. See our mobile-first indexing guide for the full picture.

How to prioritize your work

Start with field data to see which vital is failing for real users, then use lab tools to find the specific cause. Fix the worst-performing metric first, and focus on your highest-traffic templates — improving one page template often lifts thousands of URLs at once. Re-measure after each change; performance work is iterative, and small wins compound.

How much do Core Web Vitals affect rankings?

Be realistic: page experience is a relatively lightweight signal compared to relevance and links. A fast page with thin content will not outrank a slow page that better answers the query. Think of Core Web Vitals as a tiebreaker and a conversion booster rather than a magic ranking lever — but in competitive niches where content quality is similar, that tiebreaker matters, and faster pages always convert better.

Field data vs lab data

One source of confusion deserves its own explanation. Lab data comes from a single simulated test in a controlled environment — useful for debugging because it is repeatable. Field data comes from real Chrome users visiting your site over the previous 28 days, and this is what Google actually uses for ranking.

The two often disagree, and that is normal. A lab test on a fast connection might show a great LCP, while field data reveals that real users on mid-range phones and slower networks experience something much worse. Always treat field data as the source of truth for whether you pass, and use lab tools only to diagnose the cause. If you have little traffic, field data may be unavailable — in that case lean on lab tools and focus on the well-known fixes above.

A simple workflow

Put it all together into a repeatable loop: check field data to find the failing metric, reproduce it in a lab tool to locate the cause, apply the relevant fix (server speed for LCP, JavaScript for INP, dimensions for CLS), and re-measure. Tackle your highest-traffic template first so a single fix lifts many URLs at once, then work down the list. Performance is never 'done', but a steady cadence keeps you comfortably in the green.

For free field data, Google Search Console includes a Core Web Vitals report that groups your URLs by status, and the Chrome User Experience Report (CrUX) feeds the same real-user numbers Google ranks on. Pair those with the on-page timing breakdown from the Page Speed & Size Test to connect a failing metric to a concrete cause on a specific page. Together they give you everything you need to diagnose and verify improvements without any paid tooling.

Conclusion

Core Web Vitals turn 'fast and pleasant to use' into measurable targets: LCP under 2.5s, INP under 200ms, CLS under 0.1. Measure honestly with the Page Speed & Size Test, fix the worst metric first, and validate on mobile. For a structured approach to performance, follow our page speed optimization checklist and fold it into your overall technical SEO audit.