Chrome User Experience Report, or CrUX as most people shorten it, deals with how real users actually interact with your site. That is a completely different thing from a simulated test that passes you solely because you structured your page right or used the latest image compression trick. CrUX measures what people who actually land on your site feel.

If you are a developer, you should already be conversant with FCP, LCP, INP, TBT, and CLS. If you are a website owner, a founder, or a design hobbyist, those five letters can look like alphabet soup. So before anything else, here is what they actually mean in practice.

What These Metrics Are Really Asking

Strip away the acronyms and every one of these metrics is asking one of three simple questions:

When a user lands on your site, does the first meaningful thing they see load quickly? That is First Contentful Paint (FCP) and Largest Contentful Paint (LCP), the second being the biggest visible element on the screen, usually a hero image or heading, and how long it takes to show up.

When they click or tap something, is there a lag before the page responds? That is Interaction to Next Paint (INP), and its older relative Total Blocking Time (TBT), which shows up when the main thread is too busy running scripts to respond to a click.

Does the page jump around while it is loading, so a button shifts right before someone taps it? That is Cumulative Layout Shift (CLS).

That is the entire narrative behind Core Web Vitals. Loads fast, responds fast, stays put. Everything else is implementation detail.

Where This Connects to Our Last Article

We wrote earlier about why mobile Lighthouse scores usually come in lower than desktop, and walked through the throttling behind that gap. Following that piece, a comment rightly pointed out something we referenced but did not sit on long enough, the fact that CrUX, and by extension Core Web Vitals, is the number that actually matters to Google and to your users. Lighthouse is a lab simulation. CrUX is the field.

That distinction is not a footnote. It is the difference between chasing a score and fixing what real visitors experience.

How to Actually See Your CrUX Data

You do not need paid tools to start here.

Run your live site through PageSpeed Insights. If your site gets enough traffic, you will see a section above the lab results labeled “Discover what your real users are experiencing.” That section is pulling from CrUX, aggregated over the last 28 days from actual Chrome users who visited your pages.

Search Console has a Core Web Vitals report that does the same thing at scale, grouped by URL and by whether pages pass, need improvement, or fail. It is free, it is already sitting in your account if your site is verified, and it will tell you which pages are actually failing for real people, not which pages fail a simulated run on a throttled connection.

Only once you have exhausted what these two give you does it make sense to look at paid, more granular field-data tools.

Worth noting

CrUX only works if enough real people are actually visiting your site. Google needs a minimum volume of Chrome users hitting a page before it will surface field data for it at all. If your site is new, low-traffic, or mostly seen by a small local audience, PageSpeed Insights and Search Console will often show you nothing in the field data section, or data so thin it is not reliable.

If that is where you are, lab data is not a downgrade, it is your main tool for now. Lean on Lighthouse to get the fundamentals right, then go further than the score. Actually use your own site on a mid-range phone over mobile data. Click through your own forms and menus. Notice where you personally feel a delay or a jump. That manual pass catches real friction that neither Lighthouse nor an empty CrUX report will show you.

Once traffic grows, CrUX data will start populating on its own, and you can shift from manual testing to reading real user behavior in aggregate.

Why Field Data Is the Real Compass

A site can score in the 60s on mobile Lighthouse and still pass Core Web Vitals in the field, because its actual visitors are on decent phones and networks that the lab throttle deliberately punishes. The reverse also happens. A site can hit 90+ on Lighthouse and still fail INP in the field, because the lab run never simulates someone actually tapping a button, so heavy main-thread JavaScript that wrecks real interactions barely registers in the test.

That is why lab metrics exist to guide, not to judge. They are useful for diagnosing why something is slow. They are not the number that decides whether your site is actually fast for the people using it.

The sequence that works is simple. Pull your CrUX or Search Console numbers first. Find whichever metric is actually failing at the 75th percentile, since that is the threshold Google uses. Then use Lighthouse as the diagnostic tool to figure out why, whether that is an unoptimized LCP image, unused JavaScript blocking the main thread, or elements without reserved space causing shift. Chasing a lab score to 100 without checking the field data first is a good way to spend a week solving a problem your actual users never had.

Field data is your compass. Lab data is your flashlight. Use them in that order.