To check Core Web Vitals, start with real-user data, then use a lab test to find the cause. Open the Core Web Vitals report in Search Console for your whole site, paste one URL into PageSpeed Insights for a page-level result, and run Lighthouse in Chrome DevTools to debug. Use CrUX for trends over time.
Core Web Vitals are field metrics first. Google's web.dev guide to its tools says "Field data describes how real users actually experienced your website" and "Lab data describes how hypothetical users may experience your website." Its advice is to "concentrate on field Core Web Vitals over Lighthouse metrics and scores."
That sets the order of work. Use field data to learn whether you have a problem and where. Then use lab tools to learn why. The same guide says CrUX "can often tell you when there is a problem, but often has insufficient data to tell you why," and that "Lab tools can't always identify the cause of all Core Web Vitals issues affecting your users."
Google's Web Vitals overview sets the "good" line for each metric. It recommends measuring at "the 75th percentile of page loads, segmented across mobile and desktop devices." In plain words, three out of four visits have to meet the line.
PageSpeed Insights applies the same rule: "the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good." This guide is about testing. For what each metric means and how to fix it, read our guide to Core Web Vitals: LCP, INP, CLS benchmarks and fixes.
The Core Web Vitals report in Search Console is the widest view. Its help page says "The data for the Core Web Vitals report comes from the CrUX report," so you see real users over a rolling window, not a lab run.
When you fix an issue, the report offers a validation step. Google describes it this way: "Click Start Tracking to start a 28-day monitoring session to check for instances of this issue in your site." Plan on about four weeks before Search Console confirms a fix.
PageSpeed Insights (PSI) "reports on the user experience of a page on both mobile and desktop devices," according to its documentation. Enter a URL and you get two kinds of result.
If the URL has too little field data, "PSI will fall back to origin-level granularity." If the origin also lacks data, PSI "will be unable to show any real-user experience data."
Do not expect the two sections to match. Field data is "a historical report about how a particular URL has performed." Lab data "is based on a simulated load of a page on a single device and fixed set of network conditions. As a result, the values may differ."
Lighthouse is "an open-source, automated tool to help you improve the quality of web pages." You can run it in a panel inside Chrome DevTools, from the command line, as a Node module, or through PSI. Google's overview lists the DevTools route: open Chrome DevTools, click the Lighthouse tab, and run the audit on the page. It says the report arrives after "30 to 60 seconds."
Know the limits before you trust the result. Google's guide says "Lighthouse (or Lighthouse CI) is not a substitute for field data," and its Web Vitals overview says "Tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP."
For INP, use the Performance panel in DevTools. Per Chrome's documentation, "If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)." Google's guide adds that "The trace view is particularly useful to debug responsiveness issues affecting INP."
The Chrome User Experience Report (CrUX) is "a dataset that reflects how real-world Chrome users experience popular destinations on the web." Chrome's CrUX page calls it "the Google dataset of the Web Vitals program." Search Console and PSI both read from it. You can also use it directly.
CrUX has a coverage limit. "Not all origins or pages are represented in the dataset": a site must be publicly discoverable and have "a large enough number of visitors." A new or low-traffic page may show no field data in any tool. In that case, lean on lab tests and check again as traffic grows.
Follow the three steps in Google's web.dev guide: evaluate your site's health and find the pain points, debug and optimize, then monitor for changes, because "A website needs continuous monitoring in both the lab and the field to identify worsening trends."
To fix what you find, read how to pass the Core Web Vitals assessment.
Keep the ranking expectation modest. Google's page experience documentation says "Core Web Vitals are used by our ranking systems." It also says good results "doesn't guarantee that your pages will rank at the top of Google Search results" and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."
Mergeflo does not test, monitor or fix Core Web Vitals, so use the tools above for that. What it does is track your Google clicks, impressions and positions, so after you change a template you can watch how those pages perform in search. It also finds search gaps and buyer questions, drafts articles in your brand voice for your review, and publishes the ones you approve to Webflow when you press Publish.
Enter a URL in PageSpeed Insights. It shows real-user data from CrUX and a Lighthouse lab run for the same page. To check a whole site instead, open the Core Web Vitals report in Search Console.
There is no single score. Google sets a line for each metric: LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads. PageSpeed Insights also reports a separate Lighthouse score, and says 90 or above is good.
They measure different things. Field data is a historical report from real users. Lab data comes from one simulated load on a single device and fixed network conditions. Google says the values may differ.
A URL group without a minimum amount of reporting data is omitted from the report. Pages also need enough public visitors to appear in CrUX at all, since not all origins or pages are represented in the dataset.
Use the report's validation step. Google describes it as a 28-day monitoring session, and CrUX data is a 28-day rolling window, so allow about four weeks.
Google says Core Web Vitals are used by its ranking systems, but that good results do not guarantee a top ranking. It also says it seeks to show the most relevant content even if the page experience is sub-par.
