The Page Speed Metrics Google Actually Scores You On
Most people trying to speed up their site are watching the wrong numbers. They screenshot a 94 from GTmetrix and call it done, while Google's actual scoring sits in a completely different set of metrics underneath. The three core web vitals metrics Google measures are specific, named, and each tied to a real moment in how a visitor experiences your page. Getting them wrong isn't just a score problem. It affects where you rank.
On this page
Why Your Overall Speed Score Is Not What Google Measures
A 92 in Lighthouse feels like a pass. An 87 in GTmetrix feels close. Neither of those numbers has any direct bearing on how Google ranks your page. PageSpeed Insights and similar tools are diagnostic instruments, built to help you find problems and prioritise fixes. They are not ranking signals. Google does not take your composite score, hand it to a ranking algorithm, and reward the sites with the highest number. Treating it as though it does leads people to chase the wrong target entirely.
The signals that feed into search ranking come from the core web vitals metrics specifically. Largest Contentful Paint measures how quickly the main content loads for a real user. Interaction to Next Paint captures how fast the page responds after someone taps or clicks. Cumulative Layout Shift tracks whether the page visually jumps around while it settles.
These three are measured from real Chrome user data collected in the field, not from a lab simulation run on a tool. A site can score 95 in Lighthouse and still carry poor field data on all three vitals, which is the version of performance that matters to Google.
LCP: The Metric That Times Your Biggest Element
Largest Contentful Paint measures how long it takes for the biggest visible element on the page to fully render in the viewport. That element is usually a hero image, a large H1 heading block, or occasionally a video thumbnail sitting above the fold. Google draws a clear line here, under 2.5 seconds is good, anything above 4 seconds is poor, and the gap between those thresholds is where most sites bleed ranking potential. The score is tied to real user experience data, not just a lab test, so it reflects what your actual visitors see on their devices.
The things that hold LCP back most often are unoptimised images served at far too large a file size, render-blocking scripts that sit in the <head> and delay paint, and slow initial server response times. A common pattern is a 3MB hero image that loads last because three third-party scripts are queuing ahead of it.
Fix the image format first. Switch to WebP, and set a proper fetchpriority="high" attribute on that element so the browser knows to load it before anything else. If you want to see how these individual fixes stack up against each other in practice, the pattern of what shifts the score is often different from what people expect.
INP Replaced FID. What Changed?
First Input Delay measured only the delay before a browser began processing your first click or tap. It ignored everything that happened next, which made it relatively easy to pass without your site feeling responsive to users. Google retired FID and replaced it with Interaction to Next Paint, which measures the full round trip from interaction to the moment the page visually updates. That broader scope makes it a far more honest signal of how a site behaves under real use, and it is considerably harder to game with a quick fix.
Poor INP scores on WordPress sites almost always trace back to heavy JavaScript running on the main thread. Page builders like Elementor or WPBakery load substantial script bundles that keep the browser occupied, so when a visitor clicks a menu or submits a form, the response stalls while those scripts finish what they were doing.
Google’s threshold for a passing INP score is under 200 milliseconds, and bloated builder output regularly pushes sites well past that. If you are working through WordPress performance fixes, auditing and deferring non-critical JavaScript is usually the most productive place to start.
CLS and the Invisible Shift
What the metric is measuring
Cumulative Layout Shift measures how much your page jumps around while it loads. It is the metric that catches people out most often because the problem rarely shows up clearly in an audit report. The score is calculated by tracking unexpected movement of visible elements, weighted by how much of the viewport shifts and by how far things move. A score above 0.1 is considered poor by Google.
The causes are usually mundane. An image without explicit width and height attributes. A font that swaps in late and nudges surrounding text. An ad slot that appears above the fold after the initial paint, shoving everything below it downward.
Why it’s hard to diagnose
What makes CLS frustrating is that the shift often only happens on a slow connection or on a device that loads resources in a different order than your development machine does. You can sit there on a fast desktop watching the page look perfectly stable, while a visitor on a mid-range phone sees the “Contact Us” button jump just as they tap it. Field data from real users tends to surface these problems far more reliably than a lab test ever will, because it captures the full range of conditions your actual audience is browsing in.
Field Data vs Lab Data
What the lab score actually tells you
Running a PageSpeed Insights test and watching the score tick up feels productive, but that number is not what Google feeds into its ranking signals. The score you see in the lab simulation is generated by a single headless browser under controlled conditions, with a fixed connection speed and no browser cache. It is useful for spotting problems, but it is a snapshot of one synthetic visit, not a picture of how your real audience experiences the page.
Google’s ranking signal comes from the Chrome User Experience Report, which collects Core Web Vitals measurements from genuine Chrome users visiting your site over a 28-day rolling window.
When field data tells a different story
A site can score 90 in PageSpeed Insights and still sit in the “needs improvement” band in field data, because real visitors on slow mobile connections or older hardware pull the numbers down. The opposite happens too. A site with a middling lab score can pass field thresholds if its actual audience mostly visits on fast broadband.
There is also a quieter problem for smaller sites. If you do not have enough eligible Chrome users visiting within that 28-day window, Google simply will not have sufficient field data to generate a Core Web Vitals assessment at all, which means your real-world performance goes unscored rather than measured.
Which Pages Get Scored and Which Don’t
Google measures core web vitals metrics at the individual URL level, not across your domain as a whole. A fast, well-optimised homepage tells Google nothing about your contact page, your service pages, or your checkout. Each URL collects its own real-world performance data from actual visitors, and each one gets its own pass or fail against the thresholds. That means you can have a genuinely tight homepage sitting right next to a checkout page that has never been looked at properly, and Google treats them as completely separate cases.
The pages that tend to get overlooked are the ones that feel secondary until you check the data. A WooCommerce checkout loaded with tracking scripts. A bloated contact page with a third-party form embed. A service landing page with an uncompressed hero image nobody noticed because the designer only ever tested on a fast office connection.
These pages still get scored. If they fail, they pull down the site-wide signal Google uses to assess your overall Core Web Vitals status in Search Console. Fixing the homepage and calling it done is a common mistake, and one that takes time and careful page-by-page auditing to properly address.
Where to Find Your Actual Core Web Vitals Data
Start with Search Console, not PageSpeed
Google Search Console is where your real Core Web Vitals data lives, and it should be your first stop. The Core Web Vitals report inside Search Console groups your URLs into three bands: Poor, Needs Improvement, and Good. These groupings are based on field data collected from real visitors using Chrome, which means they reflect what people on actual devices and connections are experiencing. That distinction matters enormously when you’re trying to understand whether a problem is widespread or confined to a specific page type.
Why the report is always the last thing to turn green
Fixing something in your code does not immediately shift those groupings. Google needs to collect enough fresh field data before it reclassifies your URLs, and that process takes weeks. On all the websites we have worked through from failing to passing Core Web Vitals, the Search Console report was always the last thing to turn green, long after the underlying page speed fixes were in place.
Set a reminder to check back after four to six weeks rather than refreshing the report daily looking for instant confirmation.