Page speed vs Core Web Vitals comes down to this: “page speed” is a loose label for how fast a page loads, and the PageSpeed Insights score is a lab test run on one simulated device. Core Web Vitals are three specific metrics (LCP, INP and CLS) measured from real Chrome users. Google’s ranking systems use Core Web Vitals. They don’t use your 0 to 100 PageSpeed score.
That difference changes what you should fix. It’s easy to burn weeks chasing a green 90+ score while your real-user data already passes. It’s just as easy to celebrate a 95 while visitors on cheap phones struggle. Wrong number, both times.
Here’s how the two relate, what Google actually says about ranking, and my verdict on what to fix first.
Why Does Picking the Wrong Metric Cost You?
Because speed work is expensive. Developer hours, plugin changes, theme rewrites and CDN bills all add up fast. If you spend that budget moving a lab score that Google doesn’t rank on, you can end up with a prettier report and the same traffic.
The opposite mistake hurts too. Some owners see “Core Web Vitals: Passed” in Search Console and stop there, even though slow server responses or heavy scripts are quietly costing them visitors. Passing is the floor. It isn’t the whole user experience.
Page Speed vs Core Web Vitals: The Mistake Most Comparisons Make
Most comparisons put the PageSpeed number and Core Web Vitals side by side as if they were two versions of one thing. In my experience, that framing causes most of the wasted speed work I see. They aren’t the same thing.
The big colored score in PageSpeed Insights comes from Lighthouse. Chrome’s Lighthouse scoring documentation lists the weights: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10%. Scores from 90 to 100 are green, 50 to 89 orange, and 0 to 49 red.
Notice what’s missing. INP isn’t in that list at all, because a lab test has no real user clicking anything. Lighthouse uses Total Blocking Time as a stand-in. And the same docs admit scores fluctuate with ads, routing, device and even browser extensions.
So I treat the score as a diagnostic. A useful one. Just not the thing Google ranks.
What Are Core Web Vitals, Exactly?
Core Web Vitals are three user-experience metrics defined on web.dev, each with a “good” threshold:
- Largest Contentful Paint (LCP) measures loading. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP) measures responsiveness. Good is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability. Good is 0.1 or less.
Google measures each at the 75th percentile of page loads, split by mobile and desktop. In plain terms, three out of four visits need to hit the threshold, not your best visit on office Wi-Fi.
INP replaced the older responsiveness metric as a Core Web Vital on March 12, 2024. If a guide still lists three metrics that don’t include INP, it’s out of date.
The Conditions That Decide Which Number Matters
Four things change which number deserves your attention:
- Whether you have field data. Low-traffic pages often have no real-user data in the Chrome UX Report, so the lab score is all you’ve got.
- Your goal. Ranking eligibility and conversion rate are different jobs. Speed beyond “good” still helps visitors even when it adds nothing to rankings.
- Device mix. A site with mostly mobile visitors lives or dies on the mobile field data, which is usually the harder test.
- Where the slowness lives. Server response, images, scripts and layout each point to a different fix and a different person on your team.
Option A: Core Web Vitals Field Data
Best for: any site with enough traffic to appear in the Chrome UX Report (CrUX), which feeds both PageSpeed Insights and the Search Console Core Web Vitals report.
Sweet spot: deciding what to fix and proving the fix worked for real people.
Strengths: It’s the data Google’s ranking systems use. It reflects your actual visitors, their phones and their networks. And it includes INP, the one metric a lab can’t measure directly.
Weaknesses: It’s slow. Google’s PageSpeed Insights documentation says field data covers the previous 28-day collection period, so a fix you ship today takes weeks to show fully. It also tells you that a page is slow, not why.
When a page lacks enough data, PageSpeed Insights falls back to origin-level data for the whole site. If the origin is too small as well, you get no field data at all.
Option B: The PageSpeed or Lighthouse Score
Best for: developers debugging a template, new sites without field data, and pre-launch testing.
Sweet spot: finding the cause behind a failing field metric, then checking a fix before it goes live.
Strengths: It’s instant and repeatable. Every audit points to a specific resource, script or image. And it works on a staging site no user has ever visited.
Weaknesses: Google describes lab data as a simulated load “on a single device and fixed set of network conditions.” That’s one guess at your audience. The score also blends metrics that aren’t Core Web Vitals, like Speed Index and First Contentful Paint, and it can’t see INP.
My honest view: the lab score is a flashlight, and I use it constantly. I never report it to a client as a ranking number.
Where Does TTFB Fit In?
“Page speed” usually covers more than the three vitals. Time to First Byte (TTFB), First Contentful Paint and total load time all live under that umbrella.
TTFB measures the gap between starting navigation and the first byte of the response. web.dev calls 0.8 seconds or less good and anything above 1.8 seconds poor. It also says plainly that TTFB isn’t a Core Web Vitals metric, so you don’t strictly need a good TTFB as long as it doesn’t stop you hitting the metrics that matter.
In practice, though, a slow server eats straight into LCP. When I audit a slow site, cheap shared hosting or an uncached WordPress install is often the first bottleneck I look for, because no image compression can win back time the server already lost.
Head-to-Head: The Criteria That Actually Decide It
| Criterion | Core Web Vitals (field) | PageSpeed / Lighthouse score (lab) | Winner and why |
|---|---|---|---|
| Used by Google’s ranking systems | Yes | No | Field. Google names Core Web Vitals, not the score |
| Measures real visitors | Yes, 75th percentile over 28 days | No, one simulated device | Field. It reflects your actual audience |
| Includes INP | Yes | No, uses Total Blocking Time instead | Field |
| Speed of feedback | Weeks | Seconds | Lab. Ideal for testing fixes |
| Explains the cause | Rarely | Yes, per resource | Lab. It points at the culprit |
| Works on low-traffic or new pages | Often no data | Always | Lab |
What Does Google Say About Page Experience and Rankings?
Google’s page experience documentation is clear and measured. It says “Core Web Vitals are used by our ranking systems” and recommends site owners achieve good Core Web Vitals.
It also sets limits. The same page says good scores in Search Console or third-party tools don’t guarantee top rankings, and that Google “always seeks to show the most relevant content, even if the page experience is sub-par.” Where lots of helpful content competes, a great page experience “can contribute to success in Search.”
Read that carefully. Relevance comes first. Page experience helps you win among similar pages, and it’s a set of signals (security, mobile display, intrusive interstitials, ad density) rather than one speed score.
So is page speed a ranking factor? The Core Web Vitals part is, by Google’s own words. The lab score isn’t. And no amount of speed will outrank a page that answers the query better.
The Verdict: Fix Failing Field Metrics First
Core Web Vitals field data is the number to act on for SEO, because it’s what Google’s ranking systems use and it reflects your real visitors. However, if your pages have no field data, the Lighthouse score is your only proxy, so use it to find and fix the same three problems.
My order of work is simple. First, open the Search Console Core Web Vitals report and find the URL groups marked Poor or Need improvement on mobile. Fix those templates before anything else, starting with the ones that carry the most traffic.
Second, use PageSpeed Insights and Lighthouse on one sample URL per failing group to find the cause. Big hero images and slow servers usually drive LCP. Heavy JavaScript usually drives INP, and on WordPress the editor you build with can add much of that weight, as I show in my Elementor vs block editor SEO comparison. Missing image dimensions, late ads and injected banners usually drive CLS.
Third, once every group passes, stop chasing the score. Moving from 88 to 97 in the lab rarely changes anything Google measures. That time is usually better spent on content and links.
For a wider pass across crawling, indexing and site health, my technical SEO checklist puts speed in context with everything else. If you’d rather hand the whole thing over, that’s what our technical SEO service covers.
When Does the Answer Flip?
The verdict holds for most established sites. It flips in a few specific situations.
- If your site is new or low-traffic, then there’s no field data yet. Work from the lab score and the individual lab metrics until CrUX starts reporting.
- If you run ecommerce or paid campaigns, then speed past the “good” line can still matter for conversions, even with zero ranking benefit. Judge it by your own revenue data.
- If field data passes but TTFB is poor, then fix the server anyway. Passing today on a slow origin leaves you one heavy plugin away from failing.
- If you’re about to launch a redesign, then the lab score is the only way to catch a regression before real users feel it.
Honestly, the healthiest setup uses both. Field data tells you where to look. The lab tells you what to change.
If you want me to check which of your templates fail and why, start with a free SEO audit.
Frequently Asked Questions
Is a PageSpeed Insights Score of 100 Necessary for SEO?
No. Google’s ranking systems use Core Web Vitals field data, not the Lighthouse score. A page can score in the 70s in the lab and still pass all three Core Web Vitals for real users. Aim to pass the field assessment, then spend leftover effort on content.
Why Does PageSpeed Insights Show Passed Core Web Vitals but a Low Score?
The top section shows field data from real Chrome users over 28 days. The score below is a single lab test on a simulated device and network. Real visitors may have faster phones or connections than the simulation, so the two can disagree without either being wrong.
Is TTFB a Core Web Vital?
No. The three Core Web Vitals are LCP, INP and CLS. TTFB is a supporting metric that web.dev treats as a diagnostic for loading, with 0.8 seconds or less rated good. A slow TTFB often drags LCP down, which is why it’s worth fixing anyway.
How Long Until Core Web Vitals Fixes Show Up?
Field data in PageSpeed Insights covers a rolling 28-day window, so a fix appears gradually and takes about four weeks to be fully reflected. Search Console also lets you start a validation on a fixed issue and then monitors it for several weeks.
Last updated: September 2026 by Mizanur Rahman
