Decode Your Website’s Speed with Core Web Vitals 

How do you measure your website’s speed?

You measure your website’s speed using Core Web Vitals (Google’s three real-world performance metrics) and free Google tools like PageSpeed Insights and Search Console that report them. Rather than a single vague “speed score,” Core Web Vitals break performance into three specific, measurable things: loading (LCP), responsiveness (INP), and visual stability (CLS). Reading those numbers correctly, and knowing where they come from, is what lets you diagnose exactly what’s slow and what to fix, instead of guessing.

Key Takeaways

• Measure speed with Core Web Vitals: LCP (loading, 2.5s), INP (responsiveness, 200ms), and CLS (stability, 0.1) (web.dev).
• Use free tools: PageSpeed Insights for any page, Search Console for site-wide field data.
• Know lab vs field data: field data (real users) is what Google assesses; lab data is for diagnosing.
• The numbers are measured at the 75th percentile, so a page must be fast for most users, not just on your device.

Most people sense their site is “slow” but can’t say why or by how much, which makes it hard to fix. Core Web Vitals turn that vague feeling into concrete numbers you can read, compare, and act on. This guide focuses on the measurement and interpretation side, how to get your site’s speed data, what each number means, and how to read it to find the problem, which then points you to the fixes in our guide to improving Core Web Vitals.

The table below lists the tools for measuring site speed and what each is best for.

What do the Core Web Vitals numbers mean?

The Core Web Vitals numbers each measure a different part of speed, and knowing what “good” looks like lets you read them at a glance. There are three, and Google sets a clear threshold for each, measured at the 75th percentile of real visits (web.dev).

Largest Contentful Paint (LCP) measures loading, how long until the largest visible element appears, and good is 2.5 seconds or less. Interaction to Next Paint (INP) measures responsiveness, how quickly the page reacts to interaction, and good is 200 milliseconds or less; INP replaced the older First Input Delay metric in March 2024. Cumulative Layout Shift (CLS) measures visual stability, how much the page unexpectedly moves as it loads, and good is 0.1 or less.

Reading them together gives a complete picture: a page can load fast (good LCP) yet feel laggy (poor INP) or jumpy (poor CLS). That’s the value of measuring all three rather than a single number, you see exactly which dimension of speed is the problem. Each maps to specific causes and fixes, which our dedicated guides to LCP and the other metrics cover, and the full definitions are in our Core Web Vitals beginner’s guide.

What tools measure Core Web Vitals?

The tools that measure Core Web Vitals are all free from Google, and each suits a different job: PageSpeed Insights for a single page, Search Console for your whole site, and Chrome’s DevTools for testing during development. Knowing which to use when saves time and avoids confusion.

PageSpeed Insights is the best starting point. Paste in any URL and it shows both your real-user (field) data and a lab test, plus a prioritised list of specific issues and the estimated time each fix would save. It’s how you diagnose one page in depth. Google Search Console takes the wider view: its Core Web Vitals report shows how your real pages perform across the entire site, grouped by issue and status (good, needs improvement, poor), so you can find which pages or templates need attention site-wide.

For development, Chrome’s built-in DevTools and the Lighthouse report let you test pages as you change them, useful lab data for confirming a fix before it goes live. Underpinning the field data in PageSpeed Insights and Search Console is the Chrome User Experience Report (CrUX), Google’s dataset of real-user measurements. The practical workflow: use Search Console to find problem pages, PageSpeed Insights to diagnose each one, and DevTools to test your fixes.

How do you run a PageSpeed Insights test, and what about mobile vs desktop?

Running a PageSpeed Insights test takes seconds: go to pagespeed.web.dev, paste the full URL of the page you want to check, and click Analyse. PageSpeed Insights then returns a report with your real-user (field) data at the top, a lab test below it, and a prioritised list of issues, scored separately for mobile and desktop.

The mobile/desktop split matters more than people expect. PSI shows two tabs, and the scores are almost always different, mobile is usually lower, because it simulates a mid-range phone on a slower connection, which is a harder test than a desktop on broadband. Since Google indexes the mobile version of your site and most traffic is mobile, treat the mobile tab as the one that counts and fix for it first; a good desktop score alongside a poor mobile score is still a problem. Test the specific pages that matter (your homepage, top landing pages, key product pages) rather than only the homepage, since different templates can perform very differently. Run each on both tabs, note where the field data says you stand, then use the lab section below to dig into why.

How do you read the data correctly (lab vs field)?

You read Core Web Vitals data correctly by understanding the crucial difference between lab data and field data, and knowing that Google assesses your site on field data. Confusing the two is the most common mistake, and it leads people to “fix” a lab score while their real-user performance, the thing that actually counts, stays poor.

Field data comes from real users visiting your site over time (via the Chrome UX Report), and it’s what Google uses to assess page experience. It reflects the full range of your visitors’ devices and connections, which is why it’s the source of truth. Lab data comes from a single simulated test in a controlled environment (like Lighthouse), which is perfectly repeatable and great for debugging, but it represents one synthetic run, not your real audience. A page can score well in the lab on a fast simulated connection yet fail in the field because many real users are on slower devices.

The other essential detail is the 75th percentile: Core Web Vitals are judged on the experience of the slowest 25% of visits, meaning 75% of real loads must hit the threshold to pass. This is why your own quick test on a fast laptop can mislead you, your experience isn’t representative. The right habit is to trust the field data for judging where you stand, and use lab data to diagnose and test fixes, then confirm improvement in the field data over the following weeks.

How do you read the Opportunities and Diagnostics sections?

Below the scores, PageSpeed Insights lists Opportunities and Diagnostics, and this is the part that tells you exactly what to fix. Opportunities are specific changes with an estimated time saving attached (for example, “Eliminate render-blocking resources” or “Properly size images”), while Diagnostics give more context on how the page is built and where the cost is going.

Read them in order of estimated saving rather than top to bottom, the biggest numbers are usually images, render-blocking CSS or JavaScript, and unused code, so start there. Expand each item to see the exact files or elements responsible, which turns a vague “it’s slow” into a named to-do list: this image, that script. Two cautions: the time savings are lab estimates, not guarantees, so use them to prioritise rather than treat as exact, and confirm any fix in field data over the following weeks, not just by re-running the lab test. The Diagnostics section is often where you’ll spot the root cause behind several Opportunities at once, a single heavy third-party script, say, that inflates both blocking time and total page weight.

How do you turn the measurements into action?

You turn Core Web Vitals measurements into action by letting the data point you to the specific bottleneck, then applying the fix for that metric, rather than trying to improve “speed” in general. The whole value of measuring is that it tells you exactly what to do next, so the workflow is diagnose, fix, re-measure.

Start by reading which metric is failing and on which pages. If LCP is poor, the data usually points to a heavy image, a slow server, or render-blocking resources, so you optimise images, improve hosting, and defer blocking files. If INP is poor, the cause is almost always too much JavaScript tying up the main thread, so you reduce and defer scripts. If CLS is poor, the tool shows which elements shift, so you reserve space for images, ads, and fonts. The measurement names the problem; the fix follows from which metric and which element the tool flags.

Then work in priority order. Fix the metric furthest from passing, and the pages that matter most for your business, first, rather than spreading effort thinly. After each change, re-test in PageSpeed Insights to confirm the lab improvement, then watch Search Console’s field data over the following weeks to confirm it for real users. This loop, measure, fix the specific cause, re-measure, is how diagnosis becomes faster pages, and it’s exactly what our guide to improving Core Web Vitals details metric by metric.

Final thoughts

Measuring your website’s speed properly means moving past a vague sense of “slow” to the three concrete Core Web Vitals, loading (LCP), responsiveness (INP), and stability (CLS), read through Google’s free tools. That’s what turns performance from guesswork into a diagnosable, fixable problem: you can see exactly which dimension is weak and which pages need work.

The two things to get right are using the correct tool for the job (PageSpeed Insights to diagnose a page, Search Console to find site-wide issues) and trusting field data over lab data, since field data is what Google assesses and what reflects your real users. Once you can read the numbers, you know what to fix, which is where our guide to improving Core Web Vitals takes over.