Core Web Vitals: The Ranking Lever Hiding in Public Data

Google already knows how fast your site is for real people, and it publishes the answer for free. Every time enough Chrome users visit your site, Google records how quickly the page loaded, how fast it responded to a tap, and how much it jumped around while loading. That record is the Chrome UX Report, and it is public for your site and your competitors' sites alike. Most businesses never look at it. Here is how to read your own field data in five minutes and turn it into a fix list that starts with the offender that costs you the most.

Speed advice usually arrives as a vague nag. Someone runs a test, sees a low score, and tells you the site is slow. That is not a plan. What you need is a number that reflects what your actual visitors experience, a clear bar to clear, and an order of operations so you fix the thing that matters before the thing that does not. Google hands you all three. The scores are called Core Web Vitals, the bars are documented, and the data is drawn from real users, not a guess.

This is a public-data read, the same discipline behind the first phase of the five-phase system we run before we build anything. You do not need a developer, a paid tool, or a login to start. You need a browser and the willingness to read three numbers honestly. Here is the method.

#The three numbers Google measures

Core Web Vitals is three metrics, each answering a plain question a visitor would recognize. The definitions and thresholds below come straight from Google's own reference at web.dev. Learn what each one measures before you try to fix anything:

• Largest Contentful Paint (LCP) is how long until the biggest thing on the screen finishes loading. This is the visitor's felt answer to "did the page show up." Usually it is your hero image or a big block of headline text.
• Interaction to Next Paint (INP) is how quickly the page responds when someone taps or clicks. It measures the lag between the action and the screen updating. High INP is the feeling of a page that ignores you for a beat before reacting.
• Cumulative Layout Shift (CLS) is how much the page jumps around while it loads. It is the score for content that shoves down under your thumb right as you go to tap it. A low number means the layout stays put.

Those three cover the load, the response, and the stability of the experience. Together they are Google's stand-in for whether a page feels good to use on a real phone. None of them is exotic. They put a figure on frustrations you already recognize as a visitor.

#The thresholds you are aiming at

You are not chasing a perfect score. Each metric has a documented good bar, a needs-improvement band, and a poor zone. Google assesses at the 75th percentile of your visits, which means three out of four page loads have to clear the bar for the metric to count as good. These are Google's documented thresholds:

• LCP is good at 2.5 seconds or less, needs improvement between 2.5 and 4 seconds, and poor above 4 seconds.
• INP is good at 200 milliseconds or less, needs improvement between 200 and 500 milliseconds, and poor above 500 milliseconds.
• CLS is good at 0.1 or less, needs improvement between 0.1 and 0.25, and poor above 0.25.

Write those six numbers on a sticky note. They are the whole scoreboard. A page passes the Core Web Vitals assessment only when all three metrics are in the good zone at the 75th percentile. Miss any one and you are told exactly which one to work on, which is the opposite of a vague slow-site complaint.

#Read your own field data in five minutes

The front door is pagespeed.web.dev. It reads directly from the Chrome UX Report and needs no account. Work through it in this order:

1. Enter your homepage URL and run the report. Give it a moment. It fetches your real-user field data and also runs a fresh lab test.
2. Find the field-data section at the top, labeled as the experience of real users over the trailing 28 days. This is the part that reflects your actual visitors, not a simulation.
3. Read all three metrics against the thresholds you noted. A colored bar shows whether each sits in the good, needs-improvement, or poor band. Note which one is worst.
4. Toggle between the mobile and desktop views. Most traffic is mobile and most speed problems show up there first, so trust the mobile read as your primary picture.
5. Check whether the field data covers your whole origin or just this page. Individual pages need enough traffic to report on their own; low-traffic pages fall back to the origin-wide summary.

In five minutes you have moved from a hunch to a scoreboard. You know which of the three numbers is failing, whether it fails on mobile or desktop, and by how much. That is enough to decide where the work goes, and you have not written a line of code or paid for a tool.

#Why field data beats the lab score

The same report shows two kinds of data, and confusing them is the most common mistake. Field data is what real people experienced on their own devices and networks over the last 28 days. Lab data is a single test Google runs on demand under fixed, controlled conditions. They often disagree, and when they do the field data is the one that matters for ranking, because Google ranks on the real experience, not the simulation.

Here is why they split. Your lab test might run on a fast simulated connection and show a clean load. But if a real share of your visitors are on older phones, weaker signal, or a page heavy with third-party scripts that only fire for real users, their felt experience is slower than the lab suggests. The field data catches all of that. Treat the lab score as a diagnostic that helps you find the cause of a problem, and treat the field score as the verdict on whether the problem is real.

#Your competitors' scores are public too

Here is the part almost nobody uses. The Chrome UX Report is not private to you. You can enter a competitor's URL into PageSpeed Insights and read their real-user field data the same way you read your own. That turns a private tuning exercise into a competitive read. If the three shops you lose deals to are all sitting in the poor band on mobile LCP, speed is a place you can pass them, and it is cheap to diagnose.

The move is simple. Pull the field scores for yourself and your top three or four competitors, put the numbers side by side, and look for the gap. If everyone in your market is slow, being the fast one is an edge worth chasing. If your competitors are already fast and you are not, you are handing them a tie-breaker on every close search result. Either way, the read tells you whether speed is worth your effort right now or whether your time is better spent elsewhere. Pair this with the competitor coverage guide to build a fuller picture of where you stand, and see the competitor analysis service for how we run this at scale.

#How this feeds Google's ranking

Core Web Vitals are the measurable core of Google's page-experience signals. Google has been clear that page experience is a factor in ranking, but it is a tie-breaker, not a trump card. When two pages are close on relevance and content quality, the one that feels better to use gets the edge. A great page will not fall off the map for a middling speed score, and a slow page will not climb on speed alone.

The honest way to think about it: passing Core Web Vitals removes a handicap. A slow site quietly loses ground it did not have to lose, in rankings and in visitors who leave before the page even loads. You are not buying a boost so much as you are refusing to pay a penalty. Because the diagnosis is free and public, there is no reason to keep paying that penalty when you can see the exact number that is costing you.

#Fix the largest offender first

Once you have the scores, resist the urge to fix everything at once. The whole point of reading the three numbers is to work in order. Start with the metric that is furthest into the poor zone at the 75th percentile, because that is the one dragging down the most real experiences. A page that fails one metric badly is a page that passes the moment you fix that one thing.

Each metric points at a familiar class of cause, so knowing which number is worst tells you roughly where to look:

1. If LCP is your worst score, look at the biggest element in view. An oversized hero image that was never compressed is the usual culprit. Serving a right-sized, modern-format image and letting it load early is often the single biggest win a site can make.
2. If CLS is your worst score, hunt for content that loads late and pushes the rest down. Images without reserved space, fonts that swap in, and ads or embeds that arrive after the text are the common causes. Reserving space for them stops the jump.
3. If INP is your worst score, the page is doing too much work when someone interacts. Heavy scripts, especially third-party tags you may have forgotten you added, block the page from responding. Trimming or deferring them is where the fix lives.

As an illustration of the order in action: imagine a site whose mobile field data shows LCP deep in the poor zone, CLS just over the good line, and INP already passing. The obvious plan is to fix the hero image first. That single change might pull LCP from a poor read into good, which could move the whole page from failing the assessment to passing it, without touching the other two. That is a made-up example to show the logic, not a promised result. Your numbers decide your order. But the principle holds: one offender, fixed first, often carries the whole page.

#Go deeper when you need the raw data

PageSpeed Insights is the reading you start from. When you want more than one URL at a time, the Chrome UX Report itself is queryable. Google exposes it as a public API and as a public dataset on BigQuery, so you can pull field scores for a whole list of pages, or a whole list of competitors, in one pass instead of typing URLs one by one. That is how you go from a spot check to a monitored baseline you refresh every month as the trailing 28-day window rolls forward.

The discipline is the same as any public-data read: pull the numbers, track them over time, and act on the direction, not just today's snapshot. A site whose LCP has been creeping up month over month is telling you something new is slowing it down before your visitors start leaving over it. Catching that early is free, and it lives in a dataset almost nobody in your market bothers to watch.

#Common mistakes to avoid

• Reading the lab score and ignoring the field score. The lab test is a diagnostic; the field data is what Google ranks on and what your visitors actually felt.
• Checking desktop when your traffic is mobile. Speed problems surface on real phones first. Read the mobile field data as your primary picture.
• Chasing a perfect score. The bars are good, not perfect. Clear the threshold on all three and stop; there are better places to spend the next hour.
• Fixing every metric at once. Work the worst offender first. A page usually passes the moment its single failing metric clears the bar.
• Reading the data once and never again. The field window is the trailing 28 days and it keeps moving. A monthly re-read keeps a regression from going unnoticed.

That standard is not a slogan. It is a workflow anyone can run, and Google hands you the hardest part for free. Open PageSpeed Insights, read your three field numbers against the six thresholds, pull the same read on your competitors, and fix the largest offender first. When you are ready to turn the read into a faster site and a channel plan, see the map pack guide and the schema markup guide for the other public levers, and read who we serve for how the work is priced by your industry and your stage.