To run a core web vitals tester on your site, paste a URL into Google's PageSpeed Insights, switch between the mobile and desktop tabs, and read the real-user data at the top of the report. Your page passes the assessment when Largest Contentful Paint (LCP) is 2.5 seconds or less, Interaction to Next Paint (INP) is 200 milliseconds or less, and Cumulative Layout Shift (CLS) is 0.1 or less. These are measured at the 75th percentile of real visits. If any one of the three fails, the whole assessment fails.
Running the test is the easy part. The hard part is knowing which numbers to trust, why a lab score and a field score disagree, and what to change when one metric is red. Most free testers show the same underlying data in different packaging, and most stop at the score without telling you what to do next.
This guide covers five steps: run the test, read the assessment, find the cause, fix it, and retest. We build speed tooling for ecommerce storefronts at Nostra AI, so the examples lean toward online stores. Every step applies to any site.
A Core Web Vitals test measures how fast your main content appears, how quickly the page reacts to input, and how stable the layout stays while it loads. Every core web vitals tester you will find, free or paid, reports some version of those three numbers. Knowing what they mean makes every report easier to read.
Largest Contentful Paint (LCP) times how long the biggest visible element, usually a hero image or a headline, takes to render. Interaction to Next Paint (INP) replaced First Input Delay in March 2024. It measures how long the page takes to show a visual response after a tap, click, or key press. Cumulative Layout Shift (CLS) scores how much visible content jumps around while you use the page. The thresholds are the same on mobile and desktop.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| INP | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Field data comes from real Chrome users and is published in the Chrome User Experience Report (CrUX). It is the data Google uses to judge your pages. It is a rolling 28-day window, and the score is the 75th percentile. That means three out of four visits must meet the threshold for a metric to count as good.
Lab data comes from a simulated page load, such as a Lighthouse run with throttled network and CPU. It is repeatable, which makes it ideal for debugging. But it loads the page once as a brand-new visitor and never taps a button, so Lighthouse reports Total Blocking Time as a stand-in for INP. A page can score 95 in Lighthouse and still fail in the field, because your real visitors use slower phones and weaker connections than the simulation assumes.
Trust field data to judge your score, and use lab data to find out why it is bad.
Yes, for two reasons. Google's ranking systems look at them as part of page experience. Relevance and content quality still dominate, so treat vitals as a tiebreaker between similar pages, not a shortcut to position one.
The bigger payoff is with the people who land on the page. A product page that takes four seconds to show its main image, or that shifts as a shopper reaches for the add-to-cart button, loses sales before anyone sees your offer. Fixing vitals helps rankings a little and conversions a lot.
The fastest way to test Core Web Vitals is to enter your URL in PageSpeed Insights. It is free, needs no login, and shows real-user data next to a Lighthouse lab run. Add Search Console afterward to see how far the problem spreads across your site.
Start with the page that earns the most traffic or revenue, not just the homepage. Homepages are often the first page a visitor sees, so they carry the full cost of a cold cache. Follow these steps.
PageSpeed Insights tests one URL at a time. The Core Web Vitals report in Search Console covers your whole property, split by mobile and desktop. It is only available once you have confirmed ownership of the site.
The report groups similar URLs, such as every product page, into a single status of Good, Needs improvement, or Poor. Click an issue to see example URLs in the group. This tells you whether you have one broken template or a sitewide problem. A group of 800 product pages failing LCP is one fix, not 800.
Different tools answer different questions, and mixing their numbers is the most common source of confusion.
| Tool | Data type | Best for |
|---|---|---|
| PageSpeed Insights | CrUX field data plus Lighthouse lab data | First check of a URL or whole origin |
| Search Console report | CrUX field data | Finding failing page groups on your own site |
| Lighthouse in Chrome DevTools | Lab | Testing a fix on staging |
| DevTools Performance panel | Lab, with CrUX context | Debugging slow interactions and layout shifts |
| Third-party checkers and Chrome extensions | Often CrUX or the PageSpeed API | Quick checks and history |
Run PageSpeed Insights first, then use Search Console to see how many pages share the problem.
The assessment is a pass or fail verdict based on field data. It reads Passed only when LCP, INP, and CLS are all good at the 75th percentile, and it fails when even one is not. Reading it correctly keeps you from fixing the wrong thing in any core web vitals check.
Each metric shows a colored bar with the share of visits that were good, needing improvement, or poor. It also shows one headline value, which is the 75th percentile. That headline value decides the verdict, not the share of green. A bar that is 70% green can still fail, because the 75th visitor out of 100 had a slow experience.
Here is a worked example for a mobile product page.
The assessment fails, and the only metric to work on is LCP. Do not spend a week tuning JavaScript for INP when it already passes. If the page's own data differs sharply from the origin data, remember that a single page and a whole site are different samples. Judge each template by its own numbers.
One failing metric fails the whole assessment, so fix the worst one first and ignore the ones already green.
You do not install anything to get Core Web Vitals data. Google collects it from Chrome users and fills it in automatically. But a URL needs enough traffic to appear in CrUX. Low-traffic pages often show no field data, and PageSpeed Insights falls back to origin-level data for the whole site, which is a useful summary.
When neither exists, you only have lab data. Use it as a direction, not a verdict. Lab numbers are good for spotting obvious problems like an oversized hero image, but they cannot tell you whether real visitors pass. In that case, collect your own field data, which Step 5 covers.
Work backward from the failing metric. Split LCP into its four phases, record the slow interaction for INP, and highlight the shifting elements for CLS. A good core web vitals tester gives you the score, but the cause needs a diagnostic pass.
LCP is the sum of four phases, and the slowest phase tells you where to work. The Performance panel in Chrome DevTools shows the LCP element and a breakdown of these phases.
| Phase | What it covers | Typical cause |
|---|---|---|
| Time to first byte (TTFB) | Request until the first byte of HTML arrives | Slow server, no CDN, redirects |
| Resource load delay | TTFB until the browser starts fetching the LCP resource | Image lazy-loaded or found late, rendered by JavaScript |
| Resource load duration | Download time of the image or font | Oversized file, wrong format |
| Element render delay | Download finished until the element is painted | Render-blocking CSS or JavaScript |
Start by checking the first row. A 1.8-second TTFB leaves very little room under a 2.5-second target, so no image tweak will rescue the page. Look at the cause of slow responses first: a slow origin, missing caching, or a chain of redirects.
For INP, open the Performance panel and use the live metrics screen. Then use the page like a shopper would: open the menu, pick a size, expand a filter, add to cart. The screen logs each interaction and its delay. When one is slow, record a trace and repeat it. Long tasks appear with red markers in the flame chart, and the call stack shows which script is blocking the main thread. Third-party tags are frequent culprits.
For CLS, record a trace and open the Layout Shifts track. Clicking a shift shows which element moved. Pay attention to shifts after load, such as a cookie banner sliding in or a review widget pushing content down. Lighthouse often misses these because it focuses on the initial load.
Diagnose before you fix, because the same red LCP can come from four different causes.
Fix the cause you found, not a generic checklist. Most failing stores trace back to a late-loading hero image, heavy third-party JavaScript, or media without reserved space. These fixes are small, and each one targets a specific metric in your test results.
Make sure the LCP image is in the HTML, not injected by JavaScript. Give it high priority and never lazy-load it. Lazy loading belongs on images below the fold. Serve a modern format like WebP or AVIF at the displayed size.
.svg)
<img
src="/images/hero-1200.webp"
srcset="/images/hero-600.webp 600w, /images/hero-1200.webp 1200w"
sizes="100vw"
width="1200"
height="600"
fetchpriority="high"
alt="Model wearing the new collection">
If TTFB is the bottleneck, add a CDN, cache HTML where it is safe, and remove redirect chains such as http to https to www. Serving pages from the edge shortens the trip to the server, which is the approach Nostra's Dash speed agent takes on storefronts.
INP fails when the main thread is busy at the moment of a tap. Audit your scripts first. Remove unused third-party tags, delay chat widgets and review widgets until the user needs them, and defer anything non-essential. Then shorten your own long tasks by painting the visual response first and doing heavy work afterward.
button.addEventListener('click', async () => {
showSpinner(); // paint the response first
await new Promise(r => setTimeout(r, 0)); // yield to the main thread
runHeavyWork(); // then do the expensive part
});
Keep event handlers small. A filter that re-renders 500 product cards synchronously will fail INP on a mid-range phone, no matter how fast your server is.
Layout shifts happen when the browser does not know how much space something needs. Give every image and video explicit dimensions, and reserve room for banners, ad slots, and embeds before they load.
img, video { max-width: 100%; height: auto; }
.hero-banner { aspect-ratio: 3 / 1; }
.promo-bar { min-height: 44px; }
.ad-slot { min-height: 250px; }
Insert new content below what the visitor is already looking at, not above it. Animate with transform instead of properties like top or height, because transforms do not shift layout.
Reserve space for everything that loads late, and the layout stops moving.
Retest in the lab right after you deploy, then wait for field data to catch up. Lab results confirm the fix worked in principle. Field results, which Google uses, lag behind by weeks. Use any core web vitals tool for the first check, and your own data for the long game.
Run PageSpeed Insights again and compare the lab numbers to your first run. If the LCP breakdown improved in the phase you targeted, the fix is working. CrUX data is a rolling 28-day average, so it takes up to four weeks to show the full effect. Your field numbers will move gradually, not overnight.
In Search Console, open the failing issue and click Validate Fix. Google then monitors the affected URLs for up to 28 days and reports whether they pass. Do not stack ten changes at once. Ship one fix, watch it, then ship the next, so you know what worked.
The 28-day window means you judge a fix in weeks, not hours.
CrUX tells you when a problem exists, but rarely why. For better detail, measure your own visitors with Google's open-source web-vitals library. You can see which page, device, and element cause the slow numbers.
<script type="module">
import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
function send(metric) {
navigator.sendBeacon('/vitals', JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id
}));
}
onLCP(send);
onINP(send);
onCLS(send);
</script>
Replace /vitals with an endpoint you control. Keep in mind that your own sample includes everything that hits your site. Automated bot traffic can skew session counts and averages, so filter it out before you trust the trends.
Testing Core Web Vitals comes down to a loop. Run PageSpeed Insights on a key page, read the field data to see which metric fails, find the cause with DevTools, apply one targeted fix, and recheck after the 28-day window. Repeat this for each template and your site stays in the green.
Clean data makes that loop reliable. If bots are inflating your sessions and muddying the numbers you use to judge speed, Edge Protect filters bad bots before they reach your storefront. That leaves you with a clearer view of what real shoppers experience.
