# Core Web Vitals for a product site: the three numbers

You need to pass Core Web Vitals. This page shows the three numbers, why they matter for search and sales, and how to fix them on a small product site. You will see how lab and field data differ, and how to test without guesswork.

Updated 2026-09-13 · Source: https://porteur.ai/guides/core-web-vitals

## The three numbers that decide your pass

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.

> To pass the assessment, a URL or your origin needs the 75th percentile of real-user visits to be good for all three: LCP, CLS, and INP.

## Field data versus lab data

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.

## Why the phone experience decides the pass

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.

## Common causes on a product site

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.

## Fixing LCP: make the first screen arrive fast

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. **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. **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. **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. **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. **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.

## Fixing CLS: stop the page from jumping

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. **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. **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. **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. **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. **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.

## Fixing INP: make taps and clicks respond quickly

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. **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. **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. **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. **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. **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.

## How to test Core Web Vitals on your pages

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. **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. **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. **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. **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. **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.

> A single bad URL can fail on its own, even if the origin passes. Likewise, if many pages lack traffic, the origin-level view may be the only one available.

## Worked examples for a product site

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.

## Why Core Web Vitals matter for a small site

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.

## Questions

### What are the Core Web Vitals?

They are three measures Google uses for page experience as of 2026: Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. Good thresholds are 2.5 s for LCP, 0.1 for CLS, and 200 ms for INP. INP replaced First Input Delay in March 2024.

### How do I pass the Core Web Vitals assessment?

Your URL or origin needs to be good at the 75th percentile for all three metrics over the last 28 days of real Chrome user visits. Fix the issues that affect the first screen on mobile. Verify in PageSpeed Insights and the Search Console Core Web Vitals report.

### What is the difference between field data and Lighthouse?

Field data reflects real users over 28 days and decides your pass. Lighthouse is a single lab run on a simulated mobile device and network. Use Lighthouse to find causes and test fixes, and field data to confirm results at scale.

### Why does my Lighthouse score change between runs?

It is a simulation on a throttled mobile profile, with network and processing variability. The Performance score also blends several metrics with weights. Run it a few times and focus on consistent issues and the specific opportunities it flags.

### How long until Search Console shows improvements?

The Core Web Vitals report is based on a 28 day window, so you will not see the full effect immediately. If you fix a pattern across a group of URLs, you may see partial changes sooner as new visits replace older data in the window.

### PageSpeed Insights says “Not enough data”. What should I do?

That means the URL or origin lacks sufficient field data. Use the Lighthouse lab section to diagnose and improve. As your traffic grows, field data may appear for the origin first, then for popular URLs.

## Read next

- [Core Web Vitals](https://porteur.ai/glossary/core-web-vitals): Core Web Vitals are Google’s three field speed and responsiveness metrics. See their thresholds, lab versus field, how to read them, and what to fix.
- [Largest Contentful Paint: what slows it and what fixes it](https://porteur.ai/guides/largest-contentful-paint): See what usually counts as LCP, what makes it slow, how to fix it in order, and how to read it in Lighthouse and field data.
- [Cumulative Layout Shift (CLS)](https://porteur.ai/glossary/cumulative-layout-shift): Cumulative Layout Shift is how much a page moves while loading. Keep CLS at or below 0.1. Here is how to measure, find causes, and fix them.
- [Interaction to Next Paint (INP)](https://porteur.ai/glossary/interaction-to-next-paint): INP is the delay from tap to next paint, good up to 200 ms; learn how to measure it, read field versus lab data, and fix script delays.
- [Lighthouse vs PageSpeed Insights: lab and field](https://porteur.ai/compare/lighthouse-vs-pagespeed-insights): Use Lighthouse for repeatable lab checks, PageSpeed Insights for real-user field data. See why scores differ and which to trust for fixes and reporting.
- [GTmetrix alternatives for page speed](https://porteur.ai/alternatives/gtmetrix-alternatives): Free ways to test your page on a phone with real user data, when to use each tool, and when paying for monitored tests is worth it.
- [The Core Web Vitals report in Search Console, page group by page group](https://porteur.ai/guides/search-console-core-web-vitals-report): Understand where the Core Web Vitals data comes from, how page groups work, what to fix by template, and how to move groups to Good.
- [How to speed up a website: the order that pays](https://porteur.ai/guides/how-to-speed-up-a-website): Six changes, ranked by what they usually return for the effort: the hero image, blocking resources, fonts, third parties, the server, the bundle.

Paste your URL to see how your pages load against real searches and rivals in about thirty seconds, free, with three findings you can act on today. Free check: https://porteur.ai/