Key Takeaways
- Core Web Vitals (LCP, CLS, INP) are real-user field metrics that Google uses as ranking signals — PageSpeed score is a lab-based estimate
- You can score 100 on PageSpeed and still fail Core Web Vitals in the field — and vice versa
- PageSpeed score weights metrics differently than Google Search — INP is a Core Web Vital but barely affects the score
- Field data from CrUX (what Google actually uses) can differ dramatically from lab data (what PageSpeed simulates)
- Optimise for Core Web Vitals first, then use PageSpeed as a diagnostic tool — never chase the score alone
Core Web Vitals and PageSpeed score measure different things
The most common misconception in WordPress performance is that your PageSpeed Insights score and your Core Web Vitals are the same thing. They’re not. They use different data sources, different metrics, different thresholds, and have different impacts on your Google rankings.
Core Web Vitals are three specific metrics — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — measured from real users visiting your site over a 28-day rolling window. This is field data, collected from Chrome browsers via the Chrome User Experience Report (CrUX). Google uses these field metrics as a ranking signal in Search.
PageSpeed Insights score is a weighted composite of six lab metrics (FCP, LCP, Speed Index, TBT, CLS, and Largest Contentful Paint) measured by Lighthouse in a simulated environment — a throttled mid-tier mobile device on a simulated 4G connection. It’s a snapshot, not a rolling average. It’s synthetic, not real-user. For a complete explanation of all three Core Web Vitals, see our complete guide.
Understanding this distinction is critical because it changes what you optimise and how you measure success.
How the PageSpeed score is actually calculated
The Lighthouse performance score is a weighted average of six metrics:
- First Contentful Paint (FCP) — 10% weight. When the first pixel of content renders.
- Largest Contentful Paint (LCP) — 25% weight. When the largest content element renders.
- Speed Index — 10% weight. How quickly content is visually displayed.
- Total Blocking Time (TBT) — 30% weight. Sum of long task blocking time. This is the lab proxy for INP.
- Cumulative Layout Shift (CLS) — 25% weight. Visual stability during page load.
Each metric is scored on a logarithmic curve, then the weighted average produces a score from 0 to 100. The weights matter: TBT alone accounts for 30% of your score, meaning JavaScript execution dominates the overall number.
Here’s the first major disconnect: INP is a Core Web Vital but TBT (its lab proxy) only loosely correlates with it. TBT measures total blocking time during initial page load. INP measures the worst interaction response throughout the entire page lifecycle. A page can have excellent TBT but terrible INP if interactions trigger expensive JavaScript after load. The PageSpeed score won’t catch this.
How you can score 100 and still fail Core Web Vitals
This happens more often than you’d think, and it’s the scenario that confuses WordPress site owners the most.
Scenario 1: Lab vs field divergence on LCP — Lighthouse tests from a fast server with a clean cache. Your real users are on slow mobile connections from diverse geographic locations. Lab LCP might be 1.8 seconds; field LCP from CrUX might be 3.5 seconds because half your traffic comes from regions far from your server. Without proper CDN caching, geographic distance kills your field scores.
Scenario 2: INP problems invisible to Lighthouse — Lighthouse only measures blocking time during page load. It doesn’t click buttons, expand accordions, or submit forms. If your WordPress site loads fast but has a heavy JavaScript dropdown menu, a bloated search overlay, or a WooCommerce add-to-cart handler that blocks for 400ms, Lighthouse won’t detect it. Your PageSpeed score stays high while your INP fails in the field.
Scenario 3: CLS after load — Lighthouse measures CLS during the initial load window. But real users scroll, click, and interact. Late-loading ads, sticky headers that resize, or infinite scroll implementations can cause CLS after Lighthouse stops measuring. Your lab CLS is 0; your field CLS is 0.3.
Scenario 4: Caching only works in lab — If your caching is misconfigured and only works sometimes (common with WooCommerce cart cookies), Lighthouse might hit a cached page and report fast times while 30% of your real users get uncached responses with 2-second TTFB.
How you can score 60 and still pass Core Web Vitals
The reverse is also true — and this is why chasing the PageSpeed score is misguided.
Heavy but well-optimised sites — A content-rich WordPress site with lots of images and JavaScript might score 65 on PageSpeed because of the sheer volume of resources. But if the critical rendering path is optimised — LCP image is preloaded, scripts are deferred, layout shifts are prevented — the Core Web Vitals pass comfortably because those three specific metrics are fine.
TBT penalty without INP impact — If your site loads heavy JavaScript that blocks the main thread during initial load (hurting TBT and therefore the score) but the scripts don’t affect user interactions (because they’re one-time initialisation), your PageSpeed score tanks but your INP is perfectly fine in the field.
Speed Index penalty — Speed Index measures how quickly the viewport is visually complete. A site that loads useful content early but finishes rendering below-the-fold elements slowly will have a poor Speed Index (dragging down the score) but excellent Core Web Vitals because LCP, CLS, and INP are all about above-the-fold and interaction performance.
The takeaway: a PageSpeed score of 60–75 with green Core Web Vitals is better for SEO than a score of 95 with failing field metrics.
What Google actually uses for rankings
Google’s page experience ranking signal uses Core Web Vitals field data from CrUX, not your PageSpeed score. Specifically:
- LCP — 75th percentile of real user experiences must be ≤ 2.5 seconds
- CLS — 75th percentile must be ≤ 0.1
- INP — 75th percentile must be ≤ 200ms
That’s it. Not FCP, not Speed Index, not TBT, not the composite score. Three metrics, measured at the 75th percentile of real-user data over 28 days. For a deeper analysis of how this affects rankings, see our article on Core Web Vitals and SEO impact.
The 75th percentile means 75% of your visitors need to experience good values. If you have 25% of traffic from a region with poor connectivity and they drag your percentile above the threshold, you fail — regardless of your PageSpeed score.
Important caveats:
- Core Web Vitals are a tiebreaker, not a dominant factor — Content relevance, backlinks, and on-page SEO still matter far more. CWV won’t help a thin page outrank authoritative content.
- CrUX data requires sufficient traffic — Sites with very low traffic may not have CrUX data, in which case Google can’t use it as a signal. This is common for new WordPress sites.
- URL-level and origin-level data — If a specific URL doesn’t have enough CrUX data, Google falls back to origin-level (site-wide) data. A few slow pages can drag down the assessment for all pages.
Lab data vs field data: Understanding the gap
The gap between lab and field data is where most confusion lives. Here’s why they differ and which to trust.
Lab data (Lighthouse, WebPageTest) runs a single test on a simulated device with a specific network connection. It’s consistent, reproducible, and great for debugging. But it tests one scenario — one device, one network, one location, one moment in time. You can run lab tests repeatedly with our WordPress speed testing methodology.
Field data (CrUX, Real User Monitoring) aggregates data from thousands of real page loads across all devices, networks, and locations. It reflects actual user experience. But it’s slow to update (28-day rolling window), can’t be tested on-demand, and includes factors outside your control (user’s device age, network quality).
Common reasons they diverge:
- Geographic distribution — Lab tests from one location; field data from everywhere your users are
- Device diversity — Lab simulates one device class; field includes everything from flagship phones to five-year-old budget Androids
- Cache state — Lab usually tests cold cache; many real users have warm browser caches from repeat visits
- Interaction patterns — Lab doesn’t interact with the page; field data captures real clicks, scrolls, and form submissions that affect INP and CLS
- Third-party variability — Ad networks, chat widgets, and analytics scripts behave differently under real-world conditions than in controlled lab environments
- A/B tests and personalisation — Lab sees one variant; field data includes all variants, some of which may be slower
Which to trust? Field data is the truth. Lab data is the diagnostic tool. Use field data to identify if you have a problem, then use lab data to diagnose and fix it.
The right approach to WordPress performance
Stop chasing the PageSpeed score. Here’s the framework we use with every VeloPress client:
1. Check field data first — Open PageSpeed Insights and look at the “Discover what your real users are experiencing” section at the top. If all three Core Web Vitals are green, your ranking signal is fine regardless of your lab score.
2. If field data fails, identify which metric — Is it LCP? Focus on server response time and LCP optimisation. Is it CLS? Fix layout shifts. Is it INP? Address interaction responsiveness. Don’t scatter your effort across everything Lighthouse flags.
3. Use lab tests to debug — Once you know the failing metric, use Lighthouse, WebPageTest, and Chrome DevTools to identify the root cause. Lab tools are excellent for this — they give you waterfalls, filmstrips, and precise timings.
4. Fix and verify in the field — After implementing fixes, you need to wait for CrUX data to update (28 days). Monitor with Google Search Console’s Core Web Vitals report. Don’t rely on a single Lighthouse re-test as proof of success.
5. Use the score for quick comparisons — The PageSpeed score is useful for tracking relative improvement over time and comparing before/after. Just don’t treat it as the target. A site that goes from 45 to 75 has likely made meaningful improvements. A site that goes from 92 to 98 may have just tweaked something irrelevant to real users.
For WordPress sites using performance plugins, it’s especially important to verify with field data — many plugins optimise specifically for Lighthouse tests without improving real-user experience.
Frequently asked questions
Does Google use PageSpeed score as a ranking factor?
No. Google uses Core Web Vitals (LCP, CLS, INP) field data from the Chrome User Experience Report as part of its page experience ranking signal. The PageSpeed Insights score is a Lighthouse lab metric — useful for diagnostics but not directly used by Google Search for rankings.
What PageSpeed score should I aim for?
Aim for 90+ as a general benchmark, but don’t obsess over the number. A score of 75 with passing Core Web Vitals is better for SEO than a score of 98 with failing field metrics. Focus on passing all three Core Web Vitals in the field data section of PageSpeed Insights, then use the score for relative comparisons.
Why does my PageSpeed score change every time I test?
Lighthouse scores have natural variance of 5–10 points between runs due to server response time fluctuations, network conditions, third-party script timing, and Lighthouse’s simulated throttling. Run at least 3–5 tests and average the results. Focus on consistent improvements of 10+ points rather than single-digit changes. Field data (Core Web Vitals) is much more stable because it averages thousands of real page loads over 28 days.
Should I optimise for mobile or desktop PageSpeed?
Mobile. Google uses mobile-first indexing, and the mobile Core Web Vitals assessment is what counts for rankings. Mobile scores are almost always lower because Lighthouse simulates a mid-tier phone with 4G throttling. Desktop scores look better but are less relevant. If your mobile Core Web Vitals pass in the field, you’re good. Desktop will almost certainly pass too.
Is 100/100 on PageSpeed necessary for good SEO?
Absolutely not. Many high-ranking WordPress sites score 60–80 on PageSpeed while passing all Core Web Vitals in the field. Content quality, backlinks, and topical authority have far more ranking impact than the difference between a 90 and a 100 score. Focus on passing Core Web Vitals thresholds in field data — that’s what Google actually measures.
Confused by your score?
We’ll tell you what actually matters
Our free audit analyses both your PageSpeed score and your real-user Core Web Vitals — and tells you exactly what to fix. Score guarantee: 90+ or you don’t pay.
