How to Run a Core Web Vitals & PageSpeed Audit (2026)

A slow page rarely announces itself. There's no error, no broken layout, nothing that looks wrong in the screenshot you approved. There's just a visitor on a phone watching a blank space where the hero image should be, tapping a button that doesn't respond yet, or losing their place when an ad slot loads and shoves the whole page down half a second after it settled. None of that shows up when you load the site on your own fast laptop on office wifi. It shows up in the numbers, and in the bounce rate.

Core Web Vitals are Google's attempt to put those invisible frustrations into measurable form, and since they're a confirmed ranking signal, a quiet performance problem is also a quiet SEO problem. This guide covers what the metrics actually mean in 2026, the difference between lab and field data (the part most people get wrong), and how to run a Core Web Vitals and PageSpeed audit across your whole site, not just the one page you remembered to check.

What Core Web Vitals measure in 2026

There are three metrics, each capturing a different way a page can frustrate a real user. The "good" thresholds, measured at the 75th percentile of real visits, are:

• LCP — Largest Contentful Paint (loading). How long until the largest visible element, usually the hero image or main heading, finishes rendering. Good is 2.5 seconds or less. This is what fails most often on image-heavy blog posts and homepages.
• INP — Interaction to Next Paint (responsiveness). How quickly the page visibly responds after a user clicks, taps, or types, measured across the whole session rather than just the first interaction. Good is 200 milliseconds or less. INP replaced the old First Input Delay metric, and it's the one the largest share of sites fail in 2026, because it exposes heavy JavaScript on checkouts, forms, and filter-heavy listing pages.
• CLS — Cumulative Layout Shift (visual stability). How much the layout jumps around while loading, the button that moves right as you go to tap it. Good is 0.1 or less. It tends to bite product and category pages where dynamic content and ad slots load late.

The rule that catches people out: a page only earns an overall "good" assessment when all three metrics pass at once, at the 75th percentile. One weak metric sinks the whole grade, which is why a dashboard that looks mostly green can still read as failing. (Note: there's been industry debate in 2026 about Google tightening the LCP threshold toward 2.0s, but Google's own documentation still treats 2.5s as the "good" bar, so that's the number to optimize against.)

Lab data vs field data, and why it matters

This is the distinction that trips up most first-time audits, so it's worth getting straight before you run anything.

• Lab data is a simulated test: a tool loads your page once, in a controlled environment, and reports what it saw. It's repeatable, available on demand, and great for diagnosing why a page is slow. Lighthouse and the lab section of PageSpeed Insights produce lab data.
• Field data is what real Chrome users actually experienced, collected over a rolling 28-day window in Google's CrUX dataset. This is what Google uses to judge your page, and it's the data that affects ranking. INP, in particular, can really only be understood from field data, because it depends on real interactions a single lab load can't reproduce.

The practical takeaway: use field data to find out whether you have a problem and which pages it affects, and lab data to diagnose and fix it. A page can post a great lab score and still fail in the field, because real users are on slower devices and worse connections than your test machine, and Google ranks on the field, not the lab.

How to run a Core Web Vitals / PageSpeed audit

There are a few ways to do this, ranging from checking one URL to scanning the whole site. Which fits depends on whether you're diagnosing a single slow page or trying to find every slow page you have.

1. PageSpeed Insights, one URL at a time (free)

Paste a URL into Google's PageSpeed Insights and you get both field data (if Google has enough real-user data for that page) and a full Lighthouse lab report, with a prioritized list of opportunities like oversized images, render-blocking resources, and long main-thread tasks. It's the best free starting point and the most authoritative single-page check, because the field data comes straight from Google. The limit is in the name: one URL at a time. Auditing a 200-page site this way is a long afternoon, and you'll still miss pages you forgot to test.

2. Google Search Console, site-wide field data (free)

The Core Web Vitals report in Search Console groups your URLs by status (Good, Needs Improvement, Poor) using real field data, so you can see roughly how much of your site is passing. It's the right tool for the big picture. Its weaknesses: it groups similar URLs together rather than listing every page, it needs enough traffic to report field data at all (low-traffic pages simply don't appear), and it tells you a group is slow without pinpointing the specific fix.

3. Lighthouse in Chrome DevTools, deep single-page diagnosis (free)

Open DevTools, run the Lighthouse tab, and you get the same lab report as PageSpeed Insights but with more debugging control, throttling options, and a performance trace you can dig into. This is where you actually diagnose why a page is slow. It's lab-only, though, and still one page at a time.

4. Scan PageSpeed across your whole site at once (the practical approach)

The job most teams actually need is checking every page's performance in one pass, so you find the slow pages you didn't already suspect, rather than only auditing the homepage and one product page and assuming the rest are fine.

Steterly includes a full Core Web Vitals and PageSpeed breakdown in every scan, for mobile and desktop, as it crawls your site, so a single scan tells you which pages are slow alongside everything else that's wrong with them. You can start with a free scan of up to 50 pages, no credit card required, with PageSpeed checks included.

The value isn't replacing PageSpeed Insights, it's surfacing the right URLs to point it at. Steterly crawls everything and flags the slow pages across your whole site; you then take the worst offenders into PageSpeed Insights or Lighthouse for the deep field-and-lab diagnosis. And because it's already crawling every page, the same scan turns up what so often drags performance down or ships alongside it: broken and oversized images, broken links, missing meta descriptions, missing image alt text, and H1 structure problems. One scan, the whole performance-and-quality picture.

How to fix the most common Core Web Vitals problems

Finding the slow pages is the hard part. The fixes cluster around a handful of high-impact patterns, by metric.

Improving LCP (loading)

• Optimize the hero image. Compress it, serve a modern format like WebP or AVIF, and size it correctly, oversized images are the single most common LCP killer on content pages.
• Preload the LCP element so the browser fetches it early instead of discovering it late.
• Inline critical CSS and defer the rest so render isn't blocked, and preload key fonts with font-display: swap.
• Speed up the server response. Caching, a CDN, and server-side rendering all cut the time before content can even start painting.

Improving INP (responsiveness)

• Break up long JavaScript tasks so the main thread isn't blocked when a user interacts. This, not images, is the core of INP work.
• Defer non-critical scripts and yield to the main thread so interactions get handled promptly.
• Audit third-party scripts. Tag managers, chat widgets, and ad scripts are frequent INP offenders, load only what you need.

Improving CLS (visual stability)

• Set explicit width and height on every image, video, and iframe so the browser reserves the space before they load.
• Reserve space for dynamic content, ad slots, embeds, banners, so nothing shoves the layout when it arrives.
• Use font-display: swap carefully and preload fonts to avoid text reflowing as a custom font swaps in.

How to keep your scores from slipping back

Performance isn't a one-time fix; it decays. Images get added, scripts pile up, a new ad slot reintroduces layout shift. A few habits keep the numbers honest:

• Re-scan after every deploy and content push. A new template, a heavy image, or an added third-party script can regress a metric overnight, and CrUX works on a 28-day window, so you want to catch it long before it shows up in your ranking.
• Watch the field data, not just the lab. Keep an eye on Search Console's Core Web Vitals report so you're judging by what real users experience, the same data Google ranks on.
• Set early-warning thresholds. Treat a metric drifting toward the edge of "good" as a signal to act, rather than waiting for it to tip into "needs improvement."
• Make a PageSpeed pass part of your pre-launch routine. A quick whole-site speed check belongs on the same checklist as broken links and placeholder text, see our pre-launch website audit checklist.

Frequently asked questions

What's a good Core Web Vitals score in 2026?

A page passes when all three metrics hit their "good" thresholds at the 75th percentile of real user visits: LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less. All three must pass at once, a single metric in the "needs improvement" range fails the overall assessment.

What's the difference between lab data and field data?

Lab data comes from a simulated, on-demand test (Lighthouse, PageSpeed Insights' lab section) and is ideal for diagnosing why a page is slow. Field data is what real Chrome users actually experienced over a rolling 28-day window in Google's CrUX dataset, and it's the data Google uses for ranking. Use field data to find problems and lab data to fix them.

Do Core Web Vitals actually affect Google rankings?

Yes. They're a confirmed part of Google's page experience signals. They aren't the single biggest factor, content and relevance still lead, but they act as a meaningful tiebreaker between comparable pages, and poor scores on competitive queries have been associated with measurable ranking drops. They also affect bounce rate and conversions directly, regardless of SEO.

Why does my page pass in PageSpeed Insights but fail in Search Console?

Usually because you're comparing lab data to field data. PageSpeed Insights' Lighthouse score is a simulated load on a fast connection; Search Console reports what real users on slower devices and networks actually experienced. Real-world conditions are harder than the lab, so a green lab score can still mean a failing field assessment, which is the one that counts for ranking.

Which Core Web Vital is hardest to pass?

In 2026, INP is the most commonly failed metric. Unlike LCP and CLS, which have well-established fix patterns, INP exposes heavy JavaScript and requires rethinking how scripts run on the main thread, so it concentrates on interactive pages like checkouts, forms, and filterable listings.

Can I audit my whole site's PageSpeed for free?

Yes. PageSpeed Insights and Lighthouse are free but test one URL at a time, and Search Console shows site-wide field data for pages with enough traffic. For a whole-site sweep that flags every slow page in one pass, Steterly includes a mobile and desktop PageSpeed breakdown in its free scan of up to 50 pages, no credit card required, so you know exactly which URLs to take into PageSpeed Insights for the deep dive.

Find the slow pages before your visitors feel them

A slow page is the kind of problem that's invisible on your own machine and obvious on a visitor's phone, the blank hero, the unresponsive tap, the layout that jumps just as they reach for a button. Core Web Vitals turn that frustration into three numbers, and because Google ranks on them, the cost of ignoring them is both lost conversions and lost positions.

Steterly is the quality controller for catching it early. Start with a free scan (no credit card required) and get a mobile and desktop PageSpeed breakdown for every page, alongside the broken links, oversized images, and missing tags that tend to drag performance down, so you can find the slow pages and fix them before anyone has to wait.