Core Web Vitals for a product site: the three numbers

Core Web Vitals are three user experience measures Google uses for assessment as of 2026. They are Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint.

• Largest Contentful Paint, good up to 2.5 s, poor above 4 s. The largest item in the viewport, often your hero image or a big heading.
• Cumulative Layout Shift, good up to 0.1, poor above 0.25. Visual stability as the page loads and updates.
• Interaction to Next Paint, good up to 200 ms, poor above 500 ms. How fast the page responds to taps and clicks.

INP replaced First Input Delay in March 2024. It measures real responsiveness across interactions, not just the first one. For a product site, this includes mobile nav taps, add to cart clicks, and form fields.

Two data sources exist. Field data comes from the Chrome User Experience Report, real Chrome users over 28 days, reported per URL or per origin at the 75th percentile. Lab data is a single test on a controlled device and connection.

• PageSpeed Insights shows field data when there is enough traffic, and always runs a Lighthouse lab test.
• Lighthouse lab runs simulate a mid-range phone on a throttled 4G connection by default. They are a snapshot to diagnose issues.
• Scores vary between Lighthouse runs. Version 10 and later weights: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10%, Speed Index 10%.
• Lighthouse has four categories, each 0 to 100: Performance, Accessibility, Best Practices, SEO.

Use lab tests to find causes and check a fix before you ship. Use field data to prove the experience your users see, and to know if you pass the assessment.

Most real visits in field data are on phones. Lighthouse also tests as a phone by default. If your mobile view is heavy, you will not pass, even if desktop feels fine in the office.

• Measure on a mid-range Android in Chrome if you can. Avoid the latest iPhone on fast wifi for testing.
• Assume slow or inconsistent networks. Optimise for the first screen load, not for a perfect cache.
• Design for small viewports. A giant hero or autoplay video above the fold can push LCP over the limit on mobile.

If your site is responsive, fix the mobile path first. Your field pass depends on it. A fast and stable mobile page also converts better for signups and checkouts.

Most issues are predictable on SaaS sites, docs, blogs and stores. Start with the above-the-fold content on your key pages: home, pricing, signup, docs landing, and a couple of high-traffic articles.

• Slow LCP: a large hero image or video, unoptimised web fonts delaying text, server slow to respond, heavy client-side rendering that waits on JavaScript.
• High CLS: cookie banners inserting late, consent or promo bars pushing content down, images without dimensions, web fonts swapping late, carousels changing height.
• Poor INP: long tasks from third-party scripts, single-page app routes doing heavy work on navigation, event handlers doing too much, big re-renders after clicks.

Name your pages and elements. For example, on /pricing, the largest element is the H1 and subheading. On /guides/getting-started, it is the hero illustration. You fix faster when you know exactly what paints and shifts.

Your goal is a good LCP at or under 2.5 s for most users. Start with the largest element in the viewport on first load. Often that is a hero image or a heading with a web font.

1. 1

   Make the server quick to send HTML

   Use caching at the edge if you can. Return HTML fast so the browser can start rendering. Avoid blocking rewrites that fetch data before sending the shell.

2. 2

   Optimise the LCP image

   Serve the right size for mobile, compress well, and use modern formats. Preload the exact LCP image URL. Do not lazy-load it. Set width and height so it reserves space.

3. 3

   Load critical CSS first, defer the rest

   Inline only the CSS needed for the first screen. Defer non-critical CSS. Remove unused CSS from frameworks on first paint.

4. 4

   Control web fonts

   Preload the exact font files used above the fold. Use font-display swap or optional to avoid blank text. Consider a system font stack for headings.

5. 5

   Reduce main-thread JavaScript on load

   Remove or delay non-essential scripts. Split bundles and defer hydration below the fold. Avoid client-side rendering of content that could be in the HTML.

A fixed /pricing paints a sharp heading and hero quickly, text is visible with a system or preloaded font, and the hero image arrives without a jolt or a delay past the threshold.

Your goal is a CLS at or under 0.1 for most users. The page should not move as it loads or after consent and promo code banners appear.

1. 1

   Reserve space for images and embeds

   Set width and height or an aspect ratio on all images and media. Give carousels a fixed height. Avoid layout based on content that loads later.

2. 2

   Stabilise fonts

   Use font-display so text shows quickly. Choose fallback fonts with similar metrics. Adjust line-height to reduce reflow when the web font swaps in.

3. 3

   Place banners and consent safely

   Insert them in a reserved container or as an overlay that does not shift content. Do not push the page down after load. Respect user interaction states.

4. 4

   Avoid late-loading UI above the fold

   Do not inject new components at the top as scripts finish. Load third-party widgets in reserved containers, off the first screen if possible.

5. 5

   Prefer transform animations

   Avoid animations that change layout properties. Use transform and opacity to keep layout stable.

A fixed /guides/getting-started keeps the masthead height constant, the hero illustration has dimensions, and a cookie bar slides over content without moving it.

Your goal is a good INP at or under 200 ms for most users. INP is sensitive to long tasks and heavy re-renders after an interaction. It measures the worst interactions across a visit, not only the first.

1. 1

   Profile interactions

   In DevTools, record a performance trace while clicking your nav, expanding accordions, submitting forms, and switching tabs. Look for long tasks blocking the main thread.

2. 2

   Break up long tasks

   Split heavy work with smaller chunks. Use async and idle callbacks where safe. Move data fetching off the critical interaction path.

3. 3

   Defer non-urgent re-renders

   Batch state updates. Avoid re-rendering the whole page on a small click. Memoise components. Use CSS for visual effects instead of JS when possible.

4. 4

   Tame third-party scripts

   Remove unnecessary trackers and chat until after user interaction. Load what you must in a worker or off the main thread where supported.

5. 5

   Keep SPA navigation light

   On route changes, render the new view quickly, then hydrate enhancements. Do not block on analytics, A/B tests, or unrelated fetches.

A fixed /signup responds to each field focus and submit button click without a hitch, and the confirmation state appears almost immediately after the tap is registered.

Test the pages that drive revenue or signups first. Home, /pricing, /signup or /checkout, docs landings, and your top two or three blog posts by traffic in Search Console. Use both lab and field views to avoid blind spots.

1. 1

   Check PageSpeed Insights

   Paste a URL. Read the field section if present for LCP, CLS, and INP over the last 28 days, at the 75th percentile. Use the Lighthouse lab section for diagnostics and opportunities.

2. 2

   Run Lighthouse locally

   In Chrome DevTools, run Lighthouse on Performance. Use the mobile mode. Repeat a couple of times. Treat the score as a guide, not a target.

3. 3

   Use the Search Console Core Web Vitals report

   Group pages by status and issue. Start with URLs marked Poor or Needs improvement. Fix one issue pattern across a set of pages, then recheck.

4. 4

   Confirm on a real phone

   Load the page on a mid-range Android over mobile data. Watch the first screen, click the main CTAs, and observe any jank or delays.

5. 5

   Ship, then monitor field data

   After a release, allow time for field data to update. The report uses a 28 day window. Expect a lag before the pass status reflects your changes.

Example: /pricing shows a large hero image and uses two web fonts. LCP is the hero image. Fix by preloading that image, serving a smaller mobile size, and preloading the heading font with swap. Defer the icons font below the fold. Inline critical CSS only for the first screen. Result: the largest element paints within the good threshold for more users.

Example: /guides/getting-started shifts when the cookie banner appears and when the hero illustration loads. Fix by reserving a fixed banner container and adding width and height to the image. Replace a top-inserted promo bar with an overlay that does not push content. Result: CLS stays within the good threshold.

Example: /app onboarding is a single-page app route that freezes after clicking Continue. Fix by deferring analytics until after the new view renders, splitting a parsing task into smaller chunks, and memoising heavy components. Result: interactions respond within the good threshold more often across a visit.

They align with what users feel. Faster first paint, no jumps, and quick taps mean fewer bounces and smoother signups. These are not vanity scores. They are guardrails for experience at scale.

For search, Google uses the assessment to understand page experience. It is not the only factor, but failing badly can hold you back against similar pages. You control these fixes. They are worth the engineering time on your core pages.