There is a particular irony at the heart of the Core Web Vitals industry. The metrics themselves are simple -- three numbers that describe how fast, responsive, and stable a web page feels to a real user. But the ecosystem of tools built around measuring those three numbers has become so elaborate that many business owners assume they need to install monitoring agents, sign up for SaaS dashboards, or hire a performance specialist just to find out where they stand. This is not true.
Google provides three free tools that, between them, tell you everything you need to know about your Core Web Vitals. All three require zero installation, zero code changes, and -- with one minor exception -- zero account friction. This post explains how each works, what each is best for, and how to combine them into a practical measurement workflow.
This post is part of the Core Web Vitals guide hub, and it assumes you already have a rough understanding of what LCP, INP, and CLS are. If not, start with our plain-English LCP guide first.
Tool 1: Google PageSpeed Insights
URL: pagespeed.web.dev Best for: Testing individual pages on demand Setup required: None Account required: None
PageSpeed Insights is the simplest tool and probably the one you will use first. You paste a URL into the form, wait about fifteen seconds, and get a detailed performance report for that single page.
The report is split into two tabs: Mobile and Desktop. Always look at the Mobile tab first. Google uses mobile-first indexing, so the mobile scores are what affect your rankings. Desktop scores are usually better than mobile scores, and optimizing for desktop when your mobile scores are poor is solving the wrong problem.
What PageSpeed Insights Shows You
At the top of the report is the "Core Web Vitals Assessment." This is your pass/fail grade. Either it shows a checkmark (you pass) or an X (you do not). Below that are the individual metrics with scores in three zones -- green (good), orange (needs improvement), red (poor).
Then come the detailed metrics:
- First Contentful Paint (FCP): When the first visible element appears
- Largest Contentful Paint (LCP): When the biggest visible element finishes loading
- Total Blocking Time (TBT): A lab-only substitute for INP
- Cumulative Layout Shift (CLS): How much the page jumps around while loading
- Speed Index: A weighted average of how quickly content appears
The diagnostics section below the metrics is where most of the useful information lives. It lists specific problems PageSpeed identified on your page:
- "Reduce unused JavaScript"
- "Properly size images"
- "Serve images in next-gen formats"
- "Eliminate render-blocking resources"
- "Largest Contentful Paint element: [specific element]"
That last one -- the LCP element identification -- is invaluable. It tells you exactly which image or heading on your page is the LCP element, so you know exactly what to optimize.
The Critical Distinction: Lab Data vs Field Data
Here is the concept that most beginners miss, and it matters enormously: PageSpeed Insights shows you two kinds of data.
Lab data: A simulated test Google runs on a virtual device with a throttled network connection. This is the big, colorful performance score at the top of the report. Lab data is consistent, repeatable, and useful for debugging -- you can make a change and rerun the test to see if it helped.
Field data: Aggregated real-world measurements from actual Chrome users visiting your site. This is labeled "Discover what your real users are experiencing" in the report. Field data is what Google actually uses for ranking. If your site has enough traffic, the field data is more important than the lab data.
Why this matters: the two data sources frequently disagree. Your lab data might show a "Poor" LCP of 5 seconds, while your field data shows a "Good" LCP of 2.1 seconds -- because your real users have faster connections than Google's simulation. Or the opposite can happen: pristine lab data, terrible field data.
The rule: trust field data for ranking decisions, use lab data for debugging specific issues.
When PageSpeed Insights Is Not Enough
PageSpeed Insights tests one page at a time, on demand. This makes it useful for checking specific pages or debugging specific changes, but not useful for monitoring your whole site over time. For that, you need the second tool.
Tool 2: Google Search Console Core Web Vitals Report
URL: search.google.com/search-console Best for: Monitoring site-wide Core Web Vitals over time Setup required: Verify ownership of your site (one-time) Account required: Free Google account
If PageSpeed Insights is a flashlight for inspecting one page, Search Console's Core Web Vitals report is an overhead light illuminating your entire site.
How to Access the Report
- Log in to Google Search Console with a Google account.
- If you have not already verified ownership of your site, follow the verification process (usually involves adding a DNS TXT record or uploading a small file).
- In the left sidebar, navigate to Experience > Core Web Vitals.
- You will see two reports: Mobile and Desktop. Click Mobile first.
What the Report Shows
The report displays an aggregated view of Core Web Vitals for all pages on your site that Google has sufficient data for. It groups your URLs into three buckets: Good, Needs improvement, and Poor, and shows the trend over the last 90 days.
Below the main chart, the report groups pages with similar issues. For example:
- "LCP issue: longer than 4s (mobile)" with 47 URLs affected
- "CLS issue: more than 0.25 (mobile)" with 12 URLs affected
Click any issue to see the specific URLs affected. This is the workflow for finding out which pages need optimization, not just whether your site as a whole is in trouble.
The Field Data Advantage
The Search Console report uses 100% field data from the Chrome User Experience Report (CrUX). This is exactly the data Google uses for ranking. If Search Console says your Core Web Vitals are "Good," Google's ranking algorithms see them as good. If it says "Poor," you have a ranking problem to fix.
This is why the Search Console report is, for most small businesses, the single most important Core Web Vitals tool. It tells you what Google thinks, using the data Google actually uses.
The 28-Day Lag
One important caveat: the field data in Search Console reflects the preceding 28 days of real user visits. When you make a performance improvement, it does not appear in the report for roughly 28 days. This lag can be frustrating if you are trying to see the impact of a specific change quickly. For rapid feedback, use PageSpeed Insights; for long-term truth, use Search Console.
Sufficient Traffic Required
The Core Web Vitals report only shows data for pages that have received enough real user visits to produce statistically meaningful measurements. New sites, low-traffic sites, or specific low-traffic pages may not appear in the report at all. If you do not see data, it usually means your site does not yet have enough traffic to measure -- not that your performance is fine.
Tool 3: Chrome UX Report (CrUX) via Public Dashboard
URL: treoh.com/crux or crux.run (public CrUX explorers) Best for: Comparing your performance to competitors Setup required: None Account required: None for public viewers
The Chrome User Experience Report is a public dataset published by Google that contains anonymized performance data from Chrome users visiting websites across the internet. Search Console uses CrUX data under the hood for its Core Web Vitals report.
What makes CrUX uniquely useful is that you can query it for any public website, including your competitors. This lets you do something that is difficult with the other tools: directly compare your site's field data to your competitors' field data.
Several free tools expose CrUX data in user-friendly dashboards:
- treoh.com/crux: Simple interface, paste a domain, see Core Web Vitals
- crux.run: More detailed view with historical charts
- Google Data Studio: For advanced users who want custom CrUX dashboards
Why this matters: knowing that your LCP is 3.2 seconds in isolation is not that useful. Knowing that your LCP is 3.2 seconds while your top competitor's LCP is 2.1 seconds is genuinely actionable. You can see whether you are keeping up with the market or falling behind.
A caveat: CrUX only includes data for pages with sufficient traffic, just like Search Console. For small competitors or niche sites, data may not be available.
The Practical Measurement Workflow
Combining these three tools, here is the workflow I recommend for a small business:
Weekly check (5 minutes): Open Google Search Console > Core Web Vitals and check for new issues or regressions. Note any URLs moving into the "Needs improvement" or "Poor" buckets. If nothing has changed, move on.
After any site change (10 minutes): Run PageSpeed Insights on your homepage and 2-3 other important pages. Compare the lab scores to what you saw before the change. If the change helped, celebrate. If it hurt, roll back or investigate.
Monthly deep dive (30 minutes): Open the Search Console report, identify the worst-performing page type, run those pages through PageSpeed Insights, and apply fixes. See our LCP post for the most effective fixes.
Quarterly competitive check (15 minutes): Use a CrUX explorer to compare your Core Web Vitals to your top 3 competitors. If you are falling behind, prioritize optimization work. If you are ahead, relax.
That is the complete measurement workflow for a business owner who wants to track performance without becoming a full-time performance engineer.
What NOT to Do
Several common mistakes waste time and produce worse outcomes:
Do not install heavyweight monitoring agents on a small site. Services like New Relic, Datadog, or enterprise RUM tools are overkill for a site with a few thousand monthly visitors. The free tools above are sufficient.
Do not check PageSpeed Insights every day. Lab data varies naturally based on network conditions. Daily checks create anxiety about normal variance. Weekly or post-change is plenty.
Do not optimize for a perfect 100 Lighthouse score. The difference between 87 and 100 is usually imperceptible to users and provides no ranking benefit. Focus on moving out of "Poor" and into "Good." Beyond that, stop.
Do not chase isolated PageSpeed Insights runs. If you get a score of 68 once, then 72, then 65, you are looking at normal variance, not actual changes. Look at trends, not individual readings.
Do not ignore field data in favor of lab data just because lab data is more flattering. Field data is what matters for rankings. If your lab scores look great but your field data is poor, trust the field data.
The Bigger Picture
Measuring Core Web Vitals is only half the work. Once you know where you stand, you need to know which issues to fix and in what order. Our Core Web Vitals guide hub covers the complete picture, including the six fixes that genuinely help, the twenty optimizations you can safely ignore, and the framework for deciding when to hire a developer.
And if you want a single tool that combines Core Web Vitals measurement with the rest of the SEO picture -- content quality, schema, technical health, AI search visibility -- run a free audit with Licheo. It takes thirty seconds, requires no account, and tells you where performance sits in the list of things worth fixing. That is, as always, exactly what we built it for.